代码检查、走查与评审
3.1、代码检查与走查
代码检查与走查都要求人们组成一个小组来阅读或直观检查特定的程序。
优点：一旦发现错误，通常就能在代码中对其进行精确定位，这就降低了调试（错误修正）的成本。另外，这个过程通常发现成批的错误，这样的错误就可以一同得到修正。修改一个现存的程序比编写一个新程序更容易产生错误。
3.2、代码检查
所谓代码检查，是以组委单位阅读代码，它是一系列规程和错误检查技术的集合，对代码检查的大多数讨论都集中在规程、所要填写的表格等。
四人组：
协调人职责：
为代码检查分发材料、安排进程
在代码检查中起主导作用
记录发现的所有错误
确保所有错误随后得到改正
检查人员进行两项活动：
1、 由程序编码人员逐条语句讲述程序的逻辑结构。
2、 对着历来常见的编码错误列表分析程序
有益：
程序员通常会得到编程风格、算法选择及编程技术等方面的反馈信息。早期发现程序中最易出错的部分的方法之一。
3.3、用于代码检查的错误列表
1、数据引用错误
1、是否有引用的变量为赋值或未初始化？
2、对于所有的数组引用，是否每一个下标的值都在相应维规定的界限之内
3、对于所有的数组引用，是否每一个下标的值都是整数？
4、对于所有的通过指针或引用变量的引用，当前引用的内存单元是否分配
这就是所谓的“虚调用（dangling reference）”错误：当指针的生命期大于所引用内存单元的生命期时，错误就会发生。当指针引用了过程中的一个局部变量，而指针的值又被赋给一个输出参数或一个全局变量，过程返回（释放了引用的内存单元）结束，而后程序试图使用指针的值时，这种错误就会发生。
5、如果一个内存区域具有不同属性的别名，当通过别名进行引用时，内存区域中的数据值是否具有正确的属性？
6、变量值的类型或属性是否与编译器所预期的一致？
7、在使用的计算机上，当内存分配的单元小于内存可寻址的单元大小时，是否存在直接或间接的寻址错误？
8、当使用指针或引用变量时，被引用的内存的属性是否与编译器所预期的一致？
9、假如一个数据结构在多个过程或子程序中被引用，那么每个过程或子程序对该结构的定义是否都相同？
10、如果字符串有索引，当对数组进行索引操作或下标引用，字符串的边界取值是否有“仅差一个（off-by-one）”的错误？
11、对于面向对象的语言，是否所有的继承需求都在实现类中得到了满足？
2、数据声明错误
1、是否所有的变量都进行了明确的声明？
没有明确的声明虽然不一定是错误，但通常确实麻烦的源头，另外，如果某个变量在一个内部过程或程序块中没有明确声明，是否可以理解为该变量在这个程序块中被共用？
2、如果变量所有的属性在声明中没有明确说明，那么默认的属性能否被正确理解？
3、如果变量在声明语句中被初始化，那么它的初始化是否正确？
4、是否每个变量都被赋予了正确的长度和数据类型？
5、变量的初始化是否与其存储空间的类型一致？
6、是否存在着相似的名称的变量？
3、运算错误
1、是否存在不一致的数据类型（如非算术类型）的变量间的运算？
2、是否有混合模式的运算？
3、是否有相同的数据类型，不同字长变量间的运算？
4、赋值语句的目标变量的数据类型是否小于右边表达式的数据类型或结果？
5、在表达式的运算中是否存在表达式向上或向下溢出的情况？也就是说，最终的结果看起来是个有效值，但中间结果对于编程语言的数据类型可能过大或过小。
6、除法运算中的除数是否可能为0？
7、如果计算机表达变量的基本方式是基于二进制的，那么运算结果是否不精确？也就是说，在一个二进制计算机上，10 X 0.1很少会等于1.0
8、在特定场合，变量的值是否超出了有意义的范围？
9、对于包含一个以上操作符的表达式，赋值顺序或操作符的优先顺序是否正确？
10、赋值的运算是否有使用不当的情况？尤其是除法？举例来说，如果i是一个整型变量，表达式2 X i / 2 == i是否成立，取决于i是奇数还是偶数，或是先运算乘法，还是先运算除法。
4、比较错误
1、是否有不同数据类型的变量之间的比较运算？
2、是否有混合模式的比较运算，或不同长度的变量间的比较运算？如果有，应去报程序能正确理解转换原则。
3、比较运算符是否正确？程序员经常混淆“至多”、“至少”、“大于”、“不小于”、“小于”和“等于”等比较关系。
4、每个布尔表达式所叙述的内容是否都正确？在编写涉及“与”、“或”和“非”的表达式时，程序员经常犯错。
5、布尔运算符的操作数是否是布尔类型的？比较运算符和布尔运算符是否错误地混在了一起？
6、在二进制的计算机上，是否有用二进制表示的小数点或浮点数的比较运算？由于四舍五入以及用二进制表示十进制数的近似度，这往往是错误的根源。
7、对于那些包含一个以上布尔运算符的表达式，赋值顺序以及运算符的优先顺序是否正确？
8、编译器计算布尔表达式的方式是否会对程序产生影响？
5、控制流程错误
1、如果程序包含多条分支路径，比如有计算GO TO的语句，索引变量的值是否会大于可能的分支数量？
2、是否所有的循环最终都终止了？
3、程序、模块或子程序是否最终都终止了？
4、由于实际情况没有满足循环的入口条件，循环体是否有可能从未执行过？如果确实发生这种情况，这里是否是一处遗漏？
5、如果循环同时由迭代变量和一个布尔条件所控制（如一个搜索循环），如果循环越界（fall-through）了，后果会如何？
6、是否存在“仅差一个”的错误，如迭代数量恰恰多一次或少一次？这在从0开始的循环中是常见的错误，我们会经常忘记将“0”作为一次计数。
7、如果编程语言中有语句组或代码块的概念，是否有不匹配的情况？
8、是否存在不能穷尽的判断？
6、接口错误
1、被调用模块接收到的形参（parameter）数量是否等于调用模块发送的实参（argument）数量？另外，顺序是否正确？
2、实参的属性（如数据类型和大小）是否与相应形参的属性相匹配？
3、实参的量纲是否与对应形参的量纲相匹配？
4、此模块传递给彼模块的实参数量，是否等于彼模块期望的形参数量？
5、此模块传递给彼模块的实参的属性，是否与彼模块相应形参的属性相匹配？
6、此模块传递给彼模块的实参的量纲，是否与彼模块相应形参的量纲相匹配？
7、如果调用了内置函数，实参的数量、属性、顺序是否正确？
8、如果某个模块或类有多个入口点，是否引用了与当前入口点无关的形参？
9、是否有子程序改变了某个原本仅为输入值的形参？
10、如果存在全局变量，在所有引用它们的模块中，它们的定义和属性是否相同？
11、常数是否以实参形式传递过?
7、输入/输出错误
1、如果对文件明确声明过，其属性是否正确？
2、打开文件的语句中各项属性的设置是否正确？
3、格式规范是否与I/O语句中的信息相吻合？
4、是否有足够的可用内存空间，来保留程序将读取的文件？
5、是否所有的文件在使用之前都打开了？
6、是否所有的文件在使用之后都关闭了？
7、是否有判断文件结束的条件，并正确处理？
8、对I/O出错情况处理是否正确？
9、任何打印或显示的文本信息中是否存在拼写或语法错误？
8、其他检查
1、如果编译器见了一个标识符交叉引用列表，那么对该类表进行检查，查看是否有变量从未应用过，或仅被引用一次。
2、如果编译器建立了一个属性列表，那么多对每个变量的属性进行检查，确保没有赋予过不希望的默认属性值。
3、如果程序编译通过了，但计算机提供了一个或多个“警告”或“提示”信息，应对此逐一进行认真检查，“警告”信息指出编译器对程序某些操作的正确性有所怀疑，所有这些疑问都应进行检查。“提示”信息可能会罗列出没有声明的变量，或者是不利于代码优化的用法。
4、程序或模块是否具有足够的鲁棒性？也就是说，它是否对其输入的合法性进行了检查？
5、程序是否遗漏了某个功能？
3.4、代码走查
代码走查与代码检查很相似，都是以小组为单位进行代码阅读，是一系列规
程和错误检查技术的集合。
3.5、桌面检查
3.6、同行评分
同行评分是一种依据程序整体质量、可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术，该项技术的目的是为程序员提供自我评价得手段。
程序是否易于理解？
