悦目的代码,好看的代码会让人的心情愉快, 读起代码也就不累,工整、整洁的程序代码,通常更让人欢迎,也更让人称道。
现在的硬盘空间这么大,不要让你的代码挤在一起,这样它们会抱怨你虐待它们的。
好了,用“缩进、空格、换行、空行、对齐”装饰你的代码吧,让他们从没有秩序的土匪中变成一排排整齐有秩序的正规部队吧。
3、程序注释——————养成写程序注释的习惯,这是每个程序员所必须要做的工作。
我看过那种几千行,却居然没有一行注释的程序。
这就如同在公路上驾车却没有路标一样。
用不了多久,连自己都不知道自己的意图了,还要花上几倍的时间才看明白,这种浪费别人和自己的时间的人,是最为可耻的人。
是的,你也许会说,你会写注释,真的吗?注释的书写也能看出一个程序员的功 底。
一般来说你需要至少写这些地方的注释:文件的注释、函数的注释、变量的注释、算法的注释、功能块的程序注释。
主要就是记录你这段程序是干什么的?你的 意图是什么?你这个变量是用来做什么的?等等。
不要以为注释好写,有一些算法是很难说或写出来的,只能意会,我承认有这种 情况的时候,但你也要写出来,正好可以训练一下自己的表达能力。
而表达能力正是那种闷头搞技术的技术人员最缺的,你有再高的技术,如果你表达能力不行,你 的技术将不能得到充分的发挥。
因为,这是一个团队的时代。
好了,说几个注释的技术细节:i 对于行注释(“//”)比块注释(“/ /”)要好的说法,我并不是很同意。
因为一些老版本的 C 编译器并不支持行注释,所以为了你的程序的移植性,请你还是尽量使用块注释。
ii 你也许会为块注释的不能嵌套而不爽,那么你可以用预编译来完成这个功能。
使用“if 0”和“endif”括起来的代码,将不被编译,而且还可以嵌套。
4、函数的inout参数———————————我经常看到这样的程序:FuncNamechar str int len strlenstr .....charGetUserNamestruct user pUser return pUser-gtname不!请不要这样做。
你应该先判断一下传进来的那个指针是不是为空。
如果传进来的指针为空的话, 那么,你的一个大的系统就会因为这一个小的函数而崩溃。
一种更好的技术是使用断言(assert),这里我就不多说这些技术细节了。
当然,如果是在 C 中,引用要比指针好得多,但你也需要对各个参数进行检查。
写有参数的函数时,首要工作,就是要对传进来的所有参数进行合法性检查。
而对于传出的参数也应该进行检查,这个动作当然应该在函数的外部,也就是说,调用完一个函数后,应该对其传出的值进行检查。
当然,检查会浪费一点时间,但为了整个系统不至于出现“非法操作”或是“Core Dump”的系统级的错误,多花这点时间还是很值得的。
5、对系统调用的返回进行判断——————————————继续上一条,对于一些系统调用,比如打开文件,我经常看到,许多程序员对 fopen 返回的指针不做任何判断,就直接使用了。
然后发现文件的内容怎么也读出不,或是怎么也写不进去。
还是判断一下吧: fp fopenquotlog.txtquot quotaquot if fp NULL printfquotError: open file error/nquot return FALSE 其它还有许多啦,比如:socket 返回的 socket 号,malloc 返回的内存。
请对这些系统调用返回的东西进行判断。
6、if 语句对出错的处理———————————我看见你说了,这有什么好说的。
还是先看一段程序代码吧。
if ch gt 0 ampamp ch lt 9 / 正常处理代码 / else / 输出错误信息 / printfquoterror ....../nquot return FALSE 这种结构很不好,特别是如果“正常处理代码”很长时,对于这种情况,最好不要用 else。
先判断错误,如: if ch lt 0 ch gt 9 / 输出错误信息 / printfquoterror ....../nquot return FALSE / 正常处理代码 / ......这样的结构,不是很清楚吗?突出了错误的条件,让别人在使用你的函数的时候,第一眼就能看到不合法的条件,于是就会更下意识的避免。
7、头文件中的ifndef——————————千万不要忽略了头件的中的ifndef,这是一个很关键的东西。
比如你有两个 C 文件,这两个C 文件都 include 了同一个头文件。
而编译时,这两个 C 文件要一同编译成一个可运行文件,于是问题来了,大量的声明冲突。
还是把头文件的内容都放在ifndef 和endif 中吧。
不管你的头文件会不会被多个文件引用,你都要加上这个。
一般格式是这样的: ifndef lt标识gt define lt标识gt ...... ...... endif lt标识gt在理论上来说可以是自由命名的,但每个头文件的这个“标识”都应该是唯一的。
标识的命名规则一般是头文件名全大写,前后加下划线,并把文件名中的“.”也变成下划线,如:stdio.h ifndef _STDIO_H_ define _STDIO_H_ ...... endif (BTW:预编译有多很有用的功能。
你会用预编译吗?)8、在堆上分配内存—————————可 能许多人对内存分配上的“栈 stack”和“堆 heap”还不是很明白。
包括一些科班出身的人也不明白这两个概念。
我不想过多的说这两个东西。
简单的来讲,stack 上分配的内存系统自动释 放,heap 上分配的内存,系统不释放,哪怕程序退出,那一块内存还是在那里。
stack 一般是静态分配内存,heap 上一般是动态分配内存。
由 malloc 系统函数分配的内存就是从堆上分配内存。
从堆上分配的内存一 定要自己释放。
用free 释放,不然就是术语——“内存泄露”(或是“内存漏洞”)—— Memory Leak。
于是,系统的可分配内存会随 malloc 越来越少,直到系统崩溃。
还是来看看“栈内存”和“堆内存”的差别吧。
栈内存分配 ————— char AllocStrFromStack char pstr100 return pstr 堆内存分配 ————— char AllocStrFromHeapint len char pstr if len lt 0 return NULL return char malloc len 对于第一个函数,那块 pstr 的内存在函数返回时就被系统释放了。
于是所返 回的 char什么也没有。
而对于第二个函数,是从堆上分配内存,所以哪怕是程序退出时,也不释放,所以第二个函数的返回的内存没有问题, 但 可以被使用。
一定要调用 free 释放,不然就是 Memory Leak!在堆上分配内存很容易造成内存泄漏,这是 C/C的最大的“克星”,如果你的程序要稳定,那么就不要出现 Memory Leak。
所以,我还是要在这里千叮咛万嘱付,在使用 malloc 系统函数(包括 calloc,realloc)时千万要小心。
记得有一个 UNIX 上的服务应用程序,大约有几百的 C 文件编译而成,运行测 试良好,等使用时,每隔三个月系统就是 down 一次,搞得许多人焦头烂额,查不出问题所在。
只好,每隔两个月人工手动重启系统一次。
出现这种问题就是 Memery Leak 在做怪了,在 C/C中这种问题总是会发生,所以你一定要小心。
一个 Rational 的检测工作——Purify,可以帮你测试你的程序有没有 内存泄漏。
我保证,做过许多 C/C的工程的程序员,都会对 malloc 或是 new 有些感冒。
当你什么时候在使用 malloc 和 new 时,有一种轻度的紧张和惶恐的感觉时,你就具备了这方面的修养了。
对于 malloc 和 free 的操作有以下规则:1 配对使用,有一个 malloc,就应该有一个 free。
(C中对应为 new 和 delete)2 尽量在同一层上使用,不要像上面那种,malloc 在函数中,而 free 在函数外。
最好在同一调用层上使用这两个函数。
3 malloc 分配的内存一定要初始化。
free 后的指针一定要设置为 NULL。
注:虽然现在的操作系统(如:UNIX 和 Win2k/NT)都有进程
上一篇:
C语言课程设计.简易计算器.报告
下一篇:
最新铁路市场营销论文参考文献