EEPW论坛

　　建议1：不要说服自己相信“皇帝的新装”

　　有的错误极具伪装性和欺骗性。

　　建议2：直接了当地表明意图

　　但编写代码的本意是希望表达某个意思，但这些代码有可能被误解为另一种意思时，请使用括号或者其它方式让你的意图尽可能清晰明了。这样做不仅有助你日后重读程序时能够更好地理解自己的用意，也方便了其它程序员日后维护你的代码。

　　建议3：考查最简单的特例

　　无论是构思程序的工作方式，还是测试程序的工作情况，这一原则都是适用的。这一原则还适用于程序的设计，在设计程序时，可以首先考虑一组输入数据全为空的情形，从最简单的特例中获得启发。

　　建议4：使用不对称边界

　　C语言中数组下标从0开始，各种计数错误的产生与这一点或多或少有关系。一旦了解了这个事实，处理这些计数错误就变得不那么困难了。

　　建议5：注意潜伏在按出的Bug

　　各种C语言实现之间，都存在着或多或少的细微差别。应该坚持只使用C语言只能够众所周知的部分，而避免使用那些“生僻”的语言特性。这样便于程序的移植工作，而且遭遇到编译器Bug的可能性也会大大降低。

　　建议6：防御性编程

　　对程序用户和编译器实现的假设不要过多。如果C编译器能够捕获到更多的编程错误，这当然不错。不幸的是，因为某些原因，要做到这一点很困难。

　　一个C语言编译器要做到严格检测程序中的各类错误，就要对程序中本意是可移植的部分做到严格的检测，同时对程序中那些需要完成与特定机器相关工作的部分网开一面。另外，某些类型的错误从本质上说是难于检测的。