WritingCleanCode讀书笔记.doc

【转载】《Writing clean code》读书笔记 转载自：/hopesophite/archive/2006/08/02/1010643.aspx 写在前面的话： 这两天看了《Writing Clean Code》，很受启发，感觉值得再读，于是整理了一点笔记，作为checklist，以备速查。 原书共8章，每章都举一些例子，指出不足，再用通用的规则改写，每章结束时会总结一下要点，其中覆盖了比较重要的规则。附录A是作者整理的编码检查表。本笔记前8章和原书前8章对应，列出了所有的规则，对比较特别或者比较难理解的规则还附上了书中的例子，偶尔加一两句个人的想法。第9章是原书各章末尾要点的汇总。第10章是原书的编码检查表。 本笔记只作为原书的一个速查手册，详细的内容请看原书。 中译本： 《编程精粹 ─── Microsoft 编写优质无错C 程序秘诀》Steve Maguire 著，姜静波 佟金荣 译，麦中凡 校，电子工业出版社 英文版： 《Writing Clean Code ── Microsoft Techniques for Developing Bug-free C Programs》Steve maguire, Microsoft Press 英文版原名： 《Writing Solid Code ── Microsoft Techniques for Developing Bug-free C Programs》Steve maguire, Microsoft Press 1 假想的编译程序 1.1 使用编译程序所有的可选警告设施 1.2 使用lint 来查出编译程序漏掉的错误 1.3 如果有单元测试，就进行单元测试 1.4 Tips C 的预处理程序也可能引起某些意想不到的结果。例如，宏UINT_MAX 定义在limit.h 中，但假如在程序中忘了include 这个头文件，下面的伪指令就会无声无息地失败， 因为预处理程序会把预定义的UINT_MAX 替换成0： #if UINT_MAX 65535u … #endif 怎样使预处理程序报告出这一错误？ 2 构造自己的断言 2.1 既要维护程序的交付版本，又要维护程序的调试版本 少用预处理程序，那样会喧宾夺主，尝试用断言 2.2 断言是进行调试检查的简单方法。要使用断言捕捉不应该发生的非法情况。不要混淆非法情况与错误情况之间的区别，后者是在最终产品中必须处理的。 这是断言和错误处理的区别 2.3 要使用断言对函数参数进行确认 2.4 要从程序中删去无定义的特性或者在程序中使用断言来检查出无定义特性的非法使用 这个对C/C++很适用 2.5 不要浪费别人的时间 ─── 详细说明不清楚的断言 森林中只标有“危险”，而没指出具体是什么危险的指示牌将会被忽略。 2.6 断言不是用来检查错误的 当程序员刚开始使用断言时，有时会错误地利用断言去检查真正地错误，而不去检查非 法的况。看看在下面的函数strdup 中的两个断言： char* strdup(char* str) { char* strNew; ASSERT(str != NULL); strNew = (char*)malloc(strlen(str)+1); ASSERT(strNew != NULL); strcpy(strNew, str); return(strNew); } 第一个断言的用法是正确的，因为它被用来检查在该程序正常工作时绝不应该发生的非 法情况。第二个断言的用法相当不同，它所测试的是错误情况，是在其最终产品中肯定会出 现并且必须对其进行处理的错误情况。 2.7 用断言消除所做的隐式假定，或者利用断言检查其正确性 Eg. 对于和机器相关的内存填充程序，不必也无法将其写成可移植的。可以用条件编译。但其中应该对某种机器的隐含假设做检查。 2.8 利用断言来检查不可能发生的情况 压缩程序的例子：正常情况和特殊情况，重复次数=4或者就等于1 2.9 在进行防错性程序设计时，不要隐瞒错误 2.10 要利用不同的算法对程序的结果进行确认 2.11 不要等待错误发生，要使用初始检查程序 2.12 Tips 不要把真正需要执行的语句放在断言里 3 为子系统设防 3.1 要消除随机特性 ─── 使错误可再现 3.2 冲掉无用的信息，以免被错误地使用 分配内存时填充上非法值：eg. 68000 用0xA3，Intel X86系列用0xCC 释放内存时立刻填上非法值 引申：这个和《代码大全》中讲的进攻式编程观点类似 3.3 如果某件事甚少发生的话，设法使其经常发生 eg. 让realloc函数中移动内存块这种比较少发生的事情经常发生－－自己包装一个relloc。 3.4 保存调试信息到日志，以便进行更强的错误检查