代码走查单(很详细的资料)

代码走查

代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法,代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。

最近对项目组进行代码评审，发觉需要对代码评审中找到的问题进行一下分类，大概可以分成以下几类问题：1. Comment注释没写，或者格式不对，或者毫无意义2. Coding Standard没遵守代码规范3. Existing Wheel重复现成的代码，或者是开源项目，或者公司已有代码4. Better practiceJava或者开源项目，有更好的写法5. Performance bottle and Improvement性能瓶颈和提高6. Code Logic Error代码逻辑错误7. Business Logic Error业务逻辑错误代码审查列出问题的类型，并有解决情况报告11月23日代码走查——项目走向成功的锦囊之一说起代码走查，相信每个人都不陌生，但为什么要执行代码走查，什么时候来执行代码走查，如何有效执行代码走查，很多人的看法和见解都不一样。

一般的看法，认为代码走查是一种非正式的代码评审技术，它通常在编码完成之后由代码的作者向一组同事来讲解他自己编写的代码，由同事来给出意见。

这种做法在很多做软件开发组织中经常采用。

但从实际执行效果来看，成效并不都那么明显，反而很多组织的这种做法有浪费时间之嫌。

主要是因为代码走查活动时间有限，而参加代码走查的人之前没有较多的时间来提前了解被走查的代码，故而在实际执行时能被走查的代码所占的比例并不高，同时也发现不了多少本质问题。

随着软件外包业的发展，它有别于软件产品开发，客户对于产品的要求不再局限于系统是否能够正确运行。

而是在设计、代码的品质上也有了更多的要求。

有的客户甚至会在我们每次交付后先来检查我们的代码品质，只要是代码不符合要求就会被拒绝。

但在项目的实际执行中，面对客户的这些要求，我们又常常遇到诸如编写的代码不符合规范；编码效率低；代码的可重用性低；代码错误多等现象，从而影响到项目的时程和交付的品质，影响到客户对我们的满意度和对我们专业程度的质疑。

软件测试(代码走查、检查与审查)

4、传递给被调用模块的实参属性是否与其形参属性匹配？
5、传递给被调用模块的实参量纲是否与其形参量纲匹配？
6、调用内部函数的实参的数量、属性、顺序是否正确？
7、是否引用了与当前入口点无关的形参？
8、是否改变了某个原来仅为输入值的形参？
9、全局变量的定义在模块间是否一致？
10、常数是否以实参形式传递过？
1）程序是够易于理解？
2）高层次的设计是够可见且合理？
3）低层次的设计是否可见且合理？
4）修改此程序对评审者而言是否容易？
5）评审者是否会以编写出该程序而骄傲？
还要要求评审人给出总的评价和建议的改进意见。
评审结束后，参与者会收到自己的那两个程序的匿名评价爱表，此外还会收到一个带统计的总结，说明在所有的程序中其程序的整体和具体得分情况，以及他对其他程序的评价爱与其他评审人同意程序打分的比较分析情况。
2、桌面检查胜过没有极限嘻哈，但其效果远远逊色于代码检查和代码走查。
同行评审
（peerrating）
1、同行评审的概念
同行评分是一种依据程序整体质量，可维护性、可扩展性、易用性和清晰性对匿名的程序进行技术评价的技术。改技术的目的是为程序员提供自我评价的手段。
2、实施过程：
选出一名程序员来担任这个评分过程的管理员，管理员又会挑选出大约2~20名参与者，保持匿名，这些参与者否应具有相似的背景要求每名参与者都挑选出两个由自己编写的程序以供评审。其中的一个程序应是参与者自认为能代表其自身能力的最好的作品，而了另一个则是参与者自认为质量较差的作品。
3、代码走查的意义：
提出的建议应针对程序本身，而不是针对程序员。换句话说，软件中存在的错误不应该被视为编写程序人员自身的弱点。相反，这些错误应被看作是伴随着软件的艰难性所固有的。

【软件工程】【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
一个集合，例如数组和矢量，应采用复数命名来表示队列中存放的对象类型。命名应采用完整的英文描述符

代码走查报告

代码走查报告是开发流程中非常重要的一环，它有助于保证代码的质量和可维护性，以及提高代码的可读性和可重复性。

在本文中，我们将对进行详细的介绍和分析。

一、什么是？是一种针对代码质量的检测报告，它是由软件开发团队对已完成的代码进行全面的检查和分析，以便发现其中的问题，并提出解决方案和优化建议。

这个过程通常由开发团队内的人员或第三方专业人员完成，以确保代码质量和可维护性达到最佳水平。

二、为什么需要？在现代软件开发流程中，代码质量和可维护性已成为关注的焦点之一。

开发人员需要将代码的质量视为重要目标，以确保产品的成功并获得用户的信任。

代码走查是一个非常重要的步骤，因为它可以确保代码的可读性，规范性和一致性，同时还可以发现潜在的风险和错误，以便及时修复。

三、的主要内容通常包括以下内容：1.代码结构和架构分析在代码走查过程中，团队需要对代码的结构和架构进行分析。

这可以帮助他们理解代码的组织结构，查找潜在的问题，并提出优化建议。

这是非常重要的，因为代码的结构和架构直接影响代码的可维护性和可扩展性。

2.代码正确性和健壮性检查代码走查的一个主要目的是发现潜在的问题和错误，以避免出现系统崩溃或其他故障。

因此，团队需要对代码进行正确性和健壮性检查，以确保代码的稳定性和可靠性。

3.代码可读性和可维护性评估代码的可读性和可维护性也非常重要。

开发人员需要编写易于理解和修改的代码，以便其他团队成员可以更轻松地维护和扩展代码。

在中，团队通常会对代码的可读性和可维护性进行评估，并提出改进建议。

4.代码规范性检查在团队中建立一致的编程规范对于确保代码的质量和可维护性至关重要。

因此，在代码走查过程中，团队需要对代码的规范性进行检查，并确保所有团队成员都遵守相同的规范。

这可以帮助团队创建一致的、易于维护和修改的代码库。

5.性能分析和瓶颈排查除了上述内容，还应包括性能分析和瓶颈排查。

这可以帮助团队确定代码中的性能问题，并提出优化建议。

这是确保软件系统高效稳定运行所必需的一步。

JAVA代码走查规范

在分支处理时，先简单后复杂代码嵌套时(如if,if,if,if层层嵌套)，不宜太深；强制类型转换前，需要判断是否可以转换(installof)；在用到外部包时用import 导入，不得出现类似于“java.util.List listData ”的情况使用统一的方式打印调试信息，不得随意“System.out.println()” 不是主程序，不能出现main函数不需要用public的方法，一律不用；内部变量List类型使用后，需要clear（）一下字符串不宜连续多个相加，如：A= B + C + D + E 在使用不确定是否为空的变量或对象前，必须判断输入参数的所有异常值是否已直接测试？函数返回值类型正确吗？调用者是否对“返回值为null”的情况进行特殊处理？函数的返回值是否全面反应了各种状态和结果？对于重复出现并完成同样单一功能的一段代码，是否用函数对其进行了封装？每一个自定义的数据结构类都应该实现 toString() 方法错误或异常信息提示正确吗？有没有不可能执行到的代码？有没有未引用的变量、标号和常量？尽量使用简单的语句，不使用生僻的语句文件、数据库和注册表等打开后，在对其进行操作之后是否进行了关闭？对于使用附带例外的函数是否增加了例外处理程序？如对数据库或文件操作。注意程序的可移植性，注意平台相关性的内容，如文件分隔符、文件名是否大小写敏感等 + F
待测模块标识：待测模块标识：待测模块版本序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 编码规范检查项
38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

代码走查报告

代码走查报告引言：在软件开发的过程中，代码走查是一种非常重要的活动。

通过代码走查，开发人员可以发现潜在的错误、代码质量问题以及潜在的安全风险。

本报告旨在对一份代码走查结果进行分析和总结，并提出相应的优化建议，以提高代码质量和开发效率。

一、代码结构和可读性：首先，通过对代码的结构进行走查，我们注意到代码的组织结构合理，模块化程度高，各个模块之间的关系清晰。

这使得代码易于阅读和理解，方便后续的维护和扩展。

然而，在代码的命名上存在一些问题，如变量和函数名缺乏描述性，不符合代码规范。

因此，建议开发人员在命名时要遵循代码规范，确保命名的准确性和描述性。

二、错误处理和异常处理：代码走查发现，代码中缺乏对错误和异常情况的处理。

这可能导致程序意外终止，影响用户体验和系统的稳定性。

建议开发人员加强对错误和异常情况的处理，例如使用try-catch语句来捕获异常并进行相应的处理，或者合理地使用断言语句来检查代码逻辑的正确性。

三、安全性问题：通过代码走查，我们发现在代码中存在一些潜在的安全风险。

例如，未对用户输入进行验证和过滤，可能导致代码受到SQL注入、跨站脚本等安全攻击。

因此，建议开发人员在接收和处理用户输入时，要进行严格的验证和过滤，确保代码的安全性。

四、性能和效率：性能和效率对于软件系统的稳定运行和用户体验至关重要。

通过代码走查，我们注意到在一些地方存在性能瓶颈和效率问题。

例如，代码中存在重复调用数据库查询的情况，没有充分利用缓存机制等。

建议开发人员在开发过程中要注意性能和效率，避免无谓的重复计算和调用，合理运用缓存和优化算法，以提高系统的响应速度和效率。

五、代码规范和一致性：代码规范和一致性对于代码的可读性和维护性至关重要。

通过代码走查，我们发现代码在规范和一致性方面存在一些问题。

例如，代码缩进不一致、括号的使用不规范等。

建议开发人员要养成良好的编码习惯，遵循代码规范，保持代码的一致性，并通过代码格式化工具来提高代码的可读性。

代码走查报告

代码走查报告代码走查是软件开发过程中的一项重要工作，通过对源代码的仔细审查和检查，可以及早发现潜在的问题和错误，提高代码质量和可维护性。

本报告旨在对最近进行的代码走查工作进行总结和分析，并提出相应的改进措施。

一、背景介绍代码走查是一种验证软件产品是否满足质量标准的活动。

通过对代码的检查来找出代码中的错误、缺陷和不合规范的部分，并提出改正措施，以确保代码的可读性、可靠性和扩展性。

二、走查目标针对本次代码走查，我们的目标是：1.检查代码的规范性和风格是否符合团队约定的标准；2.对代码中的潜在问题进行排查，例如错误处理、内存泄漏等；3.寻找代码中的性能缺陷和安全隐患；4.评估代码的可维护性，是否易于理解和修改。

三、走查方法本次代码走查采用了以下方法：1.静态代码分析：使用代码分析工具对代码进行静态分析，自动检测语法错误、潜在的缺陷和不规范的代码风格；2.手动代码审查：通过仔细阅读代码，结合经验和专业知识，寻找代码中的问题和改进空间。

四、检查结果在进行代码走查后，我们总结了以下几个方面的检查结果：1.代码规范性和风格代码规范性和风格是保证代码质量和可维护性的重要因素之一。

根据我们的走查，大部分代码的命名规范和代码风格符合团队约定的要求，但仍然存在一些不规范的情况，例如未遵守命名规则、缺少注释等。

我们建议在日后的开发过程中加强对代码规范的培训和监督，以提高整体的代码质量。

2.潜在问题排查我们对代码中常见的潜在问题进行了排查，包括错误处理、异常处理、内存泄漏等。

通过走查，我们发现了一些存在潜在问题的代码段，例如缺少错误处理、内存未释放等。

针对这些问题，我们建议开发人员及时进行修复，以保证系统的稳定性和可靠性。

3.性能缺陷和安全隐患在代码走查过程中，我们特别关注了性能缺陷和安全隐患。

通过对代码的审查，我们发现了一些可能导致性能瓶颈和安全漏洞的地方，例如循环嵌套、未加密的敏感信息传输等。

我们建议开发团队对这些问题进行进一步优化和改进，以提高系统的性能和安全性。

D7-XX项目-代码走查记录-yyyymmd

编号：NC-GS-IV-CWR版本：v1.0阶段标注：DEnjoy Your Product代码走查记录vx.y《XXX项目》编制：审核：标审：会签：批准：XX有限公司2019年XX月更改历史页目录代码走查记录表 (1)附录：文档模板说明 (7)代码走查记录表开发人员：评审日期：年月日代码走查记录表开发人员：评审日期：年月日代码走查记录表开发人员：评审日期：年月日代码走查记录表开发人员：评审日期：年月日代码走查记录表开发人员：评审日期：年月日代码走查记录表开发人员：评审日期：年月日开发组长：检查人：附录：文档模板说明1级标题字体：微软雅黑加粗二号格式段落：多倍行距设置值 3 其他0 2级标题字体：微软雅黑加粗小二格式段落：多倍行距设置值 3 其他0 3级标题字体：微软雅黑加粗三号格式段落：多倍行距设置值 3 其他0 4级标题字体：微软雅黑加粗小三格式段落：多倍行距设置值 3 其他0 5级标题字体：微软雅黑加粗四号格式段落：多倍行距设置值 3 其他0 6级标题字体：微软雅黑加粗小四格式段落：多倍行距设置值 3 其他0 7级标题字体：微软雅黑加粗小四格式段落：多倍行距设置值 3 其他08级标题字体：微软雅黑加粗小四格式段落：多倍行距设置值 3 其他09级标题字体：微软雅黑加粗五号格式段落：多倍行距设置值 3 其他0正文格式：字体：微软雅黑小四格式段落：首行缩进2字符 1.5倍行距表格内文字格式：表格标题：微软雅黑加粗五号表格标题底纹颜色：灰色色值：红黄蓝数值均为217表格正文：微软雅黑五号正文样例文字编写格式：字体：微软雅黑斜体五号表格标题底纹颜色：灰色色值：红黄蓝数值均为64格式段落：首行缩进2字符 1.5倍行距8/ 12页眉页码格式：封面格式：无页码无页眉文档更新记录页至目录页格式：有页眉有页码页码设置为罗马数字：ⅠⅡⅢ页面低端居中位置文档正文格式：有页眉有页码页码设置为阿拉伯数字页面低端居中位置并显示当前页和总页数。

代码走查

代码走查，英文词语叫：Code Review，也叫“代码审查”，它是软件公司的一项传统保留项目。

1.代码走查的形式代码走查的形式有很多种，主要有以下几种形式：●每日走查：只针对每日提交的内容进行评审，走查时间和地点都比较灵活。

●专项走查：针对某个具体问题或者专题进行走查。

评审人需要提前发送评审内容给大家进行预审，然后安排专门的会议室进行评审，时间较长。

●结对互查：提交代码前指定某位同事进行线上评审，评审通过后才能合入代码。

本文要介绍的是每日代码走查，就是大家围在一台开发机周围，逐一轮换讲解所有提交的内容。

就即使是每日代码走查，也被我们团队玩出了花样：●谈心式走查●批判式走查●半蹲式走查●伴侣式走查2.代码走查的好处持续、有效的开展代码走查，将会收获许多收益，具体表现在：●能及时发现代码中的Bug，保证版本质量。

●提升代码的可读性、可维护性，建立团队共同的编码风格。

●有利于知识共享，打破技能壁垒，避免单点故障。

●通过展示自己的优秀代码和设计思路，提升了个人成就感。

●通过讲解自己的代码，对个人沟通能力也是一种提升。

特别是对于平时比较内向或者不太喜欢发言的同学。

●给大家提供了一个每天交流、沟通的平台。

工作一天了，也挺累的了，是时候停下手工的编码工作，一起说说话，交流一下了。

3.代码走查中的“坏味道”虽然代码走查有这么多好处，可在实施的过程中并不会像想象中的那么美好，会遇到各种各样的问题，总结起来的“坏味道”有：●开发的时间本来就不多，再加上代码走查，会打乱开发节奏。

●评审的同事对代码不熟悉，发现不了问题。

●讨论发散或者纠缠在某个具体细节中，导致时间把控不好。

●评审量大。

只能走查部分同事的代码，其他同事的内容没有覆盖。

●提问题的总是那几个人，其他人都是围观群众。

4.如何做有效的代码走查虽然代码走查很多团队都在做，但要想真正做好它并不是件容易的事情。

我们团队经过长期实践，摸索出一些经验和大家分享：4.1代码走查的时间代码走查建议在固定时间举行，当团队养成习惯后，就会很自然成为团队日常工作的一部分。

代码走查表

走查前准备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 无用的注解已经删除。

代码走查单(很详细的资料)

代码走查的最主要的目的是为了发现程序中的逻辑错误，编程风格方面的错误可以通过风格检查的工具去检查。

如下的检查单给代码走查的专家发现逻辑错误提供了一个很好的帮助。

序号检查项
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、是否某个子类仅使用了父类的部分属性或方法?。

代码走查总结报告

（３）存在不同数据类型的比较吗？
]
否
重要
变量值问题：
（１）变量的初始化或缺省值有错误吗？
（２）变量发生上溢或下溢吗？
（３）变量的精度够吗？
否
重要
逻辑判断问题：
（１）由于精度原因导致比较无效吗？
（２）表达式中的优先级有误吗？
（３）逻辑判断结果颠倒吗？
否
重要
循环问题：
（１）循环终止条件不正确吗？
（２）无法正常终止（死循环）吗？
否
重要
Case语句的结尾是否忘了加break？
否
重要
是否忘记写switch的default分支？
'
否
常量
重要性
审查项
结论
是否使用含义直观的常量来表示那些将在程序中多次出现的数字或字符串？
是
|
重要
如果某一常量与其它常量密切相关，是否在定义中包含了这种关系？
是
函数设计
重要性
审查项
结论
：
参数的书写是否完整？
否
重要
是否将malloc/free和new/delete混淆使用？
@
是
重要பைடு நூலகம்
malloc语句是否正确无误？例如字节数是否正确？类型转换是否正确？
是
重要
在创建与释放动态对象数组时，new/delete的语句是否正确无误？
是
其它常见问题
$
重要性
审查项
结论
重要
数据类型问题：
（１）变量的数据类型有错误吗？
（２）存在不同数据类型的赋值吗？
是
头文件中是否只存放“声明”而不存放“定义”
是
程序的版式

java代码走查计划书

WATER Corporation代码走查计划书Version 2.0XXX文档修改记录目录1. 进度计划 (5)2。

待评审物 (5)3. 成员角色 (6)4。

基本原则 (6)4。

1 代码评审原则 (6)4.2 评审指导文档 (7)5。

走查过程定义 (7)5。

1 代码走查计划准备阶段 (7)5.2 个人代码走查阶段 (8)5。

3 代码走查会议阶段 (8)5.4 缺陷修改与关闭 (8)1. 进度计划小组代码走查活动时间进度安排如下所示：2. 待评审物待评审物名称：银行系统取款模块源代码V1。

（SC-Banking-Withd raw- V1.0）Figure 1 UML Model for Banking-Withdraw工作任务时间安排制定编码规范文档3月20日 19：00-21:00制定代码走查CheckList,提交待评审项目3月21日 19：00-21:00评审人员执行个人走查,利用工具记录发现的问题3月22日 13：00-15:00小组走查会议，完成缺陷记录报告,3月22日 15：00—16：30开发人员完成代码修改3月23日9:00-12:30评审人员再次走查修改过的代码3月24日19:00-20：30跟踪发现的问题直至问题关闭3月25日9:00-11:003.成员角色组长：制定代码走查的计划、安排代码走查活动职责分工、组织代码走查,确保代码走查的过程规范执行；质量保证人员：制定CheckList，记录代码走查会议以及完成问题记录报告；开发人员:完成代码，在代码走查中引领走查人员读代码，走查结束后并根据走查的问题记录报告完成代码修改;评审人员：依据编程规范和CheckList执行代码走查，使用Jupiter工具记录发现的问题。

4.基本原则4.1 代码评审原则1.一次检查少于200～400行代码2.努力达到一个合适的检查速度：每小时少于300~500行代码3.有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟4.在复审前,代码作者应该对代码进行注释5.建立量化的目标并获得相关的指标数据，从而不断改进流程6.使用检查表（checklist)肯定能改进双方（作者和复审者）的结果7.验证缺陷是否真正被修复8.管理人员要营造良好的氛围（文化），使大家可以积极地对待缺陷的发现，发现足够多的缺陷,只关心问题是什么、怎样引起的，而不关心是谁写的代码9.清楚度量工具（”Big Brother"）的作用——度量工具是双刃剑，要小心使用10.自我约束：即使没有时间完成所有代码的检查，也应该尽可能去做，哪怕是一部分11.轻量级的code review是高效率的、可行的，并能有效地发现缺陷4.2 评审指导文档附录1 《JAVA编程规范》附录2 《代码走查检查单》5.走查过程定义5.1 代码走查计划准备阶段主要活动：1.开发人员提交待评审代码及其需求文档，提出走查申请；2.组长审核及批准走查申请；3.QA制定走查计划、代码检查单及Java编程规范文档，生成待评审包；4.组长将待评审包上传至SVN。

代码走查检查单

3
编码时间模块名称测试完成日期
代码走查
；
能。化为局部变量。系。英文单词和拼音混写。
用同样的名称。
为单位，Tab键为4个空格。
文件编码制表时间
□ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合
■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合
4
。定义过的常量。
□ 不符合 □ 不符合 □ 不符合 □ 不符合
□ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合
■ 符合 ■ 符合 ■ 符合 ■ 符合
开至少两个Tab键。
的1/5~1/3。
段空一行；要描述。
□ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合
□ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合

代码检查单

C / C++代码审查表
已经实现）
审查项
循环语句与判断语句中，不允许对其它变量进行计算与赋值。

（ClearCode已经实现）
子程序参数错误
审查项
使用sprintf、strcpy向一
操作使用不一致
由于指针再分配，引起指针原先指向的内存块被丢失了
必须对动态申请的内存做有效性检查，并进行初始化；动态内存的释放必须和分配成对以防止内存泄漏，释放后内存指针置为NULL。

【规则
返回指向局部变量的指针
程序中局部变量不要与全局变量重名。

【规则4-8】（ClearCode 一条语句只完成一个功能。

【规则6-1】（ClearCode已经实现）
审查项
适用范围
制订本检查单的主要目的是帮助开发人员在代码走查的过程中对编程风格、程序错误的检查，如果有时间和精力可以做查找程序逻辑错误和处理流程的检查。

本检查单适用于CDMA 1x系列软件的代码。

参考资料
《CHM5K系列软件代码检查单》
《平涛,代码BUG字典（v1.2）,2002.11.26》。

代码走查规范

维远泰克代码走查规范文件编号：起草部门：测试组审核人：签发人：批准日期：版本标识：目录1引言...................................................................................................................................... 错误!未定义书签。

1.1目的 .................................................................................................................................... 错误!未定义书签。

1.2说明 .................................................................................................................................... 错误!未定义书签。

2代码走查 (4)2.1检查点 (4)2.2走查流程 (4)2.2.1走查流程图 ......................................................................................................... 错误!未定义书签。

2.2.2流程概述............................................................................................................. 错误!未定义书签。

2.2.3具体流程............................................................................................................. 错误!未定义书签。

软件测试-软件代码走查清单模板

软件代码走查清单检查人： ____________________检查口期：20年月口审查内容： ______________________________________________________________________审查结果：通过口不通过口说明： _____________________________________________________________________________序号 33~执行情况说明34函数的声明中完整地书写参数（包括类型和名）而不只是参数的类；合理地安排参数的名字及顺序参数命名及顺序，不要使用单字符参数名； 35 参数的个数不要超过十个;36 不要使用类型和数目不确定的参数; 37不要省略函数返回值的类型;38函数名字与返回值类型在语义上最好不要 394041424344 45464748存在冲突;不要函数的将正常值和错误标志混在一起返回，正常值应当用输出参数获得，而错误标志用“ return n语句返回;在函数体的“入口处”，最好用“assert v对参数的有效性进行检查；不要滥用 “assert”语句，混淆非法情况与错误情况，出错是必然存在的并且是一定要作出处理的；不要用“ return w语句返回指向“栈内存” 的“指针”或者“引用”对于在函数中不会改变的参数，使用“const” 提高函数的健壮性;函数体的有效代码量一般应为50行; 减少公用变量（包括全局变量）在多个函数中的使用，以保证函数的独立性，低耦合性等特性；函数体的有效代码量不能超过200行，一般情况下超过则必须拆分；七、内存管理用"malloc"或“new”申请内存之后, 立即检查指针值是否为“NULL” ；要为数组和动态内存赋初值；八、C++函数的高级特性。

手机软件部_代码走查检查项分类清单

说明及举例
示例
编程规范
说明
文文
“变量初始化、变量和宏命名重复或冲突、数据类型匹配、精度丢失、部分if和case的分支处理缺省和异常”等方面pc-lint做得很出色，因此这方面人工走查可以不必关注。部分pcpc-lint告警 lint做得不完美的方面下面分别列出，需采用人工走查。对多线程访问的全局变量缺少信号量保护。缺少关闭中断保护。开关中断的保护范围不当。中断服务程序使用危险的操作或者中断服务程序过于复杂耗时。多个信号量的使用关系不清晰，可能互锁。资源没有及时释放，如定时器、信号量、网络端口等。文件打开未保证所有情况下关闭。未对申请资源是否成功进行判断保护。异常处理或退出时，没有释放所有该释放的内存等资源。除数或模是否可能为零。在数值计算过程中是否可能出现溢出。对函数入口的指针进行NULL检查。对异常参数输入、异常信号输入、异常函数返回的处理和保护。断言中判断失败的没有进行错误处理。断言中对含复杂和可能再次出错的操作隐患。断言在发行版本中仍然有效（断言应该只针对debug版）。 if、switch等语句有遗漏分支没有处理。循环的起点错误，如是0还是1。循环的终点错误，如不正确使用 > , >= , < , <= 等比较符号。在for 循环体内修改循环变量和循环变量的边界，可能导致循环失去控制。循环变量类型所能取的最大值小于循环上限宏值，引发死循环；循环上限是变量，且循环上限变量类型大于循环变量类型，有死循环隐患。
开发人员实施走查时建议按子项分类，每次最好只走查1个走查子项，多次重复扫描。开发人员实施走查时建议按子项分类，每次最好只走查1个走查子项，多次重复扫描。走查实现、设计层面可以不关注代码细节，走查编码、内存层面可以不关注总体逻辑。走查实现、设计层面可以不关注代码细节，走查编码、内存层面可以不关注总体逻辑。

代码走查简介

代码走查简介1.代码审查的思想代码审查是一种制度，通过相关人员分头阅读代码，并在会上讨论，以发现一些编程过程中常犯的错误、笔误、或不符合管理/规范的代码等。

事实证明，这是一种非常有效的手段，被公认为是软件开发必须的过程之一。

代码审查一般放在编译通过之后，目的是检查通用语义、用法等中级错误。

应当说明的是，代码审查仅仅作为一种代码质量保证的方式，代码作者应该认识到代码审查是在帮自己提高效率和质量，是自己分内的事情，不是大家的事、不是上司的事、也不是开发组的事。

2.代码审查指南代码审查本身是针对代码，不是针对生产者制定议程并遵守议程(由主持人把握)限制争论和辩驳可以对每个问题都发表见解，但不要试图解决所有记录的问题作书面笔记限制参与者人数，并坚持事先做好准备(限制每次会议中审查人的人数，与会人数不做限制，但不赞成都参与讨论)建立检查表保证代码审查所需要的资源和时间对所有复审者进行有意义的培训(技术、过程以及心理学因素)复审以前所做的复审3.代码审查的几种方式自查；开发人员自己通读自己的代码组内互查：开发人员组内针对代码进行讨论，以期发现代码中的错误代码公开走查(inspection)：组织专门的人员(审查人)进行准备，以作者讲解的形式进行代码的审查下面段落主要是针对代码公开走查的方式进行说明。

4.前期准备时期代码走查模块列表的提交：各模块的负责人决定需要进行代码走查的关键模块，并提出列表文档：列表文档格式如下：(如果觉得麻烦，可以在详细设计的目录中作出标注，提交给测试组)。

不过需注意的是，每次进行审查的代码，应是逻辑上相对完整、独立的一小块代码，一般在100行左右，至少在代码审查会议前三天提出。

代码审查工作开展时间的确定：每周选择固定时间(暂定周二、周四下午2:00—4:00)，进行代码审查，以便此工作能够长期和稳定的展开。

代码检查表(checklist)：表中列出编码过程中容易出现的一些错误，以便于代码审查人在全面审查代码的同时，能够有重点的进行代码检查5.代码公开走查会议的形式角色划分：主持人、作者、审查人、记录人、与会者角色职责说明：主持人：把握整个会议的进度和议题，避免会议陷入无效的争端或讨论作者：从功能、编写思路等方面讲解代码审查人：需要提前准备熟悉代码并对代码质量进行把关的人员(一到两名，需要详细阅读代码)记录人：对会议过程进行记录的人员，主要记录针对代码提出的问题(有专门的记录表格)旁观者：代码公开走查采取公开的形式，与会者是对本次审查比较感兴趣的人员。