软件编程规范总则CHECKLIST

《软件编程规范总则CHECKLIST》由会员分享，可在线阅读，更多相关《软件编程规范总则CHECKLIST（13页珍藏版）》请在金锄头文库上搜索。

1、软件编程规范总则CHECKLIST软件编程规范总则CHECKLIST 检 查 人：_ 检查日期：1999年_月_日 审查内容：_ 审查结果：通过 不通过 说 明：_ 序号 总 则 条 款 执行情况 说明 1 排版 1 1-1：程序块要采用缩进风格编写缩进的空格数为4个。 是 否 免 2 1-2：相对独立的程序块之间、变量说明之后必须加空行。 是 否 免 3 1-3：较长的语句（80字符）要分成多行书写长表达式要在低优先级操作符处划分新行操作符放在新行之首划分出的新行要进行适当的缩进使排版整齐语句可读。 是 否 免 4 1-4：循环、判断等语句中若有较长的表达式或语句则要进行适应的划分长表达式要

2、在低优先级操作符处划分新行操作符放在新行之首。 是 否 免 5 1-5：若函数或过程中的参数较长则要进行适当的划分。 是 否 免 6 1-6：不允许把多个短语句写在一行中即一行只写一条语句。 是 否 免 7 1-7：if、while、for、default、do等语句自占一行。 是 否 免 8 1-8：对齐只使用空格键不使用TAB键。 是 否 免 9 1-9：函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格case语句下的情况处理语句也要遵从语句缩进要求。 是 否 免 序号 总 则 条 款 执行情况 说明 10 1-10：程序块的分界符（如C/C+语言的大括号和）应各独占

3、一行并且位于同一列同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while0、switch、case语句中的程序都要采用如上的缩进方式。 是 否 免 11 1-11：在两个以上的关键字、变量、常量进行对等操作时它们之间的操作符之前、之后或者前后要加空格；进行非对等操作时如果是关系密切的立即操作符（如）后不应加空格。 是 否 免 2 注释 2-1：一般情况下源程序有效注释量必须在20以上。 是 否 免 2-2：说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释注释必须列出：版权说明、版本号、生成日

4、期、作者、内容、功能、与其它文件的关系、修改日志等头文件的注释中还应有函数功能简要说明。 是 否 免 2-3：源文件头部应进行注释列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 是 否 免 2-4：函数头部应进行注释列出：函数的目的/功能、输入参数、输出参数、返回值、调用关系（函数、表）等。 是 否 免 2-5：边写代码边注释修改代码同时修改相应的注释以保证注释与代码的一致性。不再有用的注释要删除。 是 否 免 2-6：注释的内容要清楚、明了含义准确防止注释二义性。 是 否 免 2-7：避免在注释中使用缩写特别是非常用缩写。 是 否 免 2-8：注释应与

5、其描述的代码相近对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置不可放在下面如放于上方则需与其上面的代码用空行隔开。 是 否 免 序号 总 则 条 款 执行情况 说明 2-9：对于所有有物理含义的变量、常量如果其命名不是充分自注释的在声明时都必须加以注释说明其物理含义。变量、常量、宏的注释应放在其上方相邻位置或右方。 是 否 免 2-10：数据结构声明(包括数组、结构、类、枚举等)如果其命名不是充分自注释的必须加以注释。对数据结构的注释应放在其上方相邻位置不可放在下面；对结构中的每个域的注释放在此域的右方。 是 否 免 2-11：全局变量要有较详细的注释包括对其功能、取值范围、哪些函

6、数或过程存取它以及存取时注意事项等的说明。 是 否 免 2-12：注释与所描述内容进行同样的缩排。 是 否 免 2-13：将注释与其上面的代码用空行隔开。 是 否 免 2-14：对变量的定义和分支语句（条件分支、循环语句等）必须编写注释。 是 否 免 2-15：对于switch语句下的case语句如果因为特殊情况需要处理完一个case后进入下一个case处理必须在该case语句处理完、下一个case语句前加上明确的注释。 是 否 免 3 标识符命名 3-1：标识符的命名要清晰、明了有明确含义同时使用完整的单词或大家基本可以理解的缩写避免使人产生误解。 是 否 免 3-2：命名中若使用特殊约定或

7、缩写则要有注释说明。 是 否 免 3-3：自己特有的命名风格要自始至终保持一致不可来回变化。 是 否 免 3-4：对于变量命名禁止取单个字符（如i、j、k.）建议除了要有具体含义外还能表明其变量类型、数据类型等但i、j、k作局部循环变量是允许的。 是 否 免 3-5：命名规范必须与所使用的系统风格保持一致并在同一项目中统一比如采用UNI_的全小写加下划线的风格或大小写混排的方式不要使用大小写与下划线混排的方式。 是 否 免 序号 总 则 条 款 执行情况 说明 4 可读性 4-1：注意运算符的优先级并用括号明确表达式的操作顺序避免使用默认优先级。 是 否 免 4-2：避免使用不易理解的数字用有

8、意义的标识来替代。涉及物理状态或者含有物理意义的常量不应直接使用数字必须用有意义的枚举或宏来代替。 是 否 免 5 变量 5-1：去掉没必要的公共变量。 是 否 免 5-2：仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。 5-3：明确公共变量与操作此公共变量的函数或过程的关系如访问、修改及创建等。 5-4：当向公共变量传递数据时要十分小心防止赋与不合理的值或越界等现象发生。 5-5：防止局部变量与公共变量同名。 5-6：严禁使用未经初始化的变量作为右值。 6 函数、过程 6-1：对所调用函数的错误返回码要仔细、全面地处理。 是 否 免 6-2：明确函数功能精确（而不是近似）地

9、实现函数设计。 是 否 免 6-3：编写可重入函数时应注意局部变量的使用(如编写C/C+语言的可重入函数时应使用auto即缺省态局部变量或寄存器变量)。 是 否 免 6-4：编写可重入函数时若使用全局变量则应通过关中断、信号量（即P、V操作）等手段对其加以保护。 是 否 免 7 可测性 7-1：在同一项目组或产品组内要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数并且要有详细的说明。 是 否 免 序号 总 则 条 款 执行情况 说明 7-2：在同一项目组或产品组内调测打印出的信息串的格式要有统一的形式。信息串中至少要有所在模块名（或源文件名）及行号。 是 否 免 7-3：编程的同

10、时要为单元测试选择恰当的测试点并仔细构造测试代码、测试用例同时给出明确的注释说明。测试代码部分应作为（模块中的）一个子模块以方便测试代码在模块中的安装与拆卸（通过调测开关）。 是 否 免 7-4：在进行集成测试/系统联调之前要构造好测试环境、测试项目及测试用例同时仔细分析并优化测试用例以提高测试效率。 是 否 免 7-5：使用断言来发现软件问题提高代码可测性。 是 否 免 7-6：用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。 是 否 免 7-7：不能用断言来检查最终产品肯定会出现且必须处理的错误情况。 是 否 免 7-8：对较复杂的断言加上明确的注释。 是 否 免 7-9

11、：用断言确认函数的参数。 是 否 免 7-10：用断言保证没有定义的特性或功能不被使用。 是 否 免 7-11：用断言对程序开发环境（OS/piler/Hardware）的假设进行检查。 是 否 免 7-12：正式软件产品中应把断言及其它调测代码去掉（即把有关的调测开关关掉）。 是 否 免 7-13：在软件系统中设置与取消有关测试手段不能对软件实现的功能等产生影响。 是 否 免 7-14：用调测开关来切换软件的DEBUG版和正式版而不要同时存在正式版本和DEBUG版本的不同源文件以减少维护的难度。 是 否 免 7-15：软件的DEBUG版本和发行版本应该统一维护不允许分家并且要时刻注意保证两个版本在实现功能上的一致性。 是 否 免 8 程序效率 8-1：编程时要经常注意代码的效率。 是 否 免 序号 总 则 条 款 执行情况 说明 8-2：在保证软件系统的正确性、稳定性、可读性及可测性的前提下提高代码效率。 是 否 免 8-3：局部效率应为全局效率服务不能因为提高局部效率而对全