代码大全《Code Complete》中文第一版阅读笔记

前阵花了点时间把《代码大全》Code Complete中文第一版看了一遍，把里面一些自己平时不太注意的，或者需要加强实践的地方摘了出来。建议大家可以把该从头到尾略读一遍，再根据自己的薄弱方面精读相应章节，目前《代码大全》已经出到第二版。

1、学会详细设计。在做一个项目、写程序之前进行详细设计，摒弃边想边写的做法。

很多人，在做一个项目前都不喜欢写详细设计，认为多此一举，浪费时间。我以前也是这么想的，一方面是觉得项目小或者根本称不上项目；另一方面，当觉得有必要写写文档的时候，最初还很认真的写写，写到中间，特别是遇到一些问题的时候就不想写了，有些东西通过文字也不太好表达。工作了，一开始也分不清基本、详细设计分别写什么东西，慢慢得写得多了，渐渐明白了两都之间的区别，当然对各自的作用也有了更深的理解，而且在写的过程中遇到的问题，也就是你写程序时会遇到的问题。

基本设计就是把一些功能模块列出来，模块之间的关系画一画；详细设计就要求把每个模块的实现都写出来，包括函数流程图、数据输入输出、函数变量命名、宏定义等，这样基本上两份文档也就出炉了。其实这个也就是要多写写，按文档来，以后就会了。

2、建立统一的错误处理。对于程序中的错误处理，做一个统一的错误处理模块，有助于出错处理。

这个吗，灵活运用吧，小项目上做个统一的错误处理模块开销还是比较大的。但是有一点，要提前为错误处理模块做好准备，比如在每处的错误处理模块上加个宏开关，以便Debug和Release切换。

3、非正式Code Check。代码写完后，尽力想什么因素可能破坏目前的模块，然后证明该情况不会发生。

这一点，我觉得根据不同的场合，不可能要求程序对出现的任何情况都能应付，一般把这一步放在单元测试中吧，单元测试可以用CUnit等自动化的测试框架进行；有条件的话可以在编码完成后使用静态编译工具PcLint(win)、SpLint(linux)进行测试下，如果能保证一个Waring都没有，那你的编程水平和编程风格那是相当地强；调试工具建议用GDB吧，在程序运行过程中动态修改变量值那是相当的强啊，这点我比较欣赏。

4、在确信正确之前不要编译。不要依赖编译器，赊望“下一次一定能成功”。

这个错误，我可以保证80%以上的人都会犯，即使是明知故犯，不多说了，相信我也改不了的，源于人的侥幸心理啊。

5、输入垃圾，不输出垃圾。程序的健状性在这里是作为优秀的程序应该总是能确保正确的输出。

要求对输入参数时行严格的Check，此处出现的问题应该能在单元测试中发现。

6、全局数据重入问题。子程序有重入问题，数据也有重入问题，防止数据在多个子程序中同时被改变。

多任务、多线程里典型的资源共享问题，加锁互斥访问。这里容易被忽视的是全局数据是资源、子程序是资源、子程序访问的全局变量也是资源，不要放过任何一个可以被多个进程、任务、同时访问的资源。

7、避免使用循环控制变量。尽量不要将循环控制变量用到其它程序的判断和使用中去。

这里说的重复使用，不是指循环完成后，把控制变量清零再计数等，而是指使用控制变量的记录的循环次数，放入到其它判断语句中去运用，最好添加其它Flag来进行判断吧。

8、合理使用递归。使用递归能使算法程序减化，但必需保证递归能中断退出。

递归使用要求比较高，难用，但用好了事半功倍，而且有些地方还只能用递归，如下某知名公司面试题：实现函数long strlen(char *p)，要求不使用任何变量。诸如此类的问题，当然就该题目而言是毫无意义的，花时间研究这东西不值得，即使研究出来用在程序中，影响阅读、降低效率也是没必要的。