第2讲 代码走查缺陷表
C__代码走查CheckList
代码走查
一．代码走查的目的
1．保证代码符合编码规范
2．保证代码符合设计
3．发现bug
4．保证代码单元测试充分
5．促进开发人员之间的交流，为代码的优秀程度的提高和开发人员编码技能的提高提供契机。
二．过程
每次迭代都要对修改过和新编的代码进行走查，走查的过程如下图：
三．Checklist
说明：本checklist用于走查人员走查代码。
开发人员用于自我检查的checklist可以参照此checklist，依自身实际情况制定。
说明：本checklist应随着组织开发过程中出现的实际情况，对检查项具体内容进行增、删、改，以使得此checklist更具效率，但要注意保持检查项数目的简洁。
类名：走查的类的名字。
代码走查检查单
流程控制缺陷(CF) 1 对于每一个循环:是否选用了最佳的循环结构? 2 所有的循环是否都能结束? 3 如果一个循环有多个出口,是否每个出口都有必要并且得到正确处理? 4 switch声明是否都有default条件? 5 是否所有的case-switch-break对应关系都已更正并加上批注？ 6 是否named break叙述都跳到正确的地方？ 7 循环和分支的嵌套是否过深?是否正确? 8 是否有if嵌套可以转换程switch嵌套? 9 空控制叙述是否都正确，并加上括号及批注？ 10 所有的异常是否都得到了正确的处理 11 每一个方法在是否都结束?
C# 代码审查检查表
项目名称
责任人
走查日期
编号
问题
变量,Auribute,和常量声明缺陷(VC)
1 变量和常量的命名是否与约定保持一致?
2 是否存在容易混淆的相似的变量和属性名?
3 变量和属性是否书写正确?
4 变量和属性是否被正确的初始化?
5 非局部变量是否能用局部变量替换?
6 所有的for循环的控制变量是否都在循环顶部被声明?
7 是否有应该命名为常量的文字常量?
8 变量和属性是否可以用常量替换?
9 属性是否可以用本地变量?
10
所有的属性是否都有正确的访问限制符 (private,protected,public)?
【软件工程】【CMMI】代码走查单
1-14
用 应通 该配 尽符 可方 能式 减小类与类之间耦合，所遵循的经验法则是：尽量限制成员函数的可见性。如果成员函数没必要
1-15
为 若保 没护 有足(够pr理ot由ec，te不d)要；把没实必例要或保类护变(量pr声ot明ec为te公d)有，。就公定共义和为保私护有的(可pr见iv性at应e)当。尽量避免，所有的字段都建议
1-3
避免使用长名字（最好不超过 25 个字母）
1-4
采用大小写混合，提高名字的可读性。一般应该采用小写字母，但是类和接口的名字的首字母，以及任何中
1-5
所 写有 。单 包词 名首 全字 部母 小大 写写 。。使用能确切反应该类、接口含义、功能等的词。一般采用名词
1-6
采用完整的英文大写单词，在词与词之间用下划线连接，如：DEFAULT_VALUE
代码走查记录跟踪单
项目名称
记录更新人
记录更新时间
走期 模块名称
检查文件 代码总行 数（个） 数（LOC）
花费工时（H）
1
50000
2
50000
3
50000
编号
检查项
1 代码规范
1-1
程序结构清晰，简单易懂，单个函数行数不得超过100行；
1-2
使用可以准确说明变量/字段/类/接口/包等的完整的英文描述符
1-7
对不易清楚识别出该变量类型的变量应使用类型缩写作其前缀，如字符串使用strXXX,boolean使用isXXX。
1-8
应采用完整的英文描述符命名组件（接口部件），遵循匈牙利命名法则
1-9
一个集合，例如数组和矢量，应采用复数命名来表示队列中存放的对象类型。命名应采用完整的英文描述符
java代码检查表(很好的公司在用)
4.
代码优化
4.1同步方法的使用是否必要？同步代码块是否已粒度最小化？
4.2在不影响可读性和易维护性的前提下，对象是否可重复利用？如StringBuffer可以通过setLength(0)重复利用，无需每次重复创建新实例。
4.3是否有这样的代码：new String(””)？
2.2嵌套内部类是否超过2层？
2.3所有方法是抽象的且所有成员变量是静态常量的抽象类是否声明成了接口？
2.4当类所有的方法和属性都是静态的时，是否定义了缺省的私有构造方法？
2.5没有使用任何实例类成员（包括方法和成员变量）的方法是否被声明为静态的？
2.6异常发生时是否均恰当的记录了错误日志？是否存在使用System.out.println而不是日志模块记录日志的情况发生？
3.8克隆方法中是否调用了父克隆方法？克隆方法中是否避免了调用构造函数？
3.9使用ObjectStream后是否调用了reset()方法以避免内存泄漏？
3.10条件、循环中的判断边界值是否恰当？
3.11程序块的break、return、throw是否恰当？
3.12charAt()、数组下标、parseInt之类可能抛运行时异常的方法是否需要事先判断或事后catch？如需要，处理是否恰当？
代码走查检查表
项目名称：模块名称：版本号：
检查时间：检查员：
#
检查项
是/否
注释
1.
命名、注释及风格
1.1文件、类/接口、静态变量、成员变量、方法及关键代码是否都有格式良好、简明扼要、的注释？注释是否是对设计思路的说明而不仅仅是代码行为的描述？是否存在过时的注释或废代码注释？
1.2文件中各种段落布局是否合理、是否用恰当的空行分隔？代码的断行、对齐、缩进、空行是否恰当？
[指南]代码走查检查表
![[指南]代码走查检查表](https://img.taocdn.com/s3/m/03854ed188eb172ded630b1c59eef8c75fbf9597.png)
代码走查检查表评审日期：年月日评审对象作者评审人评审工作量序号检查项评审意见走查前准备1 得到一份解释代码的最新的设计文档，作为代码走查的参考2 代码都已提交，版本统一程序结构组织1 所有代码的结构清晰，具有良好的结构外观和整齐2 所有的模块（函数和外部接口）定义清晰，模块分解清楚3 所有的功能需求都明显的覆盖4 整个代码体系结构组合合理 ,分层清晰，代码之间功能划分明确5 所有的接口模块化，尽量减少接口之间的耦合度，修改时尽量不影响其他代码模块6 代码体系构架对空间和速度都已经进行考虑7 数据库操作、IO操作等是否正确关闭资源。
并且必须在try -catch-finally 的finally中关闭。
8 一个业务如果进行多次数据库更新、添加、删除是否正确添加事务。
9 进行逻辑与、逻辑或判断时是否使用短路与、短路或。
10 多处使用相同代码时，应定义唯一方法或变量以供使用。
11 对象是否使用工厂获取。
12 导入类时，如果仅使用包中的几个类，应导入具体类，而不是导入整个包。
13 数组声明的时候使用 int[] index ，而不要使用int index[]。
14 代码实现的逻辑是否与详细设计描述的逻辑一致15 检查类中是否有无效的代码或者是无用的代码。
16 不要使用System.out.print()以及System.err输出，需要进行日志处理17 所有的文件名符合文件命名规范，见名知意18 文件和模块分组清晰19 较长的语句、表达式或参数（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读20 每个程序文件都小于2000行代码组织1 数据库查询语句不要出现select *2 对需要处理的字符串定义为StringBuffer ，常量定义成静态的。
3 所有的变量名都小于32字符4 有返回值的方法是否正确返回。
Return语句应定义在方法结尾处。
代码缺陷分析与修复最佳实践(二)
代码缺陷分析与修复最佳实践引言：代码缺陷是软件开发中难以避免的问题，它可能导致软件系统的不稳定性、安全性问题，甚至引发严重的后果。
因此，代码缺陷的分析与修复是开发人员不可忽视的重要工作。
本文将探讨代码缺陷分析与修复的最佳实践，以帮助开发人员提高代码质量和软件可靠性。
一、代码缺陷分析代码缺陷分析旨在识别潜在的软件缺陷，并找出其原因和影响。
下面是一些常用的代码缺陷分析方法和技巧。
1. 静态代码分析工具静态代码分析工具可以检测代码中的潜在问题，如空指针引用、内存泄漏、未初始化变量等。
开发人员可以使用流行的静态代码分析工具，如FindBugs、PMD等，来扫描代码并发现潜在的缺陷。
2. 代码审查代码审查是一种通过人工审查代码来发现潜在问题的方法。
开发人员可以组织团队成员进行代码审查，相互检查并提出改进意见。
代码审查不仅能够帮助发现代码缺陷，还能够促进知识共享和团队合作。
3. 单元测试单元测试是一种通过编写测试用例来验证代码正确性的方法。
通过编写全面的单元测试，开发人员可以覆盖代码中的各种分支情况，从而发现潜在的缺陷。
单元测试还可以作为代码修改后的验证手段，确保缺陷修复不会引入新的问题。
4. 数据流分析数据流分析是一种通过跟踪程序变量的值和使用情况来发现代码缺陷的方法。
通过分析数据流，开发人员可以找到潜在的空指针引用、资源泄漏、不正确的变量赋值等问题。
数据流分析可以手工进行，也可以借助工具来辅助完成。
二、代码缺陷修复代码缺陷修复是指在发现代码缺陷后，将其进行修复以提高代码质量和软件可靠性的过程。
以下是一些常用的代码缺陷修复方法和技巧。
1. 缺陷跟踪系统缺陷跟踪系统是一个用于记录和追踪软件缺陷的工具。
开发人员可以使用缺陷跟踪系统来记录发现的缺陷，并在修复缺陷后关闭相应的缺陷。
缺陷跟踪系统还可以帮助团队成员进行协作和沟通，提高修复缺陷的效率和质量。
2. 修复缺陷的优先级在修复代码缺陷时，开发人员应该根据缺陷的优先级来制定修复计划。
代码走查表
代码走查表
代码走查的最主要的目的是为了发现程序中的逻辑错误，编程风格方面的错误可以通过风格检查的工具去检查。
如序号检查项
1、代码的注释与代码是否一致?是注释是否是多余的?
2、是否存在超过3层嵌套的循环与/或判断?否
3、变量的命名是否代表了其作用?是
4、所有的循环边界是否正确?是
5、所有的判断条件边界是否正确?是
6、输入参数的异常是否处理了?是
7、程序中所有的异常是否处理了?是
8、是否存在重复的代码?否
9、是否存在超过20行的方法?是
10、是否存在超过7个方法的类?是
11、方法的参数是否超过3个?否
12、是否有多种原因导致修改某个类?是
13、当发生某个功能变化时，是否需要修改多个类?否
14、代码中的常量是否合适?是
15、一个方法是否访问了其他类的多个属性?是
16、某几项数据是否总是同时出现，而又不是一个类的属性?是
17、switch语句是否可以用类来替代?是
18、是否有一类的职责很少?是
19、是否有一个类的某些属性或者方法没有被其他类所使用?否
20、在类的方法中是否存在如下的调用形式：a.b().c()?否
21、是否某个类的方法总是调用另外一个类的同名方法?
22、是否某个类总是访问另外一个类的属性与方法?
23、是否两个类完成了类似的工作，使用了不同的方法名，却没有拥有同一个父类?
24、是否某个类仅有字段和简单的赋值方法与取值方法构成?
25、是否某个子类仅使用了父类的部分属性或方法?
检查的工具去检查。
如下的检查单给代码走查的专家发现逻辑错误提供了一个很好的帮助。
否。
01-代码检查列表总结-
代码检查错误列表总结数据引用错误：1. 是否有引用的变量未赋值或初始化2. 下标的值是否在范围之内3. 是否存在非整数下标4. 是否存在虚调用(dangling reference)对于所有的通过指针或引用变量的引用,当前引用的内存单元是否分配?5. 当使用别名时属性是否匹配6. 记录和结构的属性是否匹配,即变量值的类型或属性是否与编译器所预期的一致7. 是否计算位串的地址?是否传递位串参数?8. 基础的存储属性是否正确9. 跨过程的结构定义是否匹配10. 索引或下标操作是否有”仅差一个”的错误11. 继承需求是否得到满足运算错误：1. 是否存在非算术变量间的运算？2. 是否存在混合模式的运算？3. 是否存在不同字长变量间的运算？4. 目标变量的大小是否小于赋值大小？5. 中间结果是否上溢或下溢？6. 是否存在被0除？7. 是否存在二进制的不精确度？8. 变量的值是否超过了有意义的范围？9. 操作符的优先顺序是否被正确理解？10. 整数除法是否正确？数据声明错误：1. 是否所有的变量都已声明？2. 默认的属性是否被正确理解？3. 数组和字符串的初始化是否正确？4. 变量是否赋予了正确的长度、类型和存储类？5. 初始化是否与存储类相一致？6. 是否有相似的变量名？比较错误：1. 是否存在不同类型变量间的比较？2. 是否存在混合模式的比较运算？3. 比较运算符是否正确？4. 布尔表达式是否正确？5. 比较运算是否与布尔表达式相混合？6. 是否存在二进制小数的比较？7. 操作符的优先顺序是否被正确理解？8. 编译器对布尔表达式的计算方式是否被正确理解？控制流程错误：1. 是否超出了多条分支路径？2. 是否每个循环都终止了？3. 是否每个程序都终止了？4. 是否存在由于入口条件不满足而跳过循环体？5. 可能的循环越界是否正确？6. 是否存在“仅差一个”的迭代错误？7. DO/END语句是否匹配？8. 是否存在不能穷尽的判断？9. . 输出信息中是否有文字或语法错误？输入/输出错误：1. 文件属性是否正确？2. OPEN语句是否正确？3. I/O语句是否符合格式规范？4. 缓冲大小与记录大小是否匹配？5. 文件在使用前是否打开？6. 文件在使用后是否关闭？7. 文件结束条件是否被正确处理？8. 是否处理了I/O错误？接口错误：1. 形参的数量是否等于实参的数量？2. 形参的属性是否与实参的属性相匹配？3. 形参的量纲是否与实参的量纲相匹配？4. 传递给被调用模块的实参个数是否等于其形参个数？5. 传递给被调用模块的实参属性是否与其形参属性匹配？6. 传递给被调用模块的实参量纲是否与其形参量纲匹配？7. 调用内部函数的实参的数量、属性、顺序是否正确？8. 是否引用了与当前入口点无关的形参？9. 是否改变了某个原本仅为输入值的形参？10. 全局变量的定义在模块间是否一致？11. 常数是否以实参形式传递过？其他检查：1. 在交叉引用列表中是否存在未引用过的变量？2. 属性列表是否与预期的相一致？3. 是否存在“警告”或“提示”信息？4. 是否对输入的合法性进行了检查？5. 是否遗漏了某个功能？。
代码走查检查表模板
其他评审意见或建议：
评审意见 (具体意见描述)
评审人
责任人
特别是那些可能出错的类型8声明空白缩进重要9声明空白缩进重要变量是否已经在定义的同时初始化
代码检查列表
序号 1 所属类别 命名 重要程度 重要 检查项 命名规则是否与所采用的规范保持一致？ 所有的源文件都应该在开头有一个版权和文件内容声明 /* *Model：模块名称 *Description：文件描述 *Author:作者姓名（一般情况下用中文） *Finished：xxxx年xx月xx日 */ 在导入包时当完全限制代码所使用的类的名字,而不用通配符 的方式 例如: import java.awt.Color; import java.awt.Button;
声明、空白、缩进 重要 声明、空白、缩进 重要 声明、空白、缩进 中等 声明、空白、缩进 中等 声明、空白、缩进 中等 逻辑 逻辑 逻辑 逻辑 逻辑 逻辑 重要 中等 重要 重要 中等 重要
19 20 21 22 23
逻辑 逻辑 逻辑 逻辑 逻辑
重要 重要 重要 重要 重要
是否对有异常抛出的方法都执行了try...catch保护？ 入口对象是否都被进行了判断不为空？ 入口数据的合法范围是否都被进行了判断？(尤其是数组) 是否对有异常抛出的方法都执行了try...catch保护？ 是否对方法返回值对象做了null检查，该返回值定义时是否 被初始化?
2
注释
重要
3Leabharlann 注释重要4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
注释 注释 注释 注释
重要 重要 中等 重要
注释是否较清晰且必要？ 复杂的分支流程是否已经被注释？ 距离较远的}是否已经被注释？ 方法是否已经有文档注释？（功能、输入、返回及其他可 选） 每行是否只声明了一个变量？（特别是那些可能出错的类 型） 变量是否已经在定义的同时初始化？ 是否合理地使用了空格使程序更清晰？ 代码行长度是否在要求之内？(建议每行不超过80个字符) 折行是否恰当？ 包含复合语句的{}是否成对出现并符合规范？ 是否给单个的循环、条件语句也加了{}？ 单行是否只有单个功能？（不要使用；进行多行合并） 单个函数是否执行了单个功能并与其命名相符？ 单个函数不超过规定行数？每个函数不能超过300行 入口对象是否都被进行了判断不为空？
软件缺陷追踪表
软件缺陷追踪表1.引言软件缺陷追踪表是一个用于记录和追踪软件开发过程中发现的缺陷的工具。
通过记录每个缺陷的详细信息和状态变更，可以帮助开发团队更好地管理和解决软件缺陷，从而提高软件质量。
2.缺陷追踪表结构软件缺陷追踪表通常包含以下几个重要字段：2.1 缺陷编号每个缺陷在系统中应有唯一的编号，用于快速识别和跟踪。
2.2 缺陷描述对缺陷进行详细的描述，包括发现缺陷的具体场景、现象和影响等信息，以便开发团队能够准确理解和复现该缺陷。
2.3 缺陷状态记录缺陷当前所处的状态，常见的状态包括未解决、已解决、已验证等。
2.4 缺陷严重程度对缺陷的影响程度进行评估，常见的评价标准包括严重、一般、轻微等。
2.5 缺陷优先级根据缺陷的紧急程度和重要性确定其优先级，通常分为高、中、低三个级别。
2.6 缺陷责任人指定负责处理该缺陷的开发人员或团队，以确保缺陷得到及时修复和验证。
2.7 缺陷解决方案记录解决该缺陷的具体方法和步骤，供开发人员参考和执行。
2.8 缺陷验证结果记录修复缺陷后的验证结果，以确保修复的有效性和质量。
3.缺陷追踪表的使用和管理在使用软件缺陷追踪表时，需要做到以下几点：3.1 缺陷记录和更新及时记录发现的缺陷，并随着缺陷的处理过程进行更新。
确保缺陷表中的信息是准确和最新的。
3.2 缺陷分析和优先级确定对缺陷进行分析，评估其严重程度和优先级，以确定处理的顺序和重点。
3.3 缺陷解决和验证根据缺陷表中的信息，指定相应的负责人进行缺陷解决，并及时进行验证，确保缺陷得到有效修复。
3.4 缺陷报告和溯源通过缺陷表可以生成缺陷报告，以便对缺陷的溯源和整体情况进行分析和追溯。
4.总结软件缺陷追踪表是一个重要的工具，可以有效帮助开发团队管理和解决软件缺陷。
合理使用和管理缺陷追踪表，能够提高软件开发过程的效率和质量，减少缺陷带来的风险和影响。
参考文献：1] ___。
软件质量管理教程[M]。
机械工业出版社。
2011.2] ___ Technology of are Testing (J).Hefei Normal University Journal,2020,36(01):41-43.3] Qi Li.Research and design of are ___,2014.以上是对于软件缺陷追踪表的简要介绍和说明，希望对您有所帮助。
12、代码缺陷检查表示例
C/C++代码缺陷检查表 代码缺陷检查表示例§ § § § § § § § § 文件结构 程序的版式 命名规则 表达式与基本语句 常量 函数设计 内存管理 C++ 函数的高级特性 类的构造函数、析构函 数和赋值函数 § 类的高级特性 § 其它常见问题文件结构§ § § § § § 头文件和定义文件的名称 头文件和定义文件的目录结构 版权和版本声明 预处理块 头文件中只存放“声明”而不存放“定义” ……#ifndef GRAPHICS_H #define GRAPHICS_H #include <math.h> … #include “myheader.h” … void Function1(…); … class Box { … }; #endif// 防止graphics.h被重复引用// 引用标准库的头文件 // 引用非标准库的头文件 // 全局函数声明 // 类结构声明程序的版式§ § § § 空行 代码行内的空格 长行拆分 “{” 和 “}” 的使用if (year >= 2000) if(year>=2000) if ((a >= b) && (c <= d)) if(a>=b&&c<=d) for (i = 0; i < 10; i++) for(i=0;i<10;i++)// 良好的风格 // 不良的风格 // 良好的风格 // 不良的风格 // 良好的风格 // 不良的风格§ 一行代码是否只做一件事 § if、for、while、do等语句自占一行，不 论执行语句多少都要加“{}”。
不良缺陷代码表 Defect Bin Code
08-1280-EN-99
Category of distribution文件分发类型 文件分发类型
S/N 1
Dept. 部门 MFG QA
QTY. 数量 2 1
Revision History 文件更改历史记录
Document Rev 文件版本 Revision summary 文件更改概述 Revise Date 更改日期
参考文件/Reference Document 四.参考文件 参考文件 MES-QM 缺陷代號表III [按CPTAN分類] 12-QE30-0GEN-080-x
EHS(环境健康安全)注意事项:N/A
Form # : 12-DC80-0GEN-001-02-F
WORK INSTRUCTION 工作指示
DOCUMENT NO 文件编号.
Title/文件名称 CM Defect&Bin Code / CM 缺陷代码 文件名称: 文件名称
Customer客户: CM Product Family 产品系列: ALL Product Model 产品型号: ALL
针对在清单中不能找到的缺陷如果需要加入到系统中则需要将此缺陷及描述发给cmmes协调员确认获得cmmes协调员批准后cmmes协调员将此缺陷加入系统2formessystemaccordingtothecustomerrequirementandactualdefecttocheckwiththemesdefectcodeifcantfoundthedefectcodeinthecommondefectlistqewillhighlighttoqafunctionandrequesttoaddthemintothemessystem
Dept. 2 3
代码走查表
走查前准备1 得到一份解释代码的最新的设计文档2 代码解释时使用了严格的警告和错误检查参数并被解释通过3 代码使用带ISO标准的xxxx编译器进行解释程序结构4 所有代码的结构清晰，具有良好的结构外观和整齐5 所有的模块（函数和外部接口）定义清晰，模块分解清楚6 所有的功能需求都明显的覆盖7 高层设计独立于OS/环境8 结构设计能够满足机能变更9 代码体系结构描述了如何把代码重用到其他体系结构中10 整个代码体系结构组合合理11 所有主要的数据构造描述清楚，合理12 模块中所有的数据结构都定义为局部的，并且通过定义好的函数进行访问13 为外部定义了良好的函数接口14 所有的接口模块化，因此修改时不影响其他代码模块15 内存使用方法和内存管理策略描述清楚和正确16 代码体系构架对空间和速度都已经进行考虑17 提供了处理数据的策略18 具有同一的错误处理策略19 通过一套清晰的函数接口提供错误信息目录文件组织20 所有的文件名符合文件命名规范，见名知意21 文件和模块分组清晰22 每个文件有文件头和标准的习惯一致（描述文件的用途，作者，对外提供的函数）23 每个文件都组织的有序－文件头，类型定义，原型，函数24 所有的代码行在80字符以内25 每个程序文件都小于2000行26 每个文件只包含一个完整功能模块的代码函数组织27 每个函数都有一个标准的函数头声明28 函数组织：头，函数名，参数，函数体29 函数定义符合ANSI或者用标准PERL的编译开关30 每个函数都能够在最多2页纸可以打印31 所有的变量声明每行只声明一个32 所有的函数名都小于64个字符33 每个函数之间都用2空行进行分开代码组织34 每行代码都小于80字符35 所有的变量名都小于32字符36 所有的行每行最多只有一句代码或一个表达式37 复杂的表达式具备可读性38 续行缩进39 括号在合适的位置40 每个顺序的小块用空行隔开41 注解和代码对齐或接续在代码之后移植性42 代码与操作系统无关，不需要任何假设条件函数43 函数头清楚地描述函数和它的功能44 代码中有相关注解45 函数的名字清晰的定义了它的目标以及函数所做的事情46 函数的功能清晰定义47 函数中所有的部分都合理的组成函数，相关独立的语句组组成函数48 函数高内聚只做一件事情，并做好49 函数和其他代码松耦合50 参数遵循一个明显的顺序；51 所有的参数都被使用52 函数的参数接口关系清晰53 如果一个函数有返回值，在所有的出口都有返回值54 函数使用了最少数目的return语句55 函数的参数个数小于7个56 所有的假设和接口清楚57 使用的算法说明清楚58 函数检查了输入数据的合法性59 函数异常处理清楚60 函数设计已经考虑了将来的变化61 调试信息存在于代码中并容易激活62 代码检查调用函数的返回值，参数和调用匹配63 函数确保了没有影响函数外代码64 递归定义了出口65 递归局限于一个函数66 堆栈大小支持递归调用的深度数据类型与变量67 数据类型存在数据类型解释68 代码为每种可能改变数据类型的数据使用一个不同的类型69 代码避免了重新定义预先定义的数据类型70 数据结构简单以便降低复杂性71 每一种变量分配了正确的长度、类型和存储空间72 静态变量明确区分73 所有的声明与编译器或具体的机器长度无关74 每一个变量都初始化了75 每一个变量都在接近使用它的地方才初始化76 每一个变量都在将要使用它的时候才初始化77 变量的命名完全、明确的描述了该变量代表什么78 命名和现实生活中的事务接近而不仅仅是一个程序类型79 同一种类型或指针命名的前缀指出类型或指针80 命名不与标准库中的命名相冲突81 程序没有使用特别的、易误解的、发音相似的命名82 所有的变量都有最小的活动范围83 所有的全局变量都描述清楚84 使用函数访问取代全局数据的访问85 所有的变量都用到了86 存取数据的程序与全局数据的用法是兼容的87 变量按照它的命名用途进行使用特殊88 所有的数组访问在它们的边界内89 代码已经处理了-1错误90 代码处理了指针异常91 所有常量定义和使用替代代码中的数字92 类型转换明确指明其他注意项93 代码与比较，计算变量的大小无关94 代码与操作符的优先级无关95 所有的表达式使用了正确的操作符条件判断96 条件检查和结果在代码中清晰97 If/else 使用正确98 普通的情况在if下处理而不是else99 判断的次数降到最小100 判断的次数不大于6次，无嵌套的if链101 数字，字符，指针和0/NULL/FLSE 判断明确102 boolen表达式表示清楚103 最常用的情况最先判断104 所有的情况都考虑105 判断体足够短，以使得一次可以看清楚106 嵌套层次小于3次循环107 循环体不为空108 循环之前做好初始化代码109 循环体能够一次看清楚110 当有明确的多次循环操作，使用For循环111 当有不明确的多次循环操作，while循环被使用112 代码中不存在无穷次循环113 循环的头部进行循环控制114 循环索引具有有意义的命名115 循环设计得很好它，只干一件事情116 循环终止的条件清晰117 循环体内的循环变量起到指示作用118 循环嵌套的次数小于3次输入输出119 所有文件的属性描述清楚120 所有OPEN/CREATE调用描述清楚121 文件结束的条件进行检查122 显示的文本无拼写和语法错误注释123 有一个简单的说明，用于描述代码的结构124 每个文件和模块均以给予解释125 源代码能够自我解释126 每个人看到代码就能很快理解127 解释说明代码功能，准确描述代码意义128 解释不过于简单129 注解清楚正确130 注解为用户服务131 所有的假设和限制进行注解132 长的控制体结束，进行注解总括133 代码直观134 代码中的用语符合广告用语，而不是技术化的描述135 代码和设计文档对应136 无用的代码已经删除137 无用的注解已经删除。
代码走查检查单
新增按钮必须排列在通用按钮之后，退出按钮之前。 新增按钮必须有MDI帮助和说明。 数据窗的行高68、单元格高度为56，行线颜色border(none)、背景白色（white）； 列表式数据窗一般为Grid，数据窗的字体“宋体 9”，数据窗Header高68、标签（Text）高56，背景为灰色（ButtonFac （No border） 按钮（CommandButton） 按钮的大小 长度：334，高度：88 其他控件 StaticText、SinglelineEdit、EditMask的高度为72 全部采用默认样式（3D），以统一界面为标准。 长宽比例要求一致，建议采用黄金比例法 弹出的层数不能超过3个，并且保证是响应式窗口 同类型的窗口保持布局一致 代码走查人签字： QA人员签字：
■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合
6
操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操
□ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合
□ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合
■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合
代码走查单
是否适用 严重程度
是： 高：
否： 中：
评审工件
工件版本
是否达到可评审状态
是
否
严重程度 建议修正措施
评审人员 其它 注释
不适用： 低：
4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 结果 统 计：
其它：
注释 注释是否解释了代码的目的，或总结了代码所要完成的工作？ 注释是否是最新的？ 注释是否清晰正确？ 是否对代码含义进行了注释？ 声明全局变量时，是否给以了注释？ 是否说明了每个子程序的目的？ 注释是否与代码保持一致性，不存在没用的注释？ 其它：
程序块的分界符是否各独占一行并且位于同一列，同时与引用它们 1.6 的语句左对齐？ 1.7 其它：
2 命名 2.1 定义的程序名是否有意义？
标识符的命名是否清晰、明了，有明确含义，同时使用完整的单词 2.2 或大家基本可以理解的缩写，避免使人产生误解？ 2.3 命名中规若范使是用否特与殊所约使定用或的缩系写统，风是格否保有持注释一说致明，？并在同一项目中统 2.7 一？ 2.8 其它：
是否注意运算符的优先级，并用括号明确表达式的操作顺序，避免 3.9 使用默认优先级？ 3.1 是否只引用属于自己的存贮空间？ 3.11 是否防止引用已经释放的内存空间？
如果不是构造函数，过程/函数中分配的内存，在过程/函数退出之 3.12 前是否释放？
对于退出过程/函数后仍然需要存在的内存，是否确保该内存使用完 3.13 毕后及时释放该内存？
过程/函数中申请的（为打开文件而使用的）文件句柄，在过程/函 3.14 数退出之前是否关闭？ 3.15 是否防止内存操作越界？
系统运行之初，是否初始化有关变量及运行环境，防止未经初始化 3.16 的变量被引用？ 3.17 在产品软件（项目组）中，是否统一编译开关选项？
时间管理代码检查及缺陷管理
时间管理将主要活动分类。
在开始分配时间时，你会发现大部分时间都用在相对很少的几个活动上。
记录每项主要活动所花费的时间。
坚持记录时间需要很强的自我约束能力，要想进行精确的记录，必须记录下每件主要工作开始和结束的时间。
除非你知道自己实际上用了多少时间，否则就不可能管理好使用时间的方式。
用标准的方法记录时间。
必须使用标准的时间日志。
因为需要采集的时间数据的数量增加得很快，如果不认真记录和存储这些数据，它们很可能丢失或变得混乱，这样很不利于查找或对它们进行解释。
如果不打算对这些数据进行适当的整理、归纳，就根本不必要去收集数据。
事件日志注：C表示“已完成”，U表示“单位”以分钟为测量单位。
工程是在完成任务中不间断工作的时间一般都少于1小时，因此以小时为单位对工作时间进行测量不能提供用以计划和管理工作所需要的详细数据，而用分钟跟踪时间容易得多。
一旦决定进行时间跟踪，用分钟作为测量单位将比用小时更恰当。
处理中断时间。
采用表2.1跟踪时间时，一个常见的问题就是中断。
电话、聊天、偶尔的烦恼以及必要的休息打断的次数多得令人吃惊。
中断的时间不是有效的工作时间，并且变化幅度很大，如果不对它进行测量，实际上就在时间记录中加入了一个随机数，也就很难使用时间数据来计划和管理时间了。
事件日志中的数据能帮助你了解工作被打断的频率。
多数中断不仅浪费时间，还会打断你的思路，导致效率降低和错误的产生，因此了解被打断的频率有助于提高工作的质量和效率。
将时间数据保存在合适的地方。
记录时间花费情况值得推荐的方法就是用工程记事本来记录时间以及其他的事情。
对一个软件专业人员，工程记事本用途很多，可以记录时间日志、程序设计方案以及运算结果，可以作为你所遵循正确的工程实施方案的凭证，可以记录下脑子里面一闪而过的想法。
推荐的方法是从工程记事本的第一页开始向后记录主要活动及其所花费的时间，最后一页开始向前记录时间日志。
录主要活动及其所花费的时间，最后一页开始向前记录时间日志。
代码走查报告(模板)
所有设计要求是否都实现
其它(根据情况添加)
开发组长：检查人：
总体
代码编制是否遵照编码规范
缺陷修改是否完全完成
所有的代码是否风格保持一致
注释
所有的注释是否是最新的
所有的注释是清楚和正确
若代码修改注释是否很方便修改
所有代码异常处理是否都有注释
每一功能目的是否都有注释
是否按注释类型格式编写注释
代码注释量是否达到了规定值
源代码质量
所有变量的命名是否依照规则
循环嵌套是否优化到最少
淘宝模板代码代码走查宝贝描述模板代码模板代码淘宝店铺模板代码淘宝自定义模板代码淘宝模板代码怎么用淘宝装修模板代码网页代码模板淘宝客服模板代码
代码审核问题报告
文档标识：
当前版本：
当前状态：
草稿
发布日期：
发布
修பைடு நூலகம்历史
日期
版本
作者
修改内容
评审号
变更控制号
评审对象：评审日期：
问题
是
否，指出问题所在或解释理由
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用malloc或者new申请内存之后，是否立即检查指针值是否为null
⑩关于类的高级特性
是否违背了继承和组合的规则
代码走查缺陷表
检查项目
满足
不满足
详情
测试员
时间
① 格式部分
嵌套的IF是否有正确的缩进
注释是否准确并有意义
Байду номын сангаас使用的符号是否有意义
代码基本上是否与开始时的模块模式统一一致
是否遵循了全套的编程标准
②入口和出口的连接
初始入口和最终出口是否正确
被传送的参数值是否被正确的设置
对关键的被调用模块的意外情况是否有所处理（如丢失、混乱）
当对另一个模块的每一次调用时，全部所需的参数能否传送给每一个被调用的模块
③存储器问题
每一个域在第一次使用前是否被正确的初始化
规定的域是否正确
每个域是否有正确的变量类型声明
④判断及转移
用于判断的是否是正确的变量
是否判断了正确的条件
每个转移目标是否正确的并且至少执行了一次
⑤性能
性能是否最佳
⑥可维护性
清单格式是否适用于提高可读性
标号盒子程序是否符合代码的逻辑意义
⑦逻辑
全部设计是否已经实现
代码所做的是否是设计规定的内容
每一个循环是否执行了正确的次数
⑧可靠性
对从外部接口采集的数据是否有确认
⑨内存设计
数组或指针的下表是否越界
是否修改了“指向常量的指针”内容
是否有效的处理了“内存耗尽”的问题
是否出现了不规范指针（指针变量没有被初始化、用free或者delete释放了内存之后，忘记将指针设置为null）