你必须非常努力,才能看起来毫不费力!
分类:
2008-10-11 12:49:56
1.引言
八月上旬,深圳举办了一个讨论会,主题是"编写优质无错代码"。这个讨论会吸引了深圳各大软件公司,通信公司的程序员,系统分析员参加,并在讨论会后纷纷表示,这种讨论会很有实际价值,希望将这种形式的讨论会继续下去,形成一个论坛,以提高大家的编程水平和交换有价值的信息资料。
这个活动的发起是从网络上开始的。我偶然看到了这个讨论会的论题,发生了兴趣。本来周末的我一般是很懒的,没什么事情是不会出门的。而当我看到这论题后,就给举办者发信表示愿意参加。于是,一个周六的下午,我就坐在了讨论会的现场。参加完这个讨论后,我觉得有必要把其中的精华部分写下来,和网络上的广大程序员共享,于是就有了这篇文章。
2.主题:
编写优质无错的代码---讨论会主题。
相信每个程序员都有这种希望,谁都不愿意自己写出来的代码在release之后出错,需要不停的修改维护。但是,主持人提出了这样一个问题:"编写优质无错代码是否必要?" 为什么呢?我稍微解释一下。在项目的时间很紧张的时候,是按期完成任务重要,还是代码的稳定性,优质无错重要呢?
主持人提出的四个具体问题是:
对于第一个问题,编写优质无错代码的代价当然是时间,不过随着编程人员的经验逐渐丰富,所需要的时间也逐渐减少。对于第二个问题,代码的质量比编写效率重要。当你花了1周时间写出来的代码需要你花一个月或者更长的时间去debug, 去修改错误,这种效率的损失是得不偿失的。对于第三个问题, 这需要看项目经理或者产品经理的态度和专业精神了。如果在一个专业的项目经理或者产品经理的指挥下,当然是首先保证质量其次提高效率。而对于某些项目经理或者产品经理来说,按时完成任务是最重要的,他们往往不在乎在软件发布之后花比开发时间长得多的时间去修改程序,维护错误。因为,对于他们来说,首先是要完成任务,好给上级领导交差,至于后期维护,就是另外一个任务了,维护花的时间多,正说明了他这个项目的复杂性和难度。而对于开发人员来讲,所希望的则正好相反。开发人员不喜欢花太多的时间在一个烂摊子上。所以,在讨论会上,大家纷纷表示,应该让项目经理或者产品经理也来听一听这个讨论会:-)。
对于第四个问题,当然优质无错代码不是意味着效率的降低,而是正好相反,对提高效率有很好的促进作用。一个版本发布之后,如果因为错误太多,开发人员不得不去花很多时间修改bug, 甚至要从系统的体系结构方面去做大的改动,重新编写部分代码,这种效率的降低才是更大,更不能承受的。而且,花了太多的时间在老版本的维护上,必然影响到新版本的工程进度,直接影响到整个产品线的质量和进度,严重的甚至会毁掉整个产品。
对于这一个主题,我的回答是,在时间允许的范围之内,尽量提高代码的质量,不追求慢工出细活,不追求代码的100%无错,但是要保证99%以上的无错。这样,在时间的压力下,在质量要求的束缚下,就要求程序员有一个良好的习惯,和稳健的编程风格,以保证代码的优质无错。这就是第二个问题:什么是编写优质无错的代码的核心思想?优质无错是相对的,而不是绝对的。任何代码,都不可能说是绝对无错的,但是在绝大部分情况下,是稳定的,强健的,优质的,无错的。每次发布的时候,都会对上次的发布版本做若干修改,增强功能的同时,也要修改若干bug。那么,核心思想就是:怎样才能自动地查出这个错误。怎样才能避免这个错误。
3.编写优质无错代码的经验
在说了上面很多理论性的问题之后,来看一看具体问题。先来看一看一个具体的题目:(我本人就是先在网上看了这个题目,才对这个讨论会发生兴趣的)
作为开发团队的一员,你需要实现一些库函数提供给其他人使用。假设你实现的一个函数原型如下:
int DoSomeThing(char* pParam)你们约定好参数pParam不能为NULL,但为了防止调用者错误传递NULL,你需要在你的函数里做判断处理。
请问你会选择那种方式,并说明原因?
(a) if (!pParam)关于这个问题,大概是所有的程序员都会遇到的。所以,在网上和讨论会上,都发生了激烈的争论和意见交换。我大概把主要的几种观点记录了一下,列举在下面:
因为非NULL是约定,所以可以确定是调用者的问题,f可以明确地指出这一点,防止错误扩散。
我的附加说明: 防止错误扩散的意思是,如果用其他方式,比如throw exception的方式,这个异常不一定会在调用此函数的上一层被捕捉到,可能会被继续抛出直到最上一层或者直到在某一层被catch到,这样的话,错误就会距离发生地点很远,扩散开来。这一观点,代表了一大部分的程序员的观点。
不赞成assert, assert更重要的作用是程序体里面的一个注释, 在阅读程序的时候起作用不能依赖他来检测错误, 很大程度上assert容易使使用者依赖它本不应该依赖的东西。
这也代表了部分程序员的观点,认为assert是不可依赖的,而应该依赖于错误检测,比如返回值或者异常。
f和d都可取。如果没有系统开销的考虑,d则更好些。可以一举两得。如果没人catch这个exception,其结果就跟f一样,按bug处理,dump core留下一stack trace。如果有人catch,那就按运行错误处理......但是返回一特初值表示错误,只是将错误上交,掩耳盗铃而已。最终总得有个人assert,messagebox,throw exception,perror+exit,或别得什么的。既然已经是约定,就干脆付起责任。
不可用d, 这就像你用人,却不相信人一样,偏要try,catch防范他。其实那个错是自己造成的,如果看到异常就容易不检讨自己。
讨论过程中,有人认为assert检查的是bug, 而异常是可以恢复的意外情况。所以,观点3的支持者说:可恢复的意外是可以理解的,但可恢复的bug就没什么意义了。既然已经约定好了,你再违背,就属于是bug而不是意外了(比如打不开文件什么的)。很多库函数都不检查指针的合法性(除了系统调用以外,因为总不能让系统dump core吧),也不检查指针是否为NULL(因为如果层层都检查,必定劳民伤财,干脆让最上面调用的人在调用之外查)。
选f+d, 好处如下:
如果在现实中,测试没有能找到所有的BUG,那可能就要用异常来帮忙了!
当然,我也提出了我的观点, 我支持观点6。理由如下:
assert只在debug标志的时候有用,而在编译release版本的时候不起作用。assert对于检查硬编码的错误,是非常有用的,能够及时的查处编码的错误。比如borland c++的类库源代码中就有很多这样的assert。但是assert不是万能的,因为有很多错误的发生不是完全在编译时发生的,而是运行时的错误。在release后,assert是不可能依赖的。那么,我们就需要exception这一机制来检测运行时错误,并相应的做出处理。当然,在异常检测和处理过程中还有许多需要讨论的问题,由于不是这一题目的范围,我们没有必要继续讨论得太多,但是,提出来希望大家注意:异常不是捕获了就完成任务了,而要对于不同的情况,采取不同的处理办法,千万不能只是捕获,而不做任何处理,那样和不捕获异常没有任何区别。
在题目刚刚提出的时候,选择各种答案的人都有,所以,我有必要在这里把其他答案为什么不能选的理由说一下。
(a) if (!pParam)这是很多初级程序员常常采取的一种方式。返回值设为0。 因为函数的返回值往往是计算的结果,不赞成把错误标志值和计算结果混在一起使用,容易造成使用者的误会。当然,在很多unix函数中,由于历史原因,还存在很多这样子的函数,所以需要指出,不要沿用这种方式。
(b) if (!pParam)b比a稍微好一点点,返回了一个常量或者预定义的宏。 从返回值的字面上,调用者能知道发生了什么错误,但是,这也不是一种好的方法。
(c) if (!pParam)这是最不好的方式。直接给pParam赋予空字符串,然后继续函数过程,这容易造成不可预料的后果,是程序不稳定的根源。
(d) if (!pParam)抛出异常,刚刚已经讨论过了,不再赘述。
(e) if (!pParam)这是一种比较可笑的方式,当然也有不少人用。MessageBox是直接弹出一个对话框,告诉使用者,出错了。但是并不做任何处理,程序继续往下执行,直到出错崩溃。呵呵
(f) assert(!pParam);断言,刚刚已经讨论过了,不再赘述。
以上这个题目,引发了所有与会者的兴趣,讨论异常热烈,最后,主持人也给出了自己的观点:d+f。当然这并不是标准答案,因为编程这一门课程本来就没有什么标准答案,大家见仁见智,这个答案只是经验的积累。
主持人紧接着列出了"编写优质无错代码的经验":
以上是本节的主要内容。断言,刚刚的问题中已经讨论过了,来看看其他的内容。
下面memcpy函数实现有什么问题:
Void *memcpy(void *pvTo,void *pvFrom,size_t size){呵呵,粗略一看,这函数还真找不出问题来。但是仔细看看,你就会发现while(size -- >0);
这里多了一个分号,导致下面的*pbTo++= *pbFrom++;不是在while循环中执行多次,而是只执行了一次。当然这不是函数设计者的预期结果,而编译器却不会报告错误,因为while(size -- >0);从语法上来讲,并没有错误。这就是理想的编译器和实际的编译器的区别所在。
那么,该怎么检查这种错误呢?主持人提出了如下办法:
while(size -- >0) NULL; 可以加入NULL来解决空语句.
这样子,当你需要 while(size -- >0) *pbTo++= *pbFrom++;
这种形式的时候,就不会发生错误了,只需要用眼睛看看,就能发现了。两点好处:无冗余代码,使人更明白。减少风险.
还有人会这么写
if( (n=read(....)) == 1) ....在这里,赋值符号=和判断相等的符号==容易敲错,而编译器又检查不出来,可能就会有如下错误:
If(ch = ‘ ’)...;这也是需要注意的问题。理想的编译器和实际的编译器小结:
下面函数实现,哪一个好,为什么?
a.分析:
a.该函数检查ch是否在A..Z之间,如果是,则返回相应的小写字符,如果不是,则返回-1。缺点在于:把错误标志值和计算结果混在一起使用,容易造成使用者的误会。
b.该函数使用了断言,如果ch在A..Z之间则返回相应的小写字符,如果不是,断言会起作用,程序发生错误并退出。而最后一个return ch;则是在release的时候,如果不是A..Z之间,则返回原来的字符。但是,从书写效率上来说,这个函数稍微罗嗦了一点。因为它重复使用了断言和if判断。
c.该函数也使用了断言,返回相应大写字母的小写字母。
使用断言的好处:
断言使用举例:
void memcpy(void * pvTo,void *pvFrom,size_t size){使用断言的规则:
断言小结:
写到这里,我们初步探讨了编写优质无错代码的必要性,原则,和相关经验。
留几个练习题目,大家也参与一下讨论吧。
下面的memset函数实现有什么问题?
void *memset(void *pv, byte b, size_t size)下面的代码用memset将三个局部变量置为0,请问可能会有什么问题?
void DoSomeThing(...)定义结构如下:
typedef struct请问sizeof(stru)等于多少?并说明理由。
下面是C语言中两种if语句判断方式。请问哪种写法更好?为什么?
int n;下面的代码有什么问题?
void DoSomeThing(...)下面的代码有什么问题?
char *DoSomeThing(...)下面的代码有什么问题?
char *_strdup( const char *strSource )下面的代码有什么问题?并请给出正确的写法。
try{我敲字敲累了,告一段落吧。不过,讨论会并不止讨论了这些内容,还有很多内容我没有写完,比如,函数的界面, 编写代码的风险, 编程的态度等等问题。作为补充,我把讨论会的幻灯片修改成了文本版本,作为另外一篇文章放在这里,以便对这个话题感兴趣的网友们参考。有什么问题,欢迎来信 ariesram@linuxaid.com.cn 继续探讨。