代码审查(Code Review)清单

标签: 程序员 Code Review 代码审查 | 发表时间:2012-08-09 02: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] 推荐:

代码审查(Code Review)清单

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

什么是整洁的代码(Clean Code)?

- - 博客 - 伯乐在线
英文原文: What Is Clean Code?,编译: iteye – wangguo. 什么样的代码才是真正好的、整洁的代码. Bjarne Stroustrup,C++之父:. ● 逻辑应该是清晰的,bug难以隐藏;. ●错误处理完全根据一个明确的策略;. ●性能接近最佳化,避免代码混乱和无原则的优化;.

Facebook 如何发布代码 (How Facebook Ships Code 译文)

- Tim - DBA Notes
按:这篇 How Facebook Ships Code 提供了大量的细节信息,之前已经有朋友提供了一个翻译版本,阅读之后发现有些许错误,并且原文有更新,所以基于前面的翻译版本我重新翻译了一个(完整的)版本. 我对 Facebook 的运作方式着迷. 这是个非常独特的环境,很难被复制(这个方式并不适合所有的公司,即使有些公司尝试过这么做).

代码审查过程

- - 博客园_知识库
   英文链接: Code Review Processes.   对我而言,把代码产品化而没有合适的审查流程,就像是一场抽抽乐游戏. 代码当然也有可能会挺好,不过总还是有一定概率某人的哪块积木没抽好,然后一切就轰然崩塌. 无论是采用持续集成服务、结对审查、QA审查,还是所有这些方案的组合,都可以大大降低引入风险的概率.

Clean-Code: 注释

- We_Get - 博客园-首页原创精华区
别给糟糕的代码加注释-----------------重新写吧. 这是书中的关于注释一章的第一句话,怎么说呢,这句话个人感觉很对,但是实际上却很少这么做,. 糟糕的代码不是自己写的,别人写的代码,还是让别人自己去维护吧,出了问题也是别人的. 糟糕的代码目前可以正常工作,软件开发中有一条古老哲言:如果它能工作就不要动它,很多程序员都遵守这条准则.

聊聊Code Review

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

Google 是如何做代码审查的

- litefy - python.cn(jobs, news)
在上一篇文章中提到过,我已经不在Google工作了. 我还没有想清楚应该去哪里—有两三个非常好的工作机会摆在我面前. 因为在这段做决定时间里,我不再受雇于任何人,我想可以写一些专业性的东西,一些很有趣,但也会在同事和管理工作中导致关系紧张的东西. Google是一个非常优秀的公司. 他们做出了很多令人称赞的东西—既是公司外部,人们可以看到的东西,也是公司内部.

代码审查中应该做的事

- China Moon - Solidot
威客 写道 "Mark Chu-Carroll从Google离职后,虽然已经收到了很多offer,但还没有决定去哪里. 他在其博客中分享了一些关于代码审查的趣事(中文). Google确实是一家很酷的公司. 不论是在公司内部或是外部,Google都做了很多让人赞叹的的事情. 这里我想介绍一些不涉及商业机密,但鲜为外人所知的事情.

我所钟爱的代码审查

- - 译言-电脑/网络/数码科技
  当我从学术界转向产业界的过程中,对我生涯改变最大的事情就是对代码审核的探索. 这是一件在产业开发者的世界中一件非常正常的事情,但是我此前才学术界从来没有听说过哪个学术组织在使用代码审核,在我加入Google之前我自己也从来没有做过.   简而言之,代码审查是一件了不起的事情,每个从业者都应该使用它们,我的狗Heck也应该使用它,你们也会使用到;.

敏捷代码审查指南

- - 博客 - 伯乐在线
“通过一次真正彻底地代码审查(code reviews),仔细阅读你的代码,找出问题,这是我知道的最好的方式去检测早期的bug,但是他们很少去这样干过. 某种意义上是因为他们花了大量的时间去写好代码,但是我认为主要是因为绝大部分 程序员害怕其他人审查自己的代码. 作为专业的程序员我们要克服阻力,如果你不愿意别人阅读你的代码,然后只是按照自己的意愿写,如果其他人没法读懂它,又怎能让别人使用呢.