软件代码评审检查点--C-C++.docx

软件代码评审检查点 --C-C++ 文件结构审查 【检查点 1 】文件名是否和实际内容相符？ [ 规范性 ] 〖说明〗文件名应该清晰说明出该文件的功能和作用。 〖案例〗略 【检查点 2 】多个模块公用的定义和函数原型的说明是否放在 “*.h ” ？ 〖说明〗一般来说， *.h 文件是公用的头文件，文件中申明的宏、结构、函数原型等，一其他的模块需要引用。 〖案例〗略 【检查点 3 】私有的申明和函数原型的说明是否放在 “*.inc ” ？ 〖说明〗一般来说， *.inc 文件是私有的头文件。文件中申明的宏、结构、函数原型等，是仅供本模块使用。 〖案例〗略 【检查点 4 】头文件是否使用了 #ifndef#endif 宏开关来防止重复引用？ 〖说明〗一般来说，头文件通过如下方法避免重复引用： #ifndef _XXX_H_ #define _XXX_H_ /* 文件主体 */ #endif 【检查点 5 】函数原型是否没有明确申明返回值类型 〖说明〗虽然 C语言并不需要精确定义和声明函数返回类型，如果函数没有返回值，则定义为类型void 。如果函数没有定义返回类型，编译器将认为其返回类型为 int 。在这种情况，很难判断函数是否应该有返回值。为了避免这种情况，函数返回类型应该被定义和声明。 〖案例〗错误书写： SSfunction() ; 正确书写： void SSfunction() ; 预处理 【检查点 1 】宏定义是否缺少了 “( ) ” 符号？ 〖说明〗对于表达式的宏定义，注意要对 变量和表达式本身 使用“( ) ” ，防止宏展开时出错。 〖案例〗案例一 注意下面的宏定义极易出现问题： #define ADD(x, y) x + y 上面的宏在如下代码中出错： c = ADD(a, b) /2; 宏展开后的形式为： c = a + b /2; 而不是： c = (a + b) /2; 案例二 #define MULTI(x, y) x*y 在程序中代码如下： a = MULTI( b+c, 2); 宏展开后为： a = b + c * 2 ; 而不是： a = (b + c) * 2; 【检查点 2 】宏定义是否存在不期望或者意料之外的附加效应？ 〖说明〗宏是一个短行的文本 , 或者说文本模板 , 它可以被扩充为更长的文本 . 通常由宏产生的问题并不在宏定义本身 , 而往往由其下面的程序引起 . 采用宏可以使代码简化 , 但它也可能隐藏重要的细节和关键的操作. 〖案例〗 #define SQUARE ( x ) ( ( x ) * ( x ) ) . . . w = SQUARE ( ++ value ); 实际对宏 SQUAR的E 引用将导致 value 被增加两次 , 因为这个语句将被 C预处理器扩充以下形式 : w = ( ( + + value ) * ( + + value ) ); 【检查点 3 】是否存在通过定义宏来改变程序控制流程？ 〖说明〗通过定义宏来改变程序控制流程实际上是很糟糕的编程技巧 〖案例〗 错误形式 : #define FOR_ALL for ( i = 0; i size ; i ++ ) . . . /* Clear the C array */ FOR_ALL { c [ i ] = 0; } 【检查点 4 】在函数定义中使用条件预处理，所定义的标志所致使的代码差别是否很大？ 〖说明〗在函数定义中使用条件预处理只能用于程序中基于所定义的标志所致使的代码的轻微差别 . 大的差别应该由不同的函数来处理 . 〖案例〗 【检查点 5 】函数内部的条件预处理是否遍及整个函数？ 〖说明〗在函数定义中使用条件预处理只能用于程序中基于所定义的标志所致使的代码的轻微差别 . 大的差别应该由不同的函数来处理 . 〖案例〗 【检查点 6 】一个条件预处理是否使一个完整的 C 语句分为几段？ 〖说明〗不应该让一个条件预处理使一个完整的 C 语句分为几段 . 〖案例〗 错误形式 : if ( ( cond = = GLRUN ) #ifdef FEAT_A | | ( cond = = GLWAIT ) #endif ) { 正确形式 : #ifdef FEAT_A if ( cond = = GLRUN | | cond = = GLWAIT ) #else if ( cond = = GLRUN ) #endif { 【检查点 7 】 include 中是否包含了绝对路径？ 〖说明〗 #include 包含的文件路径应该是相对路径，不应该使用绝对路径，经常出现错误主要是带有盘符，带有根目录符号的写法。 〖案例〗以下使用方法在程序中应该禁止： #include c: \include\type.h