摘自http://www.techug.com/increase-defect-detection-with-our-code-review-checklist-example
总体
- 代码能运行吗？代码实现了想要实现的功能了吗，逻辑是正确的吗，等等。
- 所有代码都很容易理解吗？
- 它遵循了你们都同意的代码规范吗？规范通常包括花括号的位置、变量和函数的命名、行长度、缩进、格式和注释。
- 有多余的或重复的代码？
- 代码尽可能模块化了？
- 全局变量能被替换？
- 有任何被注释掉的代码？
- 循环结构里有固定的长度值和正确的结束条件？
- 有代码可以被类库函数取代？
- 日志和调试代码可以被移除？
安全
- 所有数据输入都被校验（为了正确的类型、长度、格式和范围）和转码了？
- 第三方工具集在哪里用到了，能够返回被捕捉到的错误吗？
- 输出值经过校验和转码了？
- 不合法的参数值得到处理了？
文档
- 有文档吗，文档描述了代码意图吗？
- 所有的函数都加注释了？
- 任何不寻常的行为和边界处理都做说明了？
- 就第三方类库的使用和功能写文档了？
- 所有的数据结构和测试单元都做解释了？
- 有不完整的代码？如果有，它应该被移除还是打上’TODO‘之类的适当标记？
测试
- 代码可测试吗？比如，不要增加太多的或隐藏的依赖，不能够实例化对象，测试框架能够使用方法等。
- 有测试吗，它们全面吗？比如，至少包含了你们认可的代码覆盖率吗？
- 单元测试实际地测试了代码正在实现的目标功能了？
- 数组检查’越界‘错误了？
- 测试代码可被已有 API 的应用取代吗？
你还可以为清单增加一些语言相关的问题。
该清单故意没有包含所有的问题，你并不想一个长长的清单，以致于没人去使用。只需覆盖常见问题即可。
优化你的清单
把该清单做为一个起点，你应该针对具体用例进行优化。有个不错的办法，那就是让你的团队在代码审核时，花一点时间提出所产生的问题。有了这些数据，你就能够甄别出团队的常见错误，然后就被改造成常见清单。要确保删除那些不会发生的条目（你或许希望保持较少地发生，还有诸如安全相关的重要条目）。