《如何撰寫零錯誤程式》——读书笔记
1. 我们很不愿相信自己亲手写出的程序还会有错误的存在，然而它却时常存在，不要轻易做出承诺说所写的程序没有错误的存在。——p0缘起走过错误的历程
2. 程序不可能做到完全测试，但是作为程序的编写者，应当承担起基本的单元测试的责任，减少错误的发生。——p6
3. 命名方式尽量做到见名知意——p17
4. 不能太依赖黑盒测试，加入白盒测试。——p26
5. 对于while兜圈的问题，一个集成的开发环境或者一个良好的编码环境配置，例如自动缩进的配置，便可以减少此类错误的发生——p28
6. “危险的 == 与 = ”，书写经验和习惯或许会改变此类错误的发生次数，如书中提到的书写方法，用if(‘\t’==ch) 替代if(ch==’\t’)。——p31
7. 函数原型的撰写和函数功能的注释应该会减少查错的时间。——p34
8. “投资者永远不放弃任何希望，即使机会再小，他也会尽力去争取利益”，对于在写程序时开启所有的警告，单元测试过程中消除所有的警告都会使程序的出错几率减少很多。—— p38
9. 在系统集成前，应确保单元测试已经被执行！尽量避免因单元测试不通过而影响系统集成出错的问题——p41
10. “strCopy = memcpy(malloc(length), str ,length);”逻辑错误往往是隐藏着的，在涉及内存操作的时候一定要小心使用，分配后要注意内存分配是否成功——p48
11. 对于p50-p52两段程序,以及之后的断言（assert），只建议说在出错阶段才检查，而正式发行时既是不检查，那如何保证正式发行时不会出现为空的呢？——p51,p52
12. 要善于利用断言查指针错误。——p61
13. C 语言遵循强制类型，也就是必须先定义后使用的规定，所以一切变量必须是先定义后使用，内存必须是先申请后使用。不过要注意一点的就是内存映射！——p62
14. 详细的注释也是加速找出bug的一个重要技巧——p 68
15. 对于涉及指针偏移量问题和可移植问题，最好取用标准的长度，或者对标准进行求值取用——p80
16. 应当“尽早地和不断地进行软件测试“——p104
17. “出错毕竟是程式师自己的责任，如果没有这样的共识，还是早日转行，找一份比较轻松的工作，不要给别人制造麻烦“——p106
18. 可以在写出程序后依照逐行查验的方式审核一遍自己写的程序，或者模拟运行一遍，降低错误的发生——p106
19.
20. “主动发现潜伏的错误”针对内存的操作，我们在使用时应该对分配和释放的函数采用成对的使用方式，即写一个申请操作，即要写一个释放操作，并且尽量不要跨域释放——p166
21. “出错最好的方法，就是让错误的部分由机会执行，再根据它的过程来庞端问题的根源”——p188
22. “子系统完整性测试”，即提醒我们在编写程序的时候要做到高内聚，低耦合。——p188
23. 对于逐步追踪的方式出错，也就相当于调试中常采用的标记打印法，期望的都是能够在写完程序时便尽量的减少错误的存在——p206
24. “别忘了&&、 ||、 ？、！=等运算符”也就是在检查我们的程序时要特别注意逻辑部分的分流——p207
25. “一个好函数不仅本身不能有错误，而且必须避免造成使用者的错误”——p211
26. 对于getchar()函数提醒我们一定要注意类型的取值范围，避免出现益处的问题！——p213
27. “不能一味的想用一个函数来涵盖子系统的所有功能”，应该踩用每个子系统应该完成一个任务的形式编写函数——p226
28. “如果发现自己定义的函数也想tolower一样以一个传回值当成错误信息，最好仔细想想，是否可以用其它的方式来改写此函数，以避免这种情况发生”，这也就相当于我们在调用C标准函数库时经常可以看见的链式表达式，这可以方便的让我们快速写出简单却功能强大的句子！
29. 对于“if(fseek(fpDocument,offset,0) == 0)”这类函数的写法，我们应该避免，而踩用宏定义的形式定义，方便每一位调用者都能清楚的知道每个参数所代表的意思！——p242
30. “就像从悬崖顶端要回到地面一样，最快的方法就是两眼一闭，往下一蹬，也不管什么危险不危险，反正快嘛！”就像是悬崖边竖立着一个warning的牌子，但还是很多人掉下去一样！程序员应该有一个基本的素养，就是不能放过任何一个异常的现象，因为那背后一定有原因，很可能比想象的要大！——p258

31.
32. “size_t”本身这是一个不带正负号的值，一旦size的值减少到0，如果再继续减1，便会发生不足位的现象，进而将size重设为它所能代表的最大值！——p274
33. 危险习惯只多了那么一个特点，就是他们都没有直接反应出程序的需要，而且每当处理到特殊的状况时，就会毫不客气的给我们一些错误的结果。——p308
34. 所以如果能尽量在一个表示式里采用同一类的运算子，必定能减少很多发生错误的机会——P328
35. “若非必要，不要任意将不同类的运算混在一个式子里，万一必须将不同的运算放在一起使用，就用括号来表明运算的顺序”，“不要管原先的顺序对不对，用括号将所有需要的顺序标出来”——P330
36. “尤其当我们发现有一种方法可以明显的提升程序的效率，那就更要小心了，要记得天下没有白吃的午餐，有一得就要提放有一失，因为伴随效率而来的可能就是风险”——p336
37. “总之，不论我传给你的指针式用来输入或是输出，你一定要遵守规定，用来输入的资料只能用度。不能写，用来输出的变量则只能写，不能读”——p357
38. “需要多少才要多少”，对于内存的申请，我们应该做到用多少申请多少，用完之后及时释放——p359
39. “问题就发生在cmove的copy动作上，因为当fill将0写入第一位地址时，机械臂的第一个开关尚未回到0的位置”——p376
40. “当程序员不了解C的程序时如何转成机器码，而又想增进程序的效率时，通常就会尽量将原始的C程序写得更简短一些（此即APL症猴群）。不可否认的，原始程序的大小对编译后的程序的规模绝对会有影响，但是绝不是如一般人所想，只要每一行都写短一点，可执行程序就会变小！”——p382
41. “如果只顾着要程序又正确又快，结果却落得没有人看得懂，这样的程序可说是一点用处也没有。”，这也就是要求我们写出的程序不仅自己能看懂，交到别人的手上时，别人也要能看懂，并且利于今后的维护。——P388
42. “总之，根据定义，可维护的程序就是维护程序的人员能够很快的看懂，并且能轻易修改，而不会引起错误的程序”，写程序要尽量让一般人能看懂，也就是当我们去跟客户谈需求的时候，我们也一定要能够用简洁的程序语言确认客户的需求是否是我们理解的那样，或者帮助客户确认他自己都不明白的的需求！——p392
43.I P把全0保留为表示网络而全1表示网络内的广播地址
44.
45. 错误消失的三个可能原因：第一，错误报告原本就是错误；其次，报告上所写的错误早就由其他的程式师修改过了；最后，很可能错误原本就不是很明显，时好时坏——p404
46. “不要容许没有必要的弹性”也即是我们必须按照软件规格说明书来编写软件，不能随意的加上自己的想法，所有软件的功能必须是经过严格讨论并确定的。——p423
47. “不管如何，测试程序最佳的人选还是程式师自己”——p432
48. “其实即使测试员只负责挑出错误，我们还是不能放心的将出错的事完全交给他们去做。测试人员只会将输入丢进去系统，然后坐等潜伏的错误自动现行”——p433
49. 要记住一点，我们的错误早晚会随着软件一同出售，对我们及公司都将造成极大的伤害，这就好日本丰田公司经常出现的汽车召回一样，都是因为出现了一些微小的设计错误，然后造成了之后的大量汽车召回，也就造成了巨大的损失！——p436
50. “采用原始何曾是控制管理员”，也即在我们编写程序的时候要尽量采用版本控制器，控制程序的版本，防止修改后发现有错误，不能正常运行，却又无法修改回原来的版本——p450
51. 不要让同一个错误有再次出现的机会——p451

變數 bian shu
儘管 jinguan
繞口 raokou
名稱 mingcheng
傳 zhuan
幾個 jige
採用 caiyong
創舉 chuangju
嚴格 yange
讀者 duzhe
根據 genju
認識 renshi
事實 shishi
豐富 fengfu
隨機抽樣 suijichouyang
極 ji
困擾 kunrao
影響 yingxiang
盡力 jinli
維護 weihu
記憶體 jiyiti
標準 biaozhun
核反應爐 hefanyingdui
解壓 jieya
偶爾 ouer
複雜 fuza
欄位 lanwei
組譯 zuyi

http://net.pku.edu.cn/~yhf/linux_c/

write by SDC\Arts Liang