编写无错C程序_摘要

作者：juyib  出处：bbs.tsinghua.edu.cn  

1.    可以把屡次出错的合法的C习惯用法看成程序中的错误。
2.    空的循环加上“null”语句使其变为显式的。
3.    特别注意作为条件的赋值语句，例如while(*pchTo++ = *pchFrom++)
NULL;最好改写成显式的while( (*pchTo++ = *pchFrom++)!=’ \0’ )
NULL;
4.    如果用户想要检查出自己程序中的调用错误，必须自己建立原型，并随时使
其与相应的函数保持一致。如果在相应原型中使用更加精确的类型，就可以增强原型提
供的错误检查能力, 缺陷是常常必须进行参数的显式类型转换，以消除类型不匹配的错
误，即使参数的次序正确。
5.    选择编译程序的所有可选警告设施，并把这些措施看成是一种无风险高偿还
的程序投资。
6.    另一种检查错误更详细、更彻底的方法是使用lint。
7.    为什么不做单元测试呢？
8.    消除程序错误的最好方法是尽可能早、尽可能容易地发现错误，要寻求费力
最小的自动查错方法。
9.    除禁止在if语句中使用简单赋值的方法之外，能够查出这个错误的另一种众
所周知的方法是把赋值号两边的操作数颠倒过来：
if(‘\t’ == ch)
10.    程序中的测试代码使整个函数的大小增加，并且降低了该函数的执行速度。
聪明的程序员会将所有的调试代码隐藏在断言assert中。
11.    aasert是个只有定义了DEBUG才起作用的宏（而不是函数），如果其参数的计
算结果为假，就中止调用程序的执行。宏assert不应该弄乱内存，不应该对未初始化的
数据进行初始化，即它不应该产主其他的副作用。要记住，使用assert的程序员是把它
看成一个在任何系统状态下都可以安全使用的无害检测手段。
12.    一旦程序员学会了使用断言，就常常会对宏assert进行重定义。如果用户要
定义自己的断言宏，为不影响标准assert的使用，最好使用其它的名字。
13.    “无定义”意味着“要避开”：对于程序员来说，无定义的特性就相当于非
法的特征，因此要利用断言对其进行检查。这种做法在为其他的程序员提供代码库（或
操作系统）时显得特别重要。
14.    很少比跟踪到了一个程序中用到的断言，但却不知道该断言的作用这件事更
令人沮丧的了。更有甚者程序员偶尔还会设计出有错的断言。幸运的是，这个问题很好
解决，只要给不够清晰的断言加上注解即可。
15.    当程序员刚开始使用断言时，有时会错误地利用断言去检查真正地错误，而
不去检查非法情况。
16.    不是在任何情况下，都可以企图将你的函数写成一个可移植的函数的，要接
受其不可移植这一事实。此时可利用#ifdef  ***  #endif 来包含为特定体系结构所写
的代码。
17.    防错性程序设计常常被誉为有较好的编码风格，但它却隐瞒了错误。不过它
确实有价值。一个程序所能导致的最坏结果是执行崩溃，并使用户可能花几个小时建立
的数据全部丢掉。在非理想的世界中，程序确实会瘫痪，因此为了防止用户数据丢失而
采取的任何措施都是值得的。防错性性程序设计要实现的就是这个目标。
18.    在编码之前都要问自己：“在进行防错性程序设计时，程序中隐瞒错误了
吗？”如果答案是肯定的，就要在程序中加上相应的断言，以对这些错误进行报警。
19.    当子系统编写完成之后，要问自己：“程序员什么情况下会错误地使用这个
子系统，在这个子系统中怎样才能自动地检查出这些问题？”
20.    对于内存管理程序。程序员可能犯的错误是：
l 分配一个内存块并使用其中未经初始化的内容；
l 释放一个内存块但继续引用其中的内容；
l 调用realloc对一个内存块进行扩展，因此原来的内容发生了存储位置的变化，但程序
引用的仍是原来存储位置的内容；
l 分配一个内存块后即“失去”了它，因为没有保存指向所分配内存块的指针；
l 读写操作越过了所分配内存块的边界；
l 没有对错误情况进行检查。
21.    暴露错误的关键是消除错误发生的随机性。如何做到这一点要取决于具体的
子系统及其所涉及到的随机特性。但对于malloc来说，通过对其所分配的内存块进行填
充，就可以消除其随机性。当然，这种填充只应该用在程序的调试版本中。机器不同，
所选定和填充值也可能不同。
22.    使用#ifdef指令来除去调试用变量虽然使程序变得很难看，但这种用法可以
帮助我们消除一个产生潜在错误的根源