代码审查(Code Review)清单

标签: 程序员 Code Review 代码审查 | 发表时间:2012-08-09 10:37 | 作者:齐哲
出处:http://blog.jobbole.com

代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug。下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践。

文档

1. Javadoc 应该在每一个类和方法中添加。

2. 如果是修复某个 bug,应该添加 bug ID。

3. 走捷径的方法或者复杂的逻辑要有解释。

4. 如果代码会被公开,每个文件头都要标注版权信息。

5. 复杂的 HTML,JavaScript,CSS 应该包含文档。

功能

1. 如果类似的逻辑被使用了多次,应该把它写成一个帮助类,然后在多出调用。

2. 鼓励使用 API 而不是重复编写代码解决相同的问题。

3. 要强调代码的单元测试。

4. 任何新加的代码不应该破坏已有的代码。

5. 假如是 Web 应用,JSP 不应该包含 Java 代码。

code review

安全

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。

 

原文链接

相关文章

相关 [代码审查 code review] 推荐:

代码审查(Code Review)清单

- - 博客 - 伯乐在线
代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug. 下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践. Javadoc 应该在每一个类和方法中添加. 如果是修复某个 bug,应该添加 bug ID. 走捷径的方法或者复杂的逻辑要有解释.

聊聊Code Review

- - 梦想风暴
hopesfish评论《 那一点的调用》时,问了一个关于Code Review的问题:. 想请教一下,TW的筒子是如何做code reivew或者鼓励客户做code review的. 我在翻阅博主的帖子的时候,似乎对这块没有特别强调,而是更多偏重于TDD,我觉得TDD的问题是一碰到没有责任心的程序猿,就很容易流于形式了.

Java Code Review清单

- - ImportNew
使用可以表达实际意图(Intention-Revealing)的名称. DRY(Don’t Repeat Yourself)原则,(拒绝重复). 用代码来解释自己的做法(译者注:即代码注释). *参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238.

我的code review规则

- vento - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
1) 是否有语法错误,编译错误,编译警告. 做法:下载最新代码,将编译警告级别提升到最高,检查output信息. 2)是否符合需求,完成requirement文档要求的内容,不能多,也不能少. 注意:即使发现有问题代码,如果与需求关联不大,不要涉及. 应该让每次enhancement和bug fix最简洁,牵涉范围最小,影响到组件最少.

Code Review那些事儿

- - 非技术 - ITeye博客
       曾经有一段 垃圾代码放在我的面前,我没有拒绝,等我真正开始接手的时候我才后悔莫及,程序员最痛苦的事莫过于此. ---------改编于周星星的经典台词.       虽然有点夸张,但编码界确实大大存在这种情况,每当接手别人的代码,都有一种想重新写一遍的感觉,等到别人再来接手你的代码时,同样的感觉.

从Code Review 谈如何做技术

- - 酷 壳 - CoolShell.cn
(这篇文章缘由我的微博,我想多说一些,有些杂乱,想到哪写到哪). 这两天,在微博上表达了一下Code Review的重要性. 因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录.

我们该如何做好Code Review?

- - SegmentFault 最新的文章
我们该如何做好Code Review?. 午后的阳光,静静地照在你的脸上. 这时候配上一杯82年的java,脑子一片灵光闪过,呃......上午刚写完需求,下午好像没什么事了,不如看看自己写的代码. 至此,一场Code Review也就拉开序幕了. Code Review,即代码审查,是指对计算机源代码系统化地审查,常用软件同行评审的方式进行,其目的是在找出及修正在软件开发初期未发现的错误,提升软件质量及开发者的技术.

如何在团队中做好 Code Review

- - IT瘾-dev
一、Code Review的好处. 想要做好Code Review,必须让参与的工程师充分认识到Code Review的好处. 无论是高手云集的架构师团队,还是以CURD为主的业务开发团队,大家的技术能力、经验都是有差异的. 通过Code Review,对于同样的功能实现,有经验的工程师可以给经验尚浅的工程师提供合理的优化建议.

测试技术中CODE REVIEW的重要性

- - CSDN博客推荐文章
        [近期关注App自动化测试,欢迎交流,本博客文章版权归作者所有,转载请联系]     .         最近有网上的朋友向我咨询作为测试员是否应该跳槽,   首先我觉得应该向大家介绍一下什么是测试工程师,  什么是测试员,   在国内的一些中型企业并没有特别的指明.   这里测试工程师主要指测试开发工程师, 主要包括两类,  其一是测试软件开发的工程师,  其二是自动化测试脚本开发和维护的工程师,   而测试员主要指单纯编写/管理测试用例,  或是手工测试人员, 一些国内的大中型网络视频公司仍然在用纯手工测试,我感觉到很汗颜.