编程精粹Writing Solid Code 读书笔记

Writing Solid Code读书笔记
引言
一、两个关键的问题
怎样才能自动地查出这个错误?
怎样才能避免这个错误?

二、规则
每条准则都有例外
第1章 假想的编译程序
使用编译程序所有的可选警告设施
使用lint来查出编译程序漏掉的错误
如果有单元测试,就进行单元测试
第2章 自己设计并使用断言
既要维护程序的交付版本,又要维护程序的调试版本
assert如果其参数的计算结果为假,就终止调用程序的执行
如果把assert作为函数,其调用就会引起不期望的内存或代码的兑换,因此作为宏。要记住,使用assert的程序员是要把它看成一个在任何系统状态下都可以安全使用的无害检测手段。
要使用断言对函数参数进行确认

1
#include<assert.h>

assert(表达式)//如果表达式不满足则会终止程序的执行
“无定义”意味着“要避开”:
要从程序中删去无定义的特性,或者在程序中使用断言来检查出无定义特性的非法使用
程序员没有什么好的办法可以确定其代码中的实际错误情况,错误只能慢慢地暴露出来
不要浪费别人的时间——详细说明不清楚的断言
消除所做的隐式假定,或者利用断言检查其正确性
利用断言来检查不可能发生的情况
在进行防错性程序设计时,不要隐瞒错误
要利用不同的算法对程序的结果进行确认
不要等待错误发生,要使用初始检查程序
一旦开始使用断言,也许就会发现程序中的错误会显著的增加

第3章 为子系统设防
要消除随机特性,使错误可再现
冲掉无用的信息,以免被错误地使用
如果某件事甚少发生的话,设法使其经常发生
保存调试信息,以便进行更强的错误检查
建立详尽的子系统检查并且经常地进行这些检查
仔细设计程序的测试代码,任何选择都应该经过考虑
努力做到透明的一致性的检查
不要把对交付版本的约束应用到相应的调试版本上,要用大小和速度来换取错误检查能力。

第4章 对程序进行逐条跟踪
不要等到出了错误再对程序进行逐条的跟踪,养成对程序进行逐条跟踪的好习惯
在对代码进行逐条跟踪时可以对错误的情况进行模拟
对每一条代码路径进行逐条的跟踪
对代码进行逐条跟踪所花的时间要比实现相应代码所花的时间少得多
数据流,程序的命脉:对代码进行逐条跟踪的作用是它可以使我们观察到数据在函数中的流动。
当对代码进行逐条跟踪时,要密切注视数据流
源级调试程序可能会隐藏执行的细节,对关键部分的代码要进行汇编指令级的逐条跟踪。

第5章 糖果机界面
要使用户不容易忽视错误情况,不要在正常的返回值中隐藏错误代码
要不遗余力地寻找并消除函数界面中的缺陷
不要编写多种功能集与于一身的函数,为了对参数进行更强的确认,要编写功能单一的函数。
一开始就要为函数的输入选择严格的定义,并最大限度地利用断言
不要模棱两可,要明确地定义函数的参数
编写函数使其在给定有效的输入情况下不会失败
使程序在调用点明了易懂,要避免布尔参数
编写注解突出可能的异常情况

第6章 风险事业
任何时候都不要使用“简单的”位域
使用有严格定义的数据类型
尽量用可移植的数据类型
经常反问:“这个变量表达式会上溢或下溢吗?”
尽可能精确地实现设计,近似地实现设计就可能出错
编写无错代码三条原则:
不要接受具有特殊意义的参数,例如NULL指针
按照设计来实现而不能近似地实现
努力使每个函数一次就完成任务即一个“任务”应一次完成
避免无关紧要的if语句
避免使用嵌套的“?:”运算符
在实现中,有时得支持特殊情况,为了避免特殊情况遍及整个函数,应该把处理特数据情况的代码独立出来。
每种特殊情况只能处理一次
避免使用有风险的语言惯用语
关心局部效率是不值得的,如果很注重效率的话,请集中于全局效率和算法的效率上,这样才会看到努力的效果。
如果有可能,就不要把不同类型的操作符混合使用;如果必须把不同类型操作符混合使用,就用括号把它们隔离开来。
不能毫无必要地将不同类型的操作符混合使用,如果必须将不同类型的操作符混合使用,就用括号把它们隔离开来。
避免调用返回错误的函数。

第7章 编码中的假象
只引用属于你自己的存储空间
只有系统才能有空闲的存储区,程序员不能拥有
指向输出的指针不是指向工作空间缓冲区的指针
不要利用静态(或全局)量存储区传递数据
不要写寄生函数
不要滥用程序设计语言
紧凑的C代码并不能保证得到高效的机器代码
程序员有两类读者:使用代码的用户和必须对代码进行更新的程序维护人员,所以为一般水平的程序员编写代码,编写直观的代码。

第8章 剩下来的就是态度问题
错误几乎不会“消失”
马上修正错误,不要推迟到最后
修改错误要治本,不要治表
除非关系产品的成败,否则不要整理代码
不要实现没有战略意义的特征
不设自由特征
不允许没有必要的灵活性
在找到正确的解法之前,不要一味地“试”,要花时间寻求正确的解
尽量编写和测试小块代码,即使测试代码会影响进度,也要坚持测试代码
测试代码的责任不在测试员身上,而是程序员自己的责任
程序员强调的是代码而测试员强调的是特征
不要责怪测试员发现了你的错误
建立自己的优先级列表并坚持之
后记 走向何方
决不允许同样错误出现两次

猜你喜欢

转载自www.cnblogs.com/LearnFromNow/p/9345400.html