0. 引言1. 代码检视的指导思想2. 代码检视的内容

http://www.distorage.com/code-review%E5%B0%8F%E8%AE%BA/http://www.ibm.com/developerworks/cn/rational/11-proven-practices-for-peer-review/

1. 一次评审少于 200–400 行的代码。2. 目标为每小时低于 300–500 LOC 的检查速率。3. 花足够的时间进行正确缓慢的评审，但是不要超过 60–90 分钟。4. 确定代码开发者在评审开始之前就已经注释了源代码。5. 为代码评审和获取制度建立可定量化的目标，这样您才能改进流程。6. 使用检查列表，因为它可以极大地改进代码开发者和评审者的作品。7. 确认缺陷确实得到修复了。8. 培养良好的代码评审文化氛围，在这样的氛围中搜索缺陷被看做是积极的活动。9. 警惕"老大"效应。10. 最少评审一部分代码，就是您不能评审全部的代码，以从 Ego Effect 中受益。11. 采用轻量级，能用工具支持的代码评审。

1. 每小时小于 400 LOC 的评审速度下，效率是相对较高的2. 每小时超过 400 LOC 的评审速度会降低效率

永远不要对一个原型代码评审超过 60-90 分钟

1. "将支持访问降低 20%"2. "使开发引入的缺陷百分比减半"

1. 支持性访问将不会得到影响，直到新的版本得到发布并交到客户手中为止

使用检测表对于评审员非常重要，如果代码开发者忘记了某项任务，评审员也同样可能忘记

1. 使用检查表来避免可能会忘记的事情，它对代码开发者和评审者都有用。忽略是最难发现的缺陷2. 评审不在那里的东西是很困难的一件事。检查表是解决这个问题的最好方式，因为它会提醒评审者和代码开发者花点时间去考虑一下可能被遗忘的事情3. 检查表还会提醒代码开发者和评审者确定    1) 所有的错误(bug)都得到了处理    2) 软件功能已经通过了无效值测验    3) 而且已经创建了单元测试

1. 尽可能多的消除缺陷，不管是谁"导致"了错误(bug)2. 管理人员必须建立缺陷是积极的这样的观点。毕竟，每一个缺陷的存在，都是改进代码的潜在机会，而错误(bug)评审过程的目的，就在于使代码尽可能地完美。每一个被发现并解决的缺陷，都是客户以后不会看到的缺陷，也是 QA 
人员不必花费时间去解决的问题3. 团队需要维持这样一种态度，就是发现缺陷，就意味着代码开发者和评审者 作为一个团队 去改进产品的质量成功了。而不是"代码开发者产生了一个缺陷，而评审者负责去发现它"。它更像是配对编程的一种有效形式。4. 评审员要向所有的开发者展示收集坏习惯，学习新技巧，并展开功能的机会。开发员可以从他们的错误(bug)中学习，但是只是在他们警惕错误(bug)时才会这样。如果开发员害怕发现错误(bug)，那么积极的结果就会消失。5. 如果您是一名初级开发员，或者是一个团队的新成员，那么其他人发现缺陷时，就意味着您强有力的队友在帮助您成长为一个合格的开发员。这就比您单枪匹马地编程，没有具体的反馈时，要更快地进步

1. 与详细设计方案的一致性只要将检视的代码对照详细设计进行比较就很容易检查出代码是否和详细设计一致，采用逐行逐字阅读进行比较的方法进行。2. 头文件检查头文件检查主要关注以下方面：    1) 是否包含有多余的其他头文件    2) 头文件是否内聚，即是否多个模块共用一个头文件    3) 头文件内的内容是否清晰，是否分类排放好并给出了足够的注释    4) 是否使用了象 #ifdef __LIST_H__ 之类的宏定义保证头文件不被重复引用3. 宏定义检查    1) 宏定义中有参数和表达式时，参数和表达式是否都用括号括起来了。例如：    #define ADD(a, b) (a + b) //正确的应该是 ((a) + (b))    这个定义中就没有将参数a和b括起来，如果使用时a和b是表达式的话，就会因为运算符顺序问题而出问题。    2) 续行符\是否使用正确4. 常量常量方面主要检查的主要问题如下：    1) 常量是否使用了宏来进行定义    2) 程序中是否存在魔鬼数字    3) 16进制数据是否在前面加上了0x    4) 常量是否来自规格    5) 不来自规格的常量的值是否合理5. 全局变量与共享变量需要检查的主要问题如下：    1) 全局变量是否必须的，是否可以改成局部变量    2) 是否有全局范围内变量和局部范围内变量重名情况    3) 是否有多个任务访问共享变量，是否进行了有效的保护    4) 当全局变量只限于本文件内使用时，是否定义成静态的    5) 多个任务读写共享变量时，是否可以将读写操作封装成独立函数，而不是在每个模块里都进行加锁解锁操作6. 静态变量和函数静态变量和函数检视时主要问题如下：    1) 静态变量的使用是否正确    2) 每次使用静态变量时是否需要重新初始化    3) 对不需要重新初始化的静态变量在多次使用后是否有溢出的问题。    4) 文件内部使用的函数是否要定义成静态的7. 数据结构数据结构方面考虑的主要问题如下：    1) 数据结构里的成员类型定义是否正确    2) 结构体里面变量顺序安排是否合理，数据是否对齐    3) 是否存在冗余未用的成员变量。    4) 类里面是否有私有变量和私有函数放到了公有的定义里去了8. 初始化初始化考虑的主要问题如下：    1) 变量使用前是否需要初始化    2) 类的构造函数中是否对需要初始化的成员都进行了初始化    3) 数组的初始化是否正确    4) 内存或数组在每次使用前是否需要初始化清零    5) 多个变量初始化赋值时是否存在顺序问题    6) 静态变量和全局变量的初始化是否存在初始化顺序问题9. 字符串    1) 字符串是否以‘\0‘结尾    2) 字符串是否会超长    3) 字符串使用的空间大小是否存在差1问题    4) 使用字符串指针时，指向的位置是否存在差1问题    5) 字符串指针是否可以为空，为空时会有什么现象     6) 字符串内容为空(即第一个字符为‘\0‘)时会发生什么现象     7) 字符串中如果有转义字符"\"字符时，是否正确地写成了"\\"    8) 在对字符串进行拷贝或连接操作时，是否对空间大小进行校验，防止出现缓冲区溢出10. 输入检查输入校验需要检视的主要问题如下：    1) 函数参数是否需要进行检查    2) 从文件读取的数据是否进行校验    3) 使用全局数据时是否需要进行校验    4) 通信收到的数据是否需要进行校验    5) 从消息中接受到的数据是否需要进行校验11. 边界条件凡是牵涉边界条件的地方都需要进行边界检查，以下的一些问题供参考：    1) 循环变量上的边界是否正确    2) 变量的取值是否有边界条件限制，边界是否给出并书写正确    3) 空间边界，如内存大小，数组大小是否正确，是否存在差1和越界情况    4) 数据结构边界，如链表的头一条记录和最后一条记录等边界情况    5) 服务器连接数量最大是多少12. 内存分配和释放内存分配方面需要检查的有以下几点：    1) 分配的大小是否正确，是否分配了过大的内存或者分配的内存大小不足，分配的内存大小是否存在差1错误    2) 内存分配是否经过判断或者进行异常处理    3) 重新分配一块内存时，是否将原有内存释放    4) 分配的内存是否需要初始化清零    5) 是否有在大循环中不断分配内存导致可能出现系统内存不足情况释放方面需要检查的有以下几点：    1) 所有的分支路径上是否将分配的内存进行了释放    2) 是否将已经释放的内存重复释放    3) 释放的是否是空指针    4) 释放多块内存时是否存在释放的先后顺序问题使用realloc()时要考虑以下几点：    1) 新增空间是否需要初始化清零    2) 是否还有指针指向老的内存块，并在realloc()后使用指向老的内存块的指针。13. 类型转换类型转换的检查有以下问题供参考：    1) 类型转换是否采用安全的转换机制    2) 当采用强制转换时是否会出问题    3) signed 和 unsigned 转换是否存在问题    4) 是否将小空间的类型转换成了大空间的类型    5) 类型转换是否会造成截断、溢出或越界14. 数组使用数组的使用也是很容易出错的一种，不幸的是现在还没有足够好的方法能保证数组越界一类的问题得到完美的解决，所以通过对数组的检视来保证质量就很重要了，下面给出检视数组的一些建议：    1) 类型是否正确    2) 多维数组是否数据存放顺序正确    3) 数组使用时是否会越界，空间大小是否存在差1错误    4) 作用域是否正确    5) 数组大小是否太大导致浪费15. 指针使用指针在C/C++中是使用最广泛的一种语法，指针使得语言的功能强大起来，但也给程序质量带来了很大麻烦，使用指针时是极易出错的，可以说C/C++代码中的缺陷大部分都与指针有关，下面给出检视指针的一些问题参考：    1) 指针是否初始化    2) 指针类型定义是否正确    3) 使用前是否申请了内存    4) 引用是否正确，是否引用了释放掉的空间    5) 指向的空间是否正确    6) 是否存在使用野指针现象    7) 释放后再使用时是否需要重新初始化    8) 是否使用了空指针，函数指针是否为空就被调用    9) 指针是否需要校验    10) 指针进行类型转换时是否会引起问题    11) 指针地址运算是否有误，在地址相加时是否考虑了相加的数字要乘以指针类型所占空间的大小。比如int *p; p+1相比p的大小不是大于1，而是大于一个整数所占空间的字节数16. 函数函数方面的一些检视建议如下：    1) 函数调用的参数传递是否正确    2) 是否有形参和实参使用错误的问题    3) 函数的返回值和输出是否需要校验    4) 调用的函数是否对全局数据产生影响    5) 函数功能是否单一，是否在函数里处理了多个不同的功能    6) 函数参数是否需要定义为const    7) 函数是否过长(一般以不超过200行为宜)17. 系统和标准库调用调用系统函数和库函数时，以下一些检视建议供参考：    1) 系统调用是否正确，调用参数设置是否正确    2) 是否按照标准文档中的要求和注意事项进行了调用    3) 对于存在BUG的系统函数是否采取了规避措施进行调用    4) 对调用系统函数是否需要在调用前进行了输入校验    5) 调用后是否需要对输出进行校验18. 判断循环条件在程序中的判断和循环条件中，也存在着一些有时通过测试难以发现的问题，主要的检视建议如下：    1) 逻辑运算符是否正确，如| 和||，&和&&运算符是否搞混淆掉或键盘失误写错，    2) 逻辑等号==是否误写成等号=    3) 运算符顺序是否正确，运算符| 、&，||、&&，=、== 的运算顺序需要特别注意    4) 循环判断中的表达式是否正确地使用了括号将运算顺序区分开，并增加可读性    5) 表达式运算是否存在逻辑上的错误    6) 对浮点数是否误用了精确相等进行比较    7) 循环变量是否进行了初始化    8) 循环的中止条件是否在某些情况下无法到达而造成死循环    9) 循环的边界上是否会造成问题    10) 判断条件是否会恒真或恒假19. 计算计算错误也是程序中经常遇到的一个问题，大部分计算错误可以经过测试发现，但并不是所有的计算错误都可以很容易通过测试来发现，以下的一些问题供检视时参考：    1) 计算表达式或公式是否书写正确，需要逐字符地进行确认没有输入错误    2) 表达式中运算符顺序是否书写正确，同优先级运算符运算时是否存在自左至右结合或自右至左结合运算结果不同的问题    3) 是否需要使用括号来保证运算顺序的正确性和增加程序的可读性    4) 是否存在计算溢出情况，如两个整数相乘结果超出整数最大范围等情况    5) 截断误差和舍入误差是否会引起问题，误差是否会累积下去导致误差越来越大     6) 是否存在除零问题(零做分母的问题)，或者两个整数相除结果得到零然后再和其他整数相乘     7) 是否存在某个变量会累积增加导致长时间运行后的溢出20. 资源释放资源释放方面的一些检视建议如下：    1) 所有的资源是否都进行了释放    2) 要检查是否存在某条路径遗漏了释放    3) 句柄释放        3.1) 打开文件是否关闭了        3.2) 信号量是否释放        3.3) 句柄是否关闭        3.4) 锁资源是否释放        3.5) 是否存在死锁问题    4) 全局的资源是否存在随时间累积增加不减少的问题     5) 其他各种资源如网络socket等是否在各条对应路径上进行了关闭    6) 类的析构函数中是否对类中需要释放的成员进行了释放21、效率从空间和时间效率方面一些检视建议如下：    1) 多个if判断是否可以改为switch或if…else if结构     2) 多个相同处理的case语句是否归到一起    3) 在多重循环中，最忙的循环是否在最内层    4) 循环体内的判断语句是否可以移到循环体外