代码审查(Code Review)清单
代码review的范围 -回复
代码review的范围-回复代码review的范围，是指在软件开发过程中对代码的检查和评审。
代码review是一种常见的开发实践，旨在提高代码质量、发现潜在问题和改进代码的可读性、可维护性。
在本文中，我们将一步一步回答以下问题，深入探讨代码review的范围。
1. 为什么需要代码review？2. 代码review的好处是什么？3. 代码review的范围包括哪些方面？4. 代码review的注意事项是什么？5. 代码review的最佳实践是什么？1. 为什么需要代码review？软件开发是一个复杂的过程，涉及到多个人员的协作和大量的代码编写。
单靠个人的能力和经验无法保证代码的质量和正确性。
而代码review提供了一种机制，通过对代码的检查和评审，可以找出潜在的问题和改进空间，提高代码的质量和可维护性。
2. 代码review的好处是什么？代码review有多个好处：a. 提高代码质量：通过检查和评审，可以发现潜在的bug、逻辑错误和性能问题，从而改进代码的质量。
b. 加强团队合作：代码review是团队成员之间的一种交流和合作机会。
通过review，可以促进团队成员之间的沟通和互动，加强团队合作和凝聚力。
c. 学习和分享知识：代码review可以帮助团队成员互相学习和分享经验。
在review过程中，可以发现和学习其他人的优秀代码实践和技巧。
d. 提高代码可读性和可维护性：通过review，可以发现代码中的冗余、复杂和不必要的部分，从而提高代码的可读性和可维护性。
e. 提前发现问题：通过review，可以在代码进入测试或者生产环境之前发现问题。
这可以降低后续修复问题的成本和影响。
3. 代码review的范围包括哪些方面？代码review的范围通常包括以下几个方面：a. 代码规范和命名：检查代码是否符合项目的代码规范和命名约定。
b. 代码结构和组织：检查代码的模块划分、类和函数的设计等是否合理，代码是否易于理解和维护。
代码审查(CODE REVIEW)
代码审查(CodeReview)一、概述代码审查（CodeReview)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等，目前监控团队虽然提倡代码审查，也有相关的辅助工具，但是一直没有真正的推行起来，这半年的时间里，一些线上的bug如果经过代码审查，基本上可以避免的，大家也逐渐认识到代码审查可以有效地提高代码质量。
二、代码审查的作用1、提高代码质量。
通过代码审查来发现bug及代码中的不规范，这是不容置疑的，通过代码审查，代码将更加整洁，有更好的注释，更好的程序结构。
2、提高开发者开发水平。
开发者知道自己编写的代码会被同事审查，将会更加认真的编写代码，也将会督促开者不断地学习、向有经验的同事请教。
3、提高程序的可维护性。
一份程序代码将会有更多的同事熟悉，更好的代码质量，自然地也增加程序的可维护性。
4、提高开发者的对编码的责任感。
如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。
你写出的代码将更加整洁，有更好的注释，更好的程序结构——因为你知道，那个你很在意的人将会查看你的程序。
没有代码审查，你知道人们最终还是会看你的程序。
但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。
5、传播知识在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。
除非是同事的模块影响了自己的程序，他们从不相互交流。
这种情况的后果是，每个模块只有一个人熟悉里面的代码。
如果这个人休假或——但愿不是——辞职了，其他人则束手无策。
通过代码审查，至少会有两个人熟悉这些程序——作者，以及审查者。
审查者并不能像程序的作者一样对程序十分了解——但他会熟悉程序的设计和架构，这是极其重要的。
三、代码审查的执行障碍1、缺少代码审查的标准缺少代码审查的标准，往往审查人员习惯性地根据自身开发经验去进行代码审查，容易变成去挑毛病，找bug，容易产生不良地影响。
程序员必备的代码审查（CodeReview）清单【转载】
程序员必备的代码审查（CodeReview）清单【转载】在我们关于⾼效代码审查的博⽂中，我们建议使⽤⼀个检查清单。
在代码审查中，检查清单是⼀个⾮常好的⼯具——它们保证了审查可以在你的团队中始终如⼀的进⾏。
它们也是⼀种保证常见问题能够被发现并被解决的便利⽅式。
软件⼯程学院的研究表明，程序员们会犯15-20种常见的错误。
所以，通过把这些错误加⼊到检查清单当中，你可以确保不论什么时候，只要这些错误发⽣了，你就能发现它们，并且可以帮助你杜绝这些错误。
为了帮助你开始创建⼀个清单，这⾥列出了⼀些典型的内容：代码审查清单常规项代码能够⼯作么？它有没有实现预期的功能，逻辑是否正确等。
所有的代码是否简单易懂？代码符合你所遵循的编程规范么？这通常包括⼤括号的位置，变量名和函数名，⾏的长度，缩进，格式和注释。
是否存在多余的或是重复的代码？代码是否尽可能的模块化了？是否有可以被替换的全局变量？是否有被注释掉的代码？循环是否设置了长度和正确的终⽌条件？是否有可以被库函数替代的代码？是否有可以删除的⽇志或调试代码？安全所有的数据输⼊是否都进⾏了检查（检测正确的类型，长度，格式和范围）并且进⾏了编码？在哪⾥使⽤了第三⽅⼯具，返回的错误是否被捕获？输出的值是否进⾏了检查并且编码？⽆效的参数值是否能够处理？⽂档是否有注释，并且描述了代码的意图？所有的函数都有注释吗？对⾮常规⾏为和边界情况处理是否有描述？第三⽅库的使⽤和函数是否有⽂档？数据结构和计量单位是否进⾏了解释？是否有未完成的代码？如果是的话，是不是应该移除，或者⽤合适的标记进⾏标记⽐如‘TODO’？测试代码是否可以测试？⽐如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使⽤⽅法等。
是否存在测试，它们是否可以被理解？⽐如，⾄少达到你满意的代码覆盖(code coverage)。
单元测试是否真正的测试了代码是否可以完成预期的功能？是否检查了数组的“越界“错误？是否有可以被已经存在的API所替代的测试代码？你同样需要把特定语⾔中有可能引起错误的问题添加到清单中。
软件开发中的代码审查与审核
软件开发中的代码审查与审核在软件开发过程中，代码审查和审核是必不可少的环节。
通过对代码进行审查和审核，团队成员可以发现并纠正潜在的代码缺陷，提高代码质量，减少错误。
本文将介绍代码审查和审核的基本概念、作用以及最佳实践。
一、代码审查和审核的定义代码审查（code review）是一种通过检查获取代码来识别错误、优化代码和提高代码质量的过程。
它通常由团队成员或专家开发者进行，他们会定期地检查代码并提出建议改进。
代码审查可以在不同的阶段进行，例如在开发中、测试前或发布前。
代码审核（code inspection）通常是在开发过程的早期阶段进行的一种活动。
代码审核是一项严格的、程序化的过程，它旨在为软件产品的开发提供质量保证，并确保代码符合规范、标准和设计要求。
二、代码审查和审核的作用1. 提高代码的质量代码审查和审核可以帮助团队及时发现和纠正代码中的错误。
它可以帮助团队避免在开发过程中增加bug，降低代码质量。
2. 减少错误和延误通过代码审查和审核，团队可以发现潜在的缺陷并及时修复，这样可以减少错误和延误。
3. 提高团队的技能通过观察其他人的代码、看到其他开发者的解决问题的方法，团队成员可以对自己口袋中的技能进行提高。
三、代码审查和审核的最佳实践1. 审核和审查应该是有计划的团队应该有一个明确的计划，规定何时进行审查和审核。
例如，在完成某个功能时，应该对代码进行一次审查；在保持代码更新时，应该进行定期的审核。
2. 团队成员应该具备针对性的技能团队需要一个具有针对性的技能集来执行审查和审核。
过程中，正在被审查或审核的代码需要专业人员的对其进行评估。
3. 审核和审查的量要适度团队应该在一定的时间内处理适量的代码，以便在短时间内实现审查和审核的目标。
如果关注的代码量过大，代码审核和审查可能会超时导致随意的结果丢失，更损失人员的已有知识和技能。
4. 使用代码审查和审核工具使用代码审查和审核工具可以大大简化过程，并提高效率。
Code Review Checklist
以下是用于开发人员代码review的 Macadamian's指南 . 在代码提交控制前，它们应该按照以下的规则检查。
我们公开这份检查表是希望给任何开发部门的同行代码评审提供一个简要的参考。
你可以直接按本表开始评审，当然，更好的办法是按照开发实际作出修改后使用。
目录General Code Smoke Test通用测试Comments and Coding Conventions注释和代码风格Error Handling错误处理Resource Leaks资源泄漏Control Structures控制结构Performance性能Functions函数Bug Fixes bug修复Math数学General Code Smoke Test 通用测试Does the code build correctly?No errors should occur when building the source code. No warnings should be introduced by changes made to the code.代码可以正确编译：编译代码时应无错误。
Does the code execute as expected?When executed, the code does what it is supposed to.代码是否像预期结果那样执行？Do you understand the code you are reviewing?As a reviewer, you should understand the code. If you don't, the review may not be complete, or the code may not be well commented.你理解正在review(评审)的代码了吗？作为一个评审者，你应该理解这些代码；否则将导致评审不充分或效果不太好。
代码审查参考文档
代码审查参考文档代码审查〔codereview〕是保证软件质量的一个重要环节，通过审查代码能够发现代码中可能存在的咨询题并给予纠正，这些咨询题可能包括设计上的、实现上的或者编程风格等多方面。
本文档通过列举代码编写过程中的一些常见的细节咨询题，为代码审查环节提供参考。
Java代码一、对象和变量1.存在未被使用的变量Eclipse会自动用下划线标出2.对象的重复创立这是系统中普遍存在的咨询题，比方：publicclassPrtGrpEndorsementBL{privateGlobalInputmGlobalInput=newGlobalInput();privatebooleangetInputData(VDatacInputData){mGlobalInput=(GlobalInput)cInputData.getObjectByObjectName("GlobalInput",0);returntrue;}}那个地点mGlobalInput对象属于重复创立，因为在getInputData方法里会对它进行赋值，mGlobalInput使用的应该是从jsp页面传进的对象，因此改为privateGlobalInputmGlobalInput=null;又如：Stringmsg="";if(..){msg="A";}else{msg="B";}那个地点msg同样属于重复创立，改为Stringmsg=null;3.变量的作用域Java的局部变量能够定义在函数的任何位置，有局部由c转学java的程序员习惯将变量都定义在函数的顶部，因为在c里只能那样定义。
但实际上变量的作用域越短程序的内聚性就越高，耦合性也更低，程序更轻易理解，因此在java里应该在使用前才定义变量。
4.局部变量的危害定义过多的不必要的局部变量是造成系统难以维护的缘故之一，因为每增加一个局部变量我们就要先化时刻往理解那个局部变量的意思，因此我们要减少局部变量的使用。
Code Review 代码审查
Code Review 代码审查Code Review 代码审查 (1)1．关于Code Review (2)1.1 Code Review的目的 (2)1.2 Code Review的前提 (2)1.3 Code Review需要做什么 (2)1.3.1 完整性检查（Completeness） (3)1.3.2 一致性检查（Consistency） (3)1.3.3 正确性检查（Correctness） (3)1.3.4 可修改性检查（Modifiability） (3)1.3.5 可预测性检查（Predictability） (3)1.3.6 健壮性检查（Robustness） (3)1.3.7 结构性检查（Structuredness） (3)1.3.8 可追溯性检查（Traceability） (4)1.3.9 可理解性检查（Understandability） (4)1.3.10 可验证性检查(Verifiability) (4)1.4 Code Review的步骤 (4)2．Code Reivew的执行 (5)2.1．事前准备阶段 (5)2.1.1．CR的对象 (5)2.1.2．CR的内容 (5)2.1.3．评审规范和标准 (5)2.1.4．选择CR活动的参与者 (5)2.1.5．选择CR活动的实施方式。
(5)2.2．实施阶段 (6)2.2.1．准确记录 (6)2.2.2．讲解与提问 (6)2.2.3．逐项审查 (6)2.2.4．注意气氛 (6)2.3. 事后跟踪跟踪。
(6)2.3.1. 确认发现的问题 (6)2.32. 修正问题责任者 (6)2.3.3. 修正结果确认者 (7)3．注意事项 (7)3.1. 经常进行Code Review (7)3.2. Code Review不要太正式，而且要短 (7)3.3. 尽可能的让不同的人Reivew你的代码 (7)3.4. 保持积极的正面的态度 (8)3.5. 学会享受Code Reivew (8)相关资料 (8)资料来源 (8)1．关于Code Review1.1 Code Review的目的Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。
java code review评分标准
Java 代码审查评分标准代码审查是确保代码质量的重要环节，它可以帮助выявить 和修复代码中的错误，提高代码的可读性和可维护性。
对于Java 代码，我们可以参考以下评分标准进行代码审查：1. 代码风格代码风格是指代码的書写格式和规范。
良好的代码风格可以提高代码的可读性和可维护性，使其更容易理解和修改。
Java 代码的代码风格可以参考 Oracle 官方推荐的 Java 编码约定。
2. 代码组织代码组织是指代码的结构和布局。
合理的代码组织可以提高代码的可读性和可维护性，使其更容易理解和修改。
Java 代码的代码组织可以参考以下原则：使用清晰的命名约定，使变量、方法和类的名称能够准确反映其含义。
使用适当的注释，解释代码的意图和实现细节。
将代码划分为合理的模块或包，使代码易于管理和维护。
使用合理的缩进和空白，使代码易于阅读和理解。
3. 代码复杂度代码复杂度是指代码的理解和维护难度。
高的代码复杂度会降低代码的可读性和可维护性，使其更难理解和修改。
Java 代码的代码复杂度可以参考以下指标：圈复杂度（Cyclomatic complexity）：圈复杂度是衡量代码复杂度的一个指标，它表示代码中独立路径的数量。
高的圈复杂度意味着代码的逻辑更加复杂，更难理解和维护。
代码行数（Line of code）：代码行数是衡量代码长度的一个指标，它表示代码中包含的行数。
高的代码行数意味着代码更加冗长，更难理解和维护。
代码密度（Code density）：代码密度是衡量代码紧凑程度的一个指标，它表示代码中包含的字符数与代码行数的比值。
高的代码密度意味着代码更加紧凑，更难理解和维护。
4. 代码测试代码测试是指通过编写和运行测试用例来验证代码的正确性。
良好的代码测试可以提高代码的质量，降低代码中错误的发生概率。
Java 代码的代码测试可以参考以下原则：为每个代码模块编写测试用例，覆盖代码中的所有逻辑路径。
使用合理的测试数据，包括正常数据和异常数据。
代码评审清单
代码评审清单（Code Checklist ）产品,项目组名称；_宅急送_________ 产品项号名称，公共_______________ 版本号：被检杳人簽字：—检杳內容: _ _检查人螯宇，_____________________ 检查日期’______________________说明：是杏尽童避免了嵌会的立•弔篦杂芳雄是否併行了必茅而充分的汗释拎K是否代码拥亍路径是否清晰S罰Chi航是否有決4分支控制逻短复杂度是否合浬是否诜行了必更1门充分的注释同个循坏怎是吞仅执行了羊而明确的巧毙占械比校需要挣常数玫在比较表达式的前面否代彳礎丧奸格ig化并能疝苴逻辑结枸尽量孑哎在循开丙岀观近程谐月奇个吐务可作远程谓用次数是否小于以冈1中因数是吞仕抱定范围内Joinb on矽页产恪匹0己问題淸单.冋幅沐阚窟改n期修改n期楡杳SQL r 是冈1语句』碍弓用乎符画单引号T^MO select *开预的语句，必姦指出旦饶宇SF严禁使用ins«t m2 Uiblc: values "t ? , ? , "?) ＞必须指1岀具依更0jt值広字段避兌隐含的炎型转换(不同数据类型字段明加)子宣询前后必须加上桔号邀免在我here使用，1* / 1=2’这*怯廿戎作为部分条件禁上使用椰图禁上使用XX in 0 or XX血CKm中的元素个数不应超过500)禁止使用or超辽500个其止使用not in・建议使冃not exist婪止在一条河语句中恃月3层以丄的嵌套如具勺多表连莪盯「应该有主从之分，尽重从一个表取数Where子句过滤条杵，索引列或过遞记录最多氏条林应験在前面字符邑连接必须使用“ rCaw when吾匀中巳能出珂二、k、u以及is mill运算袴左连接写送必須带”cxuei'关佬宰伝稈诅用蓟摇伎端启否有不必萼的冗輛摇Java代码审查检查丧类定义缺陷(CD)代码评申检査表软件代码检杳单（C语言）77 检鱼寮量和宏，数字帘金应该用宏未表不，检登宏足义中的数位、実型是合正佚月说明・1.本檢杳单为软件评頁朋检査较件产品惜俣和扶陷提供了指导。
代码审查(CODE REVIEW)
代码审查(CodeReview)一、概述代码审查（CodeReview)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等，目前监控团队虽然提倡代码审查，也有相关的辅助工具，但是一直没有真正的推行起来，这半年的时间里，一些线上的bug如果经过代码审查，基本上可以避免的，大家也逐渐认识到代码审查可以有效地提高代码质量。
二、代码审查的作用1、提高代码质量。
通过代码审查来发现bug及代码中的不规范，这是不容置疑的，通过代码审查，代码将更加整洁，有更好的注释，更好的程序结构。
2、提高开发者开发水平。
开发者知道自己编写的代码会被同事审查，将会更加认真的编写代码，也将会督促开者不断地学习、向有经验的同事请教。
3、提高程序的可维护性。
一份程序代码将会有更多的同事熟悉，更好的代码质量，自然地也增加程序的可维护性。
4、提高开发者的对编码的责任感。
如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。
你写出的代码将更加整洁，有更好的注释，更好的程序结构——因为你知道，那个你很在意的人将会查看你的程序。
没有代码审查，你知道人们最终还是会看你的程序。
但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。
5、传播知识在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。
除非是同事的模块影响了自己的程序，他们从不相互交流。
这种情况的后果是，每个模块只有一个人熟悉里面的代码。
如果这个人休假或——但愿不是——辞职了，其他人则束手无策。
通过代码审查，至少会有两个人熟悉这些程序——作者，以及审查者。
审查者并不能像程序的作者一样对程序十分了解——但他会熟悉程序的设计和架构，这是极其重要的。
三、代码审查的执行障碍1、缺少代码审查的标准缺少代码审查的标准，往往审查人员习惯性地根据自身开发经验去进行代码审查，容易变成去挑毛病，找bug，容易产生不良地影响。
code review反馈的问题单格式
在软件开发过程中，Code Review（代码审查）是一个至关重要的环节。
它能帮助团队发现潜在的问题、提高代码质量和促进知识共享。
而在进行Code Review时，一个很重要的元素就是反馈。
正确的反馈可以帮助开发者改进代码，同时也能够促进团队合作和成长。
在进行Code Review时，制定一个高质量的问题单格式是非常重要的。
1.问题单格式的重要性在进行Code Review时，发现问题并提出反馈是必不可少的。
而问题单格式就是开发者提出问题和反馈的标准形式。
一个良好的问题单格式不仅能够让开发者更清晰地了解问题所在，还能够便于跟踪和解决问题。
制定一个高质量的问题单格式对于提升Code Review的效率和质量具有非常重要的意义。
2.问题单格式的要求在制定问题单格式时，需要考虑以下几个方面的要求：（1）清晰明了：问题单中应清晰明了地描述问题所在，尽量避免模糊或含糊不清的表达，以便开发者能够准确理解问题，并且能够迅速采取行动。
（2）具体详细：问题单中应提供详细的信息，包括问题的具体位置、原因分析、修改建议等内容。
这样能够帮助开发者更快速地定位并解决问题。
（3）标准统一：制定问题单格式时应该尽量遵循一定的标准和规范，以保持文档的统一性和易读性。
这样能够使团队成员更容易理解和处理问题。
（4）量化评估：问题单中最好能够进行量化评估，即对问题的严重程度、影响范围、解决难度等进行量化评价，以便开发者更好地了解问题的紧迫性和重要性。
3.个人观点和理解在我看来，一个高质量的问题单格式应该更侧重于问题本身的清晰度和具体性。
只有问题描述得足够清晰和具体，才能够让开发者迅速理解并采取改进措施。
问题单格式应该尽量避免主观性和模糊性，而是以客观的事实和数据为依据。
总结回顾：一个高质量的问题单格式在Code Review中具有非常重要的意义。
它能够帮助团队更好地发现和解决问题，提高代码质量和开发效率。
一个良好的问题单格式应该具备清晰明了、具体详细、标准统一和量化评估等特点。
JAVA代码审查
代码编写者，代码审核者共同对代码的质量承担责任。这样才能保证 Code Review 不是走过场，其中代码编写者承担主要责任，代码审核者承担次要责任。
二、java 代码审查检查表
重要性
激 级别 检查项
活
总计
命名
重要
20命名规则是否与所采用的规范保持一致？
20是否遵循了最小长度最多信息原则？
5、代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不 清楚的地方可积极向代码审核者提出。
6、代码编写者 bug fix 完毕之后给出反馈。 7、代码审核者把 Code Review 中发现的有价值的问题更新到"代码审核检查 表"的文档中，对于特别值得提醒的问题可群发 email 给所开发人员。
1.1 主要工作
1、发现代码中的 bug; 2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。 3、是否符合 java 开发规范和代码审核检查表
1.2 基本流程
1、代码编写者和代码审核者坐在一起，由代码编写者按照 UC（Use Case） 依次讲解自己负责的代码和相关逻辑，从表现层->持久层;
d.height = height; d.width = width; }
public synchronized Dimension getValues(){ // Ooops! Breaks encapsulation return d; } }
Example 类保证了它所存储的 height 和 width 值永远非负数，试图使用 setValues()方法来 设置负值会触发异常。不幸的是，由于 getValues()返回 d 的引用，而不是 d 的拷贝，你可 以编写如下的破坏性代码：
代码审查清单
通用代码审查清单在代码审查时，我们可以运用代码审查清单，将以往所有可能发生的常见错误罗列出来，供与会者对照检查，从而提高会审效率。
（1）数据引用错误数据引用错误是指使用未经正确地初始化的变量、常量、数组、字符串或记录。
＊是否引用了未初始化的变量？＊数组和字符串的下标是整数值吗？下标总是在数组和字符串大小范围之内吗？＊在检索操作或者应用数组下标时是否包含"丢掉一个"这样的潜在错误？＊是否在应该使用常量的地方使用了变量？＊变量是否被赋予不同类型的值？＊为引用的指针分配内存了吗？＊一个数据结构是否在多个函数或者子程序中引用，在每一个引用中明确定义结构了吗？（2）数据声明错误数据声明错误是指不正确地声明或使用变量和常量。
＊所有变量都赋予正确的长度、类型和存储类了吗？＊变量是否在声明的同时进行了初始化？是否正确初始化并与其类型一致？＊变量有相似的名称吗？＊存在声明过、但从未引用或者只引用过一次的变量吗？＊在特定模块中所有变量都显式地声明了吗？（3）计算错误计算错误是指基本的数学逻辑问题。
＊计算中是否使用了不同数据类型的变量，如整数与浮点数相加？＊计算中是否使用了数据类型相同但字节长度不同的变量？＊计算时是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？＊赋值的目的变量是否小于赋值表达式的值？＊在数值计算过程中是否可能出现溢出？＊除数或模是否可能为零？＊对于整型算术运算或某些计算，特别是除法的代码处理是否会丢失精度？＊变量的值是否超过有意义的范围？＊对于包含多个操作的表达式，求值次序是否混乱，运算优先级对吗？需要加括号使其清晰吗？（4）比较错误小于、大于、等于、不等于、真、假、比较和判断错误很可能是边界条件问题。
＊比较得正确吗？＊存在分数或者浮点数之间的比较吗？如果有，精度问题会影响比较吗？1.00000001和 1.00000002极其接近，它们相等吗？＊每一个逻辑表达式都正确地表达了吗？逻辑计算如期进行了吗？求值次序有疑问吗？＊逻辑表达式的操作数是逻辑值吗？（5）控制流程错误控制流程错误是指编程语言中循环等控制结构未按预期方式工作，通常由计算或者比较错误直接或间接造成。
【规范】代码审查规范
【关键字】规范代码审查规范1. Code Review目的Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。
Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的：•在项目早期就能够发现代码中的BUG。
•帮助初级开发人员学习高级开发人员的经验，达到知识共享。
•躲免开发人员犯一些很常见，很普通的错误。
•保证项目组人员的良好沟通。
•项目或产品的代码更容易维护。
2. Code Review的前提条件代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点。
•所有代码注释清晰，语法正确，编译通过。
•日志代码完整，业务日志、系统日志分开，中文描述，脱敏处理，状态变更，全部清晰明确。
•测试代码覆盖全部分支和流程，暂时统一使用工具Emma（各编译器可下载对应插件）进行Coverage Check。
•项目引用关系明确，依赖关系清晰，配置文件描述。
3. Code Review的审查范围代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求（性能、功能）与设计文档相同等等。
3.1、完整性检查（Completeness）•代码是否完全实现了设计文档中所涉及的所有流程和功能点•代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完整，日志文件配置是否正确。
•代码是否使用缓存等，配置信息是否正确可配置。
•代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等3.2、一致性检查（Consistency）•代码的逻辑是否符合设计文档•代码中使用的格式、符号、结构等风格是否保持一致3.3、正确性检查（Correctness）•代码是否符合制定的标准•所有的变量都被正确定义和使用•所有的注释都是准确的•所有的程序调用都使用了正确的参数个数3.4、可修改性检查（Modifiability）•代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等) •代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的•代码是否只有一个出口和一个入口（严重的异常处理除外）3.5、可预测性检查（Predictability）•代码所用的开发语言是否具有定义良好的语法和语义•是否代码躲免了依赖于开发语言缺省提供的功能•代码是否无意中陷入了死循环•代码是否躲免了无穷递归3.6、健壮性检查（Robustness）•代码是否采取措施躲免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等）3.7、结构性检查（Structuredness）•程序的每个功能是否都作为一个可辩识的代码块存在•循环是否只有一个入口3.8、可追溯性检查（Traceability）•代码是否对每个程序进行了唯一标识•是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应•代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录•是否所有的安全功能都有标识3.9、可理解性检查（Understandability）•注释是否足够清晰的描述每个子程序•是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释•使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度•是否在定义命名规则时采用了便于记忆，反映类型等方法•每个变量都定义了合法的取值范围•代码中的算法是否符合开发文档中描述的数学模型3.10、可验证性检查(Verifiability)•代码中的实现技术是否便于测试•测试代码是否正确，是否覆盖所有流程4. Code Review的步骤目前Code Review 步骤暂定如下，试行一段时间再根据问题做调整。
代码审查单
□
要步骤？
是否违背了继承和组合的规则？
（1）若在逻辑上B是A的“一种”，并且A的所有功能和属性对B而言都
有意义，则允许B继承A的功能和属性。
□
（2）若在逻辑上A是B的“一部分” (a part of)，则不允许B从A派生，
而是要用A和其它东西组合出B。
每一个域在每一次使用前正确地初始化了吗？ 是否忘记为数组和动态内存赋初值？（防止将未被初始化的内存作为右值使 用）
对屏幕输出操作，是否到达了最快的刷新速度？效率是否为最佳？需部分 刷新区域的地方是否进行了全部刷新？
□
有无可优化的程序块、函数或子程序等？
□
算法是否可以优化？
□
注释比例达到25%以上吗？
□
标号和子程序名符合代码的意义吗？
□
是否使用了ＧＯＴＯ语句？
□
是否使用了非通用的函数库？对于非标准的库是否提供了源程序？
□
测试和转移检 查
每个转移目标正确并至少执行一次吗？
□
三种情况（大于0，小于0，等于0）是否已全部测试？边界值是否进行了 测试？
□
循环语句是否有正常跳出循环的条件吗？是否会出现死循环？ｂｒｅａｋ和ｃｏｎｔｉ ｎｕｅ语句使用正确吗？
□
逻辑是否被最佳地编码？
□
提供的是一般的错误处理还是异常的例程？
□
性能检查
头文件是否使用了ifndef/define/endif预处理块?
程序结构和模块功能定义清楚吗?
编程风格检查 是否遵循该语言的指令编写格式?
注释的行数不少于代码总行数的1/5吗?
注释说明和代码功能一致吗?
错误处理分支信息表达清楚吗?
每一个模块单元的圈复杂度都小于10吗?
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
英文原文：oschina
代码审查可以帮助提高代码质量，避免由于代码习惯而造成的 bug。
下面列出的这些要点因该可以作为大部分代码审查的指导，如果是 Java 应用的话，这些建议应该被视作最佳实践。
文档
1. Javadoc 应该在每一个类和方法中添加。
2. 如果是修复某个 bug，应该添加 bug ID。
3. 走捷径的方法或者复杂的逻辑要有解释。
4. 如果代码会被公开，每个文件头都要标注版权信息。
5. 复杂的 HTML，JavaScript，CSS 应该包含文档。
功能
1. 如果类似的逻辑被使用了多次，应该把它写成一个帮助类，然后在多出调用。
2. 鼓励使用 API 而不是重复编写代码解决相同的问题。
3. 要强调代码的单元测试。
4. 任何新加的代码不应该破坏已有的代码。
5. 假如是 Web 应用，JSP 不应该包含 Java 代码。
安全
1. 任何代码都不能执行用户的输入，除非转义过了。
这个常常包含 JavaScript 的 eval 函数和 SQL 语句。
2. 禁止那些在短时间内提交非常多请求的 IP。
3. 任何类，变量，还有方法都应该有正确的访问域。
4. 尽量避免使用 iframe。
性能
1. 所有数据库和文件操句柄在不需要的时候都应该被关闭。
2. SQL 语句的写法会导致性能千差万别。
3. 鼓励创建不可变（immutable）的类。
4. 类似的逻辑代码，尽量通过 if else 语句来实现更多的重用。
5. 尽量避免使用重对象（heavy objects）。
6. 如果是 Web 项目，请检查是否使用了合适的图片尺寸，CSS sprites 和浏览器缓存等技术。
7. 全局都需要的信息保存在 application context 中。
编码习惯
1. 没有被使用的变量要删除。
2. 针对不同的 Exception 要用不同的 catch 语句，而不是一个 Exception 解决所有问题。
3. 针对变量，方法和类要用相同的命名方法。
4. 常量应该被写在独立的常量类中。
5. 每行代码的尾部不要有多余的空格。
6. 对于括号，循环，if语句等等要用统一的格式。
7. 每一个单独的方法不应该超过100行。
8. 一个单独的语句不应该超过编辑器的可视区域，它可以被拆分成几行。
9. 检查 String 对象既不是null也不是空的最好方法是 if(“”.equals(str))
10. 假如类有很多成员变量，并且实例化的时候只需要少数变量传入的话，最好使用静态工厂方法，而不是重载构造函数。
11. 给方法添加适当的访问控制，而不是所有都是 public。
12. 遵守项目中使用的框架的最佳实践建议，例如 Spring，Struts，Hibernate，jQuery。
以上的某些注意点可以通过静态代码检查工具完成，例如 CheckStyle，FindBugs 和 JTest。
赞 2 收藏。