代码走查检查单.doc

Java 代码审查检查表

项目名称

责任人

走查日期

编号问题

变量 ,Auribute, 和常量声明缺陷 (VC)

1变量和常量的命名是否与约定保持一致?

2是否存在容易混淆的相似的变量和属性名?

3变量和属性是否书写正确?

4变量和属性是否被正确的初始化?

5非局部变量是否能用局部变量替换?

6所有的 for 循环的控制变量是否都在循环顶部被声明?

7是否有应该命名为常量的文字常量?

8变量和属性是否可以用常量替换?

9属性是否可以用本地变量?系统模块

填写人

走查用时

结果问题数量备注

10 所有的属性是否都有正确的访问限制符

(private,protected,public)?

11是否有静态属性应该是非静态或 vice-versa? 方法定义缺陷 (FD)

1方法名的描述方法是否与命名约定一致?

2每个方法的参数值在使用之前是否都作了检查?

3对于每一个方法 , 它是否都返回了正确的值?

4 每种方法是否都有正确的访问限制符(private, protected, public)?

5静态方法是否应该为非静态或 vice-versa?

类定义缺陷 (CD)

1每一个类是否都有正确的构造函数和析构函数?

2在子类中是否有应该放到父类中的通用成员?

3类的继承层次是否能被简化?

数据引用缺陷 (DR)

1对于每一个数组引用 , 下标值是否在定义的范围内?

2对于对象和数组引用 , 是否组确定其值应为非空?

计算 / 数值缺陷 (CN)

1是否存在不同类型数据之间的混合计算?

2在计算中是否存在上溢或下溢的可能?

3关于数值计算的顺序和优先级的假设是否正确?

4是否用了括号来避免模糊不清?

比较 / 关系缺陷 (CR)

1对每一个布尔测试 , 正确条件是否被检查?

2比较操作符是否正确?

3布尔表达式是否通过内部否定操作进行了简化

4每个布尔表达式是否都正确?

5比较操作是否存在不引人注意的副作用?

6"&&"是否被不小心替换为 ''&"? ''||''是否被不小心替换为''|"? 流程控制缺陷 (CF)

1对于每一个循环 : 是否选用了最佳的循环结构?

2所有的循环是否都能结束?

3如果一个循环有多个出口 , 是否每个出口都有必要并且得到正确处理?

4switch 声明是否都有 default 条件?

5是否所有的 case-switch-break 对应关系都已更正并加上批注？

6是否 named break叙述都跳到正确的地方？

7循环和分支的嵌套是否过深 ?是否正确?

8是否有 if 嵌套可以转换程 switch 嵌套?

9空控制叙述是否都正确，并加上括号及批注？

10所有的异常是否都得到了正确的处理

11每一个方法在是否都结束?

输入输出缺陷 (IO)

1文件在被使用之前是否都被打开?

2输入对象的属性是否与使用的文件一致?

3文件在被使用之后是否都被关闭?

计算 / 数值缺陷 (CN)

1文本中是否有拼写和语法上的错误?

2所有的 I/O 异常处理的是否合理?

模块间接口缺陷

1方法调用的参数的数量 , 顺序 , 类型和值是否与该方法声明一致?

2度量单位是否一致（如：公分 vs. 公尺）？

3如果对象或数组被传递 , 它们是否改变 ?是否被调用方法正确改变?注释缺陷 (CM)

1每一个方法 , 类和文件是否都有适当的头注释?

2每一个属性 , 变量和常量的声明是否都有注释?

3每个类和方法的潜在行为是否都有用简易的语言进行解释?

4方法和类的头注释是否和它们的功能保持一致?

5注释和代码是否保持一致?

6注释对于理解代码是否有帮助?

7代码中的注释是否充分?

8代码中的注释是否过多?

布局和封包缺陷 (LP)

1代码布局格式和缩排标准是否前后一致?

2对于每一个方法 , 它的代码量是否都不超过 60行?

3对于每一个编译模块 , 它的代码量是否都不超过 600行?

模块性缺陷 (MO)

1模块 ( 方法 , 类) 之间是否具有低偶合性?

2每个模块 ( 方法 , 类) 自身是否具有高聚合性?

3是否存在重复的代码 , 它的功能可以通过调用其它方法实现?

4Java类库的使用是否适时适地?

存储器使用缺陷 (SU)

1数组是否足够大?

2数组和对象不再使用之后 , 它们的引用是否被赋为空值?

性能缺陷 (PE) [ 可选]

1是否有更好的数据结构和算法可以采用?

测试安排是否合理 , 使易于通过的且代价低廉的测试优先于代价较高

且通过频率较低的测试?

是否可以通过对数值进行一次计算并将结果保存来减少对它重新计算

带来的消耗?

4每一个计算出并保存了的结果是否都被应用?

5计算是否能被移到循环之外?

6在循环内是否有不需要的测试?

7短循环是否可以取消?

8对同一个数据进行操作的两个循环是否可以合并成一个?

其他意见

序号意见内容1

代码走查

代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法, 代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。最近对项目组进行代码评审，发觉需要对代码评审中找到的问题进行一下分类，大概可以分成以下几类问题： 1. Comment 注释没写，或者格式不对，或者毫无意义 2. Coding Standard 没遵守代码规范 3. Existing Wheel 重复现成的代码，或者是开源项目，或者公司已有代码 4. Better practice Java或者开源项目，有更好的写法 5. Performance bottle and Improvement 性能瓶颈和提高 6. Code Logic Error 代码逻辑错误 7. Business Logic Error 业务逻辑错误代码审查列出问题的类型，并有解决情况报告 11月23日代码走查——项目走向成功的锦囊之一说起代码走查，相信每个人都不陌生，但为什么要执行代码走查，什么时候来执行代码走查，如何有效执行代码走查，很多人的看法和见解都不一样。一般的看法，认为代码走查是一种非正式的代码评审技术，它通常在编码完成之后由代码的作者向一组同事来讲解他自己编写的代码，由同事来给出意见。这种做法在很多做软件开发组织中经常采用。但从实际执行效果来看，成效并不都那么明显，反而很多组织的这种做法有浪费时间之嫌。主要是因为代码走查活动时间有限，而参加代码走查的人之前没有较多的时间来提前了解被走查的代码，故而在实际执行时能被走查的代码所占的比例并不高，同时也发现不了多少本质问题。随着软件外包业的发展，它有别于软件产品开发，客户对于产品的要求不再局限于系统是否能够正确运行。而是在设计、代码的品质上也有了更多的要求。有的客户甚至会在我们每次交付后先来检查我们的代码品质，只要是代码不符合要求就会被拒绝。

java代码走查计划书

WATER Corporation 代码走查计划书Version 2.0 XXX 2012/3/20

文档修改记录

目录 1.进度计划 (4) 2.待评审物 (4) 3.成员角色 (5) 4.基本原则 (5) 4.1代码评审原则 (5) 4.2评审指导文档 (6) 5.走查过程定义 (6) 5.1代码走查计划准备阶段 (6) 5.2个人代码走查阶段 (6) 5.3代码走查会议阶段 (7) 5.4缺陷修改与关闭 (7)

1.进度计划小组代码走查活动时间进度安排如下所示： 2.待评审物待评审物名称：银行系统取款模块源代码V1.0 （SC-Banking-Withdraw- V1.0） Figure 1 UML Model for Banking-Withdraw

3.成员角色组长：制定代码走查的计划、安排代码走查活动职责分工、组织代码走查，确保代码走查的过程规范执行；质量保证人员：制定CheckList，记录代码走查会议以及完成问题记录报告；开发人员：完成代码，在代码走查中引领走查人员读代码，走查结束后并根据走查的问题记录报告完成代码修改；评审人员：依据编程规范和CheckList执行代码走查，使用Jupiter工具记录发现的问题。 4.基本原则 4.1 代码评审原则 1.一次检查少于200～400行代码 2.努力达到一个合适的检查速度：每小时少于300～500行代码 3.有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟 4.在复审前，代码作者应该对代码进行注释 5.建立量化的目标并获得相关的指标数据，从而不断改进流程 6.使用检查表（checklist）肯定能改进双方（作者和复审者）的结果 7.验证缺陷是否真正被修复

代码走查规范

综合征管信息系统代码走查规范文档编号：当前版本： 1.0 修改日期：2010年8月18 日

一、JA V A编程规范 (3) 1、变量定义问题 (3) 2、变量命名规则 (3) 3、变量的声明和初始化(I NITIALIZATION) (3) 4、换行(W RAPPING L INES) (4) 5、M AP对象使用问题 (4) 6、EQUALS方法使用问题 (5) 7、IMPORT多余包问题 (5) 8、N ULL P OINTER E XCEPTION问题 (6) 9、关于对象声明问题 (7) 10、注释 (7) 11、访问静态变量或方法 (8) 12、使用静态变量 (8) 13、I F语句 (8) 14、J A V A源文件的长度 (8) 15、方法的长度 (8) 二、项目开发规范 (8) 1、J A V A文件命名规则 (8) 2、JSP代码规范 (9) 3、CTRL代码规范 (14) 4、E VENT &VO&BO (17) 5、P ROXY代码规范 (18) 6、日志 (20) 7、异常处理 (21) 8、缓存 (22)

一、J A V A编程规范 1、变量定义问题如果定义的变量只是在某个局部内使用，就在局部内定义，不要在局部外定义。问题代码： // 返回的明细信息放到vo里传到前台 MAmkdjVO mamkdjVO = new MAmkdjVO(); //如果找到详细信息的记录，就展现 if (responseEvent.getFindNoRecordFlag() == "1") { mamkdjVO = responseEvent.getDetailVO(); 更正代码：(mamkdjVO只是在if条件内使用，只需要自if内定义即可) //如果找到详细信息的记录，就展现 if (responseEvent.getFindNoRecordFlag() == "1") { // 返回的明细信息放到vo里传到前台 MAmkdjVO mamkdjVO = responseEvent.getDetailVO(); 2、变量命名规则 1、禁用差别不大（只有一个或少数几个字母不同）的名称例如：hiThere和hiThre 2、在名称中禁用下划线字符('_') 3、变量的声明和初始化(Initialization) 1、避免声明的局部变量覆盖上一级声明的变量 2、尽量在声明局部变量的同时初始化。

代码走查指导书

代码走查指导书一、目的 1、根据需求、设计尽早发现在各个单元中存在的缺陷，从单元测试阶段抓质量； 2、依靠单元测试，执行代码走查，更快地掌握、了解需求、设计的变更，发现问题并及时修改测试用例； 3、从另一方面去促使开发人员提高软件编码及单元测试的质量； 4、使测试人员更好地理解业务，掌握项目信息；二、前提测试人员需要深刻理解需求、理解设计；三、测试环境由测试leader负责搭建一个简易的测试环境，数据库最好与开发部公用；注：单元测试的很多数据无法通过系统功能去制造，避免因数据的不规范而引发缺陷，所以尽量不要直接在数据库操作；四、测试范围 1、设计的完整性；（根据提交的单元测试页面及实时变更记录测试） 2、业务的正确性；（根据项目的业务需求测试）（以1为测试前提） 3、功能的正确性；（根据详细设计测试）（以1、2为测试前提） 1）页面所有事件元素（增、删、改、查、上传等按钮、控件的操作）的测试； 2）页面初始状态的默认值测试； 3）设计要求的必输项测试； 4）系统统一设计风格的测试；（如清空查询条件的清空按钮） 5）边界数据的测试； 6）Html源码的测试； 7）接口测试；（以相关接口单元已完成为前提，该测试由测试leader不定期进行，原因：一、多留点时间给测试组员设计、修改测试用例；二、以测试leader的理解去发现更深层次的问题，也可作为对组员测试工作的检查。）五、缺陷的记录与修改 1、在测试范围1~6内发现的所有缺陷均记录在SPMS之同级评审--测试走查内； 2、在测试范围7内发现的所有缺陷以邮件的形式发送项目负责人；六、人员职责划分测试leader 1、测试版本控制；（开发部提交所有已完成页面的编译包） 2、测试任务的分配（最好是谁写测试用例谁负责测试）、测试时间的控制及测试结果的发布； 3、查看所有缺陷，过滤一些非缺陷问题，整理共通问题并通知开发人员； 4、接口测试并跟踪修改结果；

前端代码规范

福宝童趣 61区项目前端代码规范代码规范六一区项目前端组 2016

文档控制更改记录日期作者版本更改参考 2016-8-15 1.0 审阅姓名职位分发拷贝号姓名地点 1 2 3 4

目录代码规范前端编码规范（1）——一般规范这是一份旨在增强团队的开发协作，提高代码质量和打造开发基石的编码风格规范，其中包含了HTML, JavaScript 和CSS/SCSS 这几个部分。我们知道，当一个团队开始指定并实行编码规范的话，错误就会变得更加显而易见。如果一段特定的代码不符合规范的话，它有可能只是代码风格错误，而也有可能会是bug。早期指定规范就使得代码审核得以更好的开展，并且可以更精确的地定位到错误。只要开发者们能够保证源代码源文件都严格遵循规范，那接下去所使用的混淆、压缩和编译工具则可投其所好不尽相同。文件命名规范在web 项目中，所有的文件名应该都遵循同一命名约定。以可读性而言，减号（-）是用来分隔文件名的不二之选。同时它也是常见的URL 分隔符（i.e. //https://www.360docs.net/doc/f512864455.html,/blog/my-blog-entry or //https://www.360docs.net/doc/f512864455.html,/images/big-black-background.jpg），所以理所当然的，减号应该也是用来分隔资源名称的好选择。请确保文件命名总是以字母开头而不是数字。而以特殊字符开头命名的文件，一般都有特殊的含义与用处（比如compass[1] 中的下划线就是用来标记跳过直接编译的文件用的）。资源的字母名称必须全为小写，这是因为在某些对大小写字母敏感的操作系统中，当文件通过工具压缩混淆后，或者人为修改过后，大小写不同而导致引用文件不同的错误，很难被发现。还有一些情况下，需要对文件增加前后缀或特定的扩展名（比如.min.js, .min.css），抑或一串前缀（比如3fa89b.main.min.css）。这种情况下，建议使用点分隔符来区分这些在文件名中带有清晰意义的元数据。不推荐推荐推荐

代码走查标准

一．目录文件组织 1.所有的文件名符合文件命名规范 2.文件和模块分组清晰二．程序结构 3.所有的模块（函数和外部接口）定义清晰，模块分解清楚 4.结构设计能够满足机能变更，便于重构 5.模块中所有的数据结构都定义为局部的，并且通过定义好的函数进行访问 6.为外部定义了良好的函数接口，且修改时不影响其他代码模块 7.代码体系构架对空间和速度都已经进行考虑三．代码组织 8.所有的代码行在80字符以内 9.每个程序文件都小于2000行 10.每个函数显示不超过100行 11.所有的变量声明每行只声明一个 12.所有的变量名都小于32字符 13.所有的函数名都小于64个字符 14.每个函数之间都用空行进行分开 15.所有的行每行最多只有一句代码或一个表达式四．函数 16.函数注释清楚地描述函数和它的功能 17.函数的名字清晰的定义了它的目标以及函数所做的事情 18.函数的参数遵循一个明显的顺序 19.函数由并列关系的语句组成 20.函数高内聚，只做一件事情，并做好 21.所有的参数小于7个，且都被使用 22.函数使用了最少数目的return语句 23.函数检查了输入数据的合法性 24.函数异常处理清楚 25.函数设计已经考虑了将来的变化

五．数据类型与变量 26.Plugin中尽量避免全局变量的使用 27.每一个变量都在接近使用它的地方才初始化 28.变量的命名完全、明确的描述了该变量代表什么 29.同一种类型命名使用统一的前缀 30.所有的变量都被使用 31.所有的数组访问要考虑越界情况 32.变量在使用前进行必要的null值判断和处理六．条件判断 33.普通的情况在if下处理而不是else 34.最常用的情况最先判断 35.嵌套层次小于3层七．循环 36.当有明确的多次循环操作，使用For循环 37.当有不明确的多次循环操作，while循环被使用 38.变量定义，数据库读写尽量在循环外进行 39.循环嵌套的次数小于3次八．注释 40.使用统一的注释模版 41.每个类，每个函数都要有注释 42.注释量不低于20% 43.注释要随着代码改变而进行更新九．其他 44.无用的代码和注解已经删除 45.页面的布局要符合统一操作说明

软件设计编码规范标准[详]

质量管理体系过程文件软件设计编码过程

文件版本信息：

目录 1.目的 (3) 2.围 (3) 3.术语 (3) 4.角色与职责 (3) 5.入口准则 (3) 6.输入 (3) 7.流程图 (3) 8.主要活动 (4) 8.1.设计原则 (4) 8.2.设计方法.................................................................................... 错误!未定义书签。 8.3.多方案选择 (4) 8.4.概要设计.................................................................................... 错误!未定义书签。 8.4.1.概要设计............................................................................ 错误!未定义书签。 8.4.2.概要设计评审.................................................................... 错误!未定义书签。 8.5.详细设计.................................................................................... 错误!未定义书签。 8.5.1.详细设计 (5) 8.5.2.详细设计评审 (6) 8.6.编码............................................................................................ 错误!未定义书签。 8.7.单元测试 (7) 8.8.代码走查 (7) 8.9.制作用户文档............................................................................ 错误!未定义书签。 8.10.变更............................................................................................ 错误!未定义书签。 9.输出 (8) 10.出口准则 (8) 11.引用文档 (8)

代码走查计划书

深圳天源迪科信息技术股份有限公司 DIC-TS-DP-BIL-ABP-V6.0/PIMP 版本：1.0 状态：WT 中国电信融合计费平台维护研发项目V6.0 代码走读计划文件建立/修改记录本文件属深圳天源迪科信息技术股份有限公司所有，未经书面许可，不得以任何形式复印或传播。

目录 1进度计划 (3) 2带评审物 ..................................................................................................... 错误！未定义书签。3成员角色 ..................................................................................................... 错误！未定义书签。4基本原则 ..................................................................................................... 错误！未定义书签。 4.1专利和著作权说明................................................................................ 错误！未定义书签。 4.2专利和著作权说明................................................................................ 错误！未定义书签。5走查过程定义 ............................................................................................. 错误！未定义书签。 5.1代码走查计划准备阶段........................................................................ 错误！未定义书签。 5.2个人代码走查阶段................................................................................ 错误！未定义书签。 5.3代码走查会议阶段................................................................................ 错误！未定义书签。 5.4缺陷修复与关闭.................................................................................... 错误！未定义书签。

代码检查规则

1.命名规范 2.JavaDoc注释类和接口的JavaDoc 方法的JavaDoc 变量的JavaDoc 3.长度限制文件长度：Java文件的行数不能超过某个值，默认值是1500 每行长度：每行的字母个数不能超过某个值，默认值是120 方法长度：方法的行数不能超过某个值，默认值是150 方法的参数个数：方法参数的个数不能超过某个值，默认值是7 return 语句的数量：方法中return语句的个数不能超过某个值，默认值是2 4.重复的代码检查内容重复的代码：当相同代码的行数超过某个值时，就认为是重复的代码，默认值是15 5.多余的不必要的括号{}

不必要的圆括号：检查不必要的圆括号”(,)”。例如：if(((((true))))) 6.未简化的未被简化的条件表达式：检查过度复杂的条件表达式，例如：(b == true)，b || true，!false 未被简化的布尔返回值：检查未被简化的boolean返回语句，例如：可以简化成： 7.空白区域(empty block) 检查{}包含起来的区域是否为空 8.空语句(empty statement) 检查是否有空的语句; 9.比较 equals和hashCode方法：检查一个类是否同时重写了equals和hashCode方法子类在重写hashCode()方法时，要调用父类的hashCode() 在实现equals()方法时要使用instanceof操作符要把常量放在equals()方法的左边，例如：“hello”.equals(s)，而不是s.equals(“hello”) 使用equals()比较对象的引用，而不要使用==或!= 10.switch 为switch语句提供default标签 switch语句的default应该放在最后检查case中是否有break，return ，throw 或continue语句，确保每次switch只执行一个分支

Java代码检查规范指导书

Java代码检查规范指导书审核: 日期: 批准: 日期: 实施日期2010年05月24日版本号A-0 密级内部

修改履历

目录 1引言 (5) 2应用范围 (5) 3角色职责 (5) 4输入 (5) 5输出 (6) 6作业流程 (6) 6.1C HECK S TYLE安装与使用 (7) 6.1.1CheckStyle插件安装 (7) 6.1.1.1“在线更新”安装方式 (7) 6.1.1.2“手动下载”安装方式 (7) 6.1.2CheckStyle的配置与使用 (9) 6.1.2.1导入：规则文件 (9) 6.1.2.2启用：项目检查 (10) 6.1.2.3查看：结果视图 (10) 6.2E CLIPSE C ODE S TYLE的配置 (10) 6.2.1.1“代码模版”的配置 (10) 6.2.1.2“代码格式化”的配置 (11) 6.2.1.3“代码清理”的配置 (11) 6.3代码修正 (11) 7问题反馈（FAQ） (12) 1)为什么第一句话需要以标点符号结束？ (12) 2)“”}”应该在同一行”的提示信息？ (12) 3)“一个局部常数，最好定义为全局常数”的提示信息？ (12) 4)“条件逻辑语句应该被移除”的提示信息？ (13) 5)“变量应该声明为PRIVATE”的提示信息？ (13) 6)“工具类不应该存在PRIVATE或者默认构造函数”的提示信息？ (14)

7)“参数超过7个”的提示信息？ (14) 8)“类级的常量必须与模式”^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$”相匹配”的提示信息？ 14 9)“避免在语句中出现嵌套的赋值语句”的提示信息？ (15)

代码走查检查表

代码走查检查表评审日期：年月日评审对象作者评审人评审工作量序号检查项评审意见走查前准备 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.代码审查的思想代码审查是一种制度，通过相关人员分头阅读代码，并在会上讨论，以发现一些编程过程中常犯的错误、笔误、或不符合管理/规范的代码等。事实证明，这是一种非常有效的手段，被公认为是软件开发必须的过程之一。代码审查一般放在编译通过之后，目的是检查通用语义、用法等中级错误。应当说明的是，代码审查仅仅作为一种代码质量保证的方式，代码作者应该认识到代码审查是在帮自己提高效率和质量，是自己分内的事情，不是大家的事、不是上司的事、也不是开发组的事。 2.代码审查指南代码审查本身是针对代码，不是针对生产者制定议程并遵守议程(由主持人把握) 限制争论和辩驳可以对每个问题都发表见解，但不要试图解决所有记录的问题作书面笔记限制参与者人数，并坚持事先做好准备(限制每次会议中审查人的人数，与会人数不做限制，但不赞成都参与讨论) 建立检查表保证代码审查所需要的资源和时间对所有复审者进行有意义的培训(技术、过程以及心理学因素) 复审以前所做的复审 3.代码审查的几种方式自查；开发人员自己通读自己的代码组内互查：开发人员组内针对代码进行讨论，以期发现代码中的错误代码公开走查(inspection)：组织专门的人员(审查人)进行准备，以作者讲解的形式进行代码的审查下面段落主要是针对代码公开走查的方式进行说明。 4.前期准备时期代码走查模块列表的提交：各模块的负责人决定需要进行代码走查的关键模块，并提出列表文档：列表文档格式如下：(如果觉得麻烦，可以在详细设计的目录中作出标注，提交给测试组)。不过需注意的是，每次进行审查的代码，应是逻辑上相对完整、独立的一小块代码，一般在100行左右，至少在代码审查会议前三天提出。代码审查工作开展时间的确定：每周选择固定时间(暂定周二、周四下午2:00—4:00)，进行代码审查，以便此工作能够长期和稳定的展开。代码检查表(checklist)：表中列出编码过程中容易出现的一些错误，以便于代码审查人在全面审查代码的同时，能够有重点的进行代码检查 5.代码公开走查会议的形式角色划分：主持人、作者、审查人、记录人、与会者

代码走查规范

维远泰克代码走查规范文件编号：起草部门：测试组审核人：签发人：批准日期：版本标识：

目录 1引言.................................................................................................................................... 错误！未定义书签。 1.1目的 ................................................................................................................................. 错误！未定义书签。 1.2说明 ................................................................................................................................. 错误！未定义书签。2代码走查 (4) 2.1检查点 (4) 2.2走查流程 (4) 2.2.1走查流程图 ...................................................................................................... 错误！未定义书签。 2.2.2流程概述.......................................................................................................... 错误！未定义书签。 2.2.3具体流程.......................................................................................................... 错误！未定义书签。 2.2. 3.1创建任务 ..................................................................................................... 错误！未定义书签。 2.2. 3.1个人走查 ..................................................................................................... 错误！未定义书签。 2.2. 3.1团队评审 ..................................................................................................... 错误！未定义书签。 2.2. 3.1修复问题 ..................................................................................................... 错误！未定义书签。

代码走查

代码走查，英文词语叫：Code Review，也叫“代码审查”，它是软件公司的一项传统保留项目。 1.代码走查的形式代码走查的形式有很多种，主要有以下几种形式： ●每日走查：只针对每日提交的内容进行评审，走查时间和地点都比较灵活。 ●专项走查：针对某个具体问题或者专题进行走查。评审人需要提前发送评审内容给大家进行预审，然后安排专门的会议室进行评审，时间较长。 ●结对互查：提交代码前指定某位同事进行线上评审，评审通过后才能合入代码。本文要介绍的是每日代码走查，就是大家围在一台开发机周围，逐一轮换讲解所有提交的内容。就即使是每日代码走查，也被我们团队玩出了花样： ●谈心式走查 ●批判式走查 ●半蹲式走查 ●伴侣式走查 2.代码走查的好处持续、有效的开展代码走查，将会收获许多收益，具体表现在： ●能及时发现代码中的Bug，保证版本质量。 ●提升代码的可读性、可维护性，建立团队共同的编码风格。 ●有利于知识共享，打破技能壁垒，避免单点故障。 ●通过展示自己的优秀代码和设计思路，提升了个人成就感。 ●通过讲解自己的代码，对个人沟通能力也是一种提升。特别是对于平时比较内向或者不太喜欢发言的同学。 ●给大家提供了一个每天交流、沟通的平台。工作一天了，也挺累的了，是时候停下手工的编码工作，一起说说话，交流一下了。 3.代码走查中的“坏味道” 虽然代码走查有这么多好处，可在实施的过程中并不会像想象中的那么美好，会遇到各种各样的问题，总结起来的“坏味道”有：

●开发的时间本来就不多，再加上代码走查，会打乱开发节奏。 ●评审的同事对代码不熟悉，发现不了问题。 ●讨论发散或者纠缠在某个具体细节中，导致时间把控不好。 ●评审量大。只能走查部分同事的代码，其他同事的内容没有覆盖。 ●提问题的总是那几个人，其他人都是围观群众。 4.如何做有效的代码走查虽然代码走查很多团队都在做，但要想真正做好它并不是件容易的事情。我们团队经过长期实践，摸索出一些经验和大家分享： 4.1代码走查的时间代码走查建议在固定时间举行，当团队养成习惯后，就会很自然成为团队日常工作的一部分。以我们团队为例，走查时间安排在： ●每天下午16:30--17:30； ●第二天上午9:00--9:30。分两块时间走查是考虑一次走查的内容会很多，有些内容可能走查不完，就分两次进行。如果当天下午能把全部过完，第二天上午就再进行走查活动。另外，在实践的过程中，如果有同事反馈代码正写在“兴头”上或者正在定位紧急故障，可以申请延缓或者不参加本次走查活动。 4.2代码走查的内容我们团队的走查内容已经超越了代码本身，还会涉及方案审查、演示等活动。具体评审内容为； ●新增代码：bug修改，新特性或重构引入的代码变更。 ●设计方案：一般为增量式方案评审。 ●Mini showcase：针对每日实现的功能进行展示。 4.3代码走查的关注点 ●?静态编码问题主要关注静态编码错误、编程风格、命名合理性、Clean Code等内容。

代码走查检查单.doc

Java 代码审查检查表项目名称责任人走查日期编号问题变量 ,Auribute, 和常量声明缺陷 (VC) 1变量和常量的命名是否与约定保持一致? 2是否存在容易混淆的相似的变量和属性名? 3变量和属性是否书写正确? 4变量和属性是否被正确的初始化? 5非局部变量是否能用局部变量替换? 6所有的 for 循环的控制变量是否都在循环顶部被声明? 7是否有应该命名为常量的文字常量? 8变量和属性是否可以用常量替换? 9属性是否可以用本地变量?系统模块填写人走查用时结果问题数量备注 10 所有的属性是否都有正确的访问限制符 (private,protected,public)? 11是否有静态属性应该是非静态或 vice-versa? 方法定义缺陷 (FD) 1方法名的描述方法是否与命名约定一致? 2每个方法的参数值在使用之前是否都作了检查? 3对于每一个方法 , 它是否都返回了正确的值? 4 每种方法是否都有正确的访问限制符(private, protected, public)? 5静态方法是否应该为非静态或 vice-versa? 类定义缺陷 (CD) 1每一个类是否都有正确的构造函数和析构函数? 2在子类中是否有应该放到父类中的通用成员? 3类的继承层次是否能被简化?

数据引用缺陷 (DR) 1对于每一个数组引用 , 下标值是否在定义的范围内? 2对于对象和数组引用 , 是否组确定其值应为非空? 计算 / 数值缺陷 (CN) 1是否存在不同类型数据之间的混合计算? 2在计算中是否存在上溢或下溢的可能? 3关于数值计算的顺序和优先级的假设是否正确? 4是否用了括号来避免模糊不清? 比较 / 关系缺陷 (CR) 1对每一个布尔测试 , 正确条件是否被检查? 2比较操作符是否正确? 3布尔表达式是否通过内部否定操作进行了简化 4每个布尔表达式是否都正确? 5比较操作是否存在不引人注意的副作用? 6"&&"是否被不小心替换为 ''&"? ''||''是否被不小心替换为''|"? 流程控制缺陷 (CF) 1对于每一个循环 : 是否选用了最佳的循环结构? 2所有的循环是否都能结束? 3如果一个循环有多个出口 , 是否每个出口都有必要并且得到正确处理? 4switch 声明是否都有 default 条件? 5是否所有的 case-switch-break 对应关系都已更正并加上批注？ 6是否 named break叙述都跳到正确的地方？ 7循环和分支的嵌套是否过深 ?是否正确? 8是否有 if 嵌套可以转换程 switch 嵌套? 9空控制叙述是否都正确，并加上括号及批注？ 10所有的异常是否都得到了正确的处理 11每一个方法在是否都结束? 输入输出缺陷 (IO)