《编程精粹》摘录

1.假想的编译程序
1.1使用编译程序所有的可选警告设施：要把所有的警告开关都打开，除非
有极好的理由才不这样做。
1.2使用 lint 来查出编译程序漏掉的错误。
1.3如果有单元测试，就进行单元测试。

2.自己设计并使用断言
3.为子系统设防
3.1如果某件事甚少发生的话，设法使其经常发生：如果某事件很少发生并没有什么问题，只要在程序的交付版本和调试版本中不少发生就行。
3.2保存调试信息，以便进行更强的错误检查。
3.3仔细设计程序的测试代码，任何选择都应该经过考虑。

4.对程序进行逐条跟踪
4.1不要等到出了错误再对程序进行逐条的跟踪：在进行代码测试时，要对其代码进行遍查。
4.2对每一条代码路径进行逐条的跟踪：
4.2.1为了验证程序的正确性，至少要对程序中的每条指令逐条跟踪一遍。在做完了这件事之后，我们对程序中不含错误就有了更高的置信。至少我们知道对于某些输入，相应的程序肯定没错。如果测试用例选择得好，代码的逐条跟踪会使我们受益非浅.
4.2.2当对代码进行逐条跟踪时，要密切注视数据流。
4.3不要编写多种功能集于一身的函数为了对参数进行更强的确认，要编写功能单一的函数
4.4不要模棱两可，要明确地定义函数的参数
4.5编写函数使其在给定有效的输入情况下不会失败

6.风险
6.1经常反问：“这个变量表达式会上溢或下溢吗？”。
6.2每个函数只完成它自己的任务：一个“任务”应一次完成。
6.3避免无关紧要地 if 语句。
6.4不能毫无必要地将不用类型地操作符混合使用，如果必须将不同类型地操作符混合使用，就用括号把它们隔离开来。

7.编码中的假象
7.1不要利用静态（或全局）量存储区传递数据

8.剩下来的就是态度问题
8.1错误几乎不会“消失”:错误消失有三个原因：一是错误报告不对；二是错误已被
别的程序员改正了；三是这个错误依然存在但没有表现出来。
8.2马上修改错误，不要推迟到最后。
8.3修改错误要治本，不要治表。
8.4除非关系产品的成败，否则不要整理代码。
8.5把“冷门”特征打入冷宫。
8.6在找到正确的解法之前，不要一味地“试”，要花时间寻求正确的方法。
8.7测试代码的责任不在测试员身上，而是程序员自己的责任：不要依靠测试组来发现错误，因为这不是他们的工作，程序员测试代码，是从里向外测试，而测试员则是从外向里测试。
8.8不要责怪测试员发现了你的错误。
8.9决不允许同样错误出现两次。