C++ 代码评审最终指南——第 1 部分

C++ 语言功能强大——但也极其复杂，复杂性使其极易引发误解和过度复杂化。相比简单语言，C++ 中的程序错误难以发现——相比其他语言，生产环境中的 C++ 程序错误更难定位。

简而言之，需要谨慎处理 C++——甚至是用鹰眼那样锐利的目光进行评审。

本篇分为两部分。第一部分，我们将讨论更多代码评审的普遍情况。第二部分，我们将深入探讨具体的 C++ 代码评审话题，并为 C++ 代码评审创建检查表。
*

C++ 代码评审的重要性

无论使用何种语言进行编码，总是难以发现代码中的程序错误和普通错误，而我们可能从头到尾都没意识到自己的错误。他人评审不失为一种解决问题的好方法。

此外，两个人或更多人之间的代码讨论便足以提出新问题，更有助于明确重要问题。

上述内容适用于任何所使用的编程语言，但 C++ 的复杂性使其尤为重要。必须额外增加至少一个人来评审代码。

代码评审前的注意事项

提交代码以供评审之前，需要注意两件事。

其一是通过静态代码分析，并能解释任一所发现的警告，这些警告可能是误报，或是出于某种原因不应处理。静态代码分析工具种类繁多——包括开源工具与商业工具——有什么理由不使用呢？当然，假定不存在任何编译器警告，但在极少数情况下，如果确实有理由忽略编译器警告，也应提前备好解释（比如，编译指示声明上的注释，用以指示编译器忽略该警告）。

其二是测试代码。运行单元测试时，最好透彻检查全部代码，包括错误和边缘案例。测试能保证代码运行，缺少测试，代码评审则毫无意义。此外，代码评审中待评审项目包含测试。如果需要在代码评审后增加测试，确保测试失败后对代码进行的变更不会避开代码评审。

静态代码分析和执行良好的单元测试均可降低问题影响代码评审的机率，并能事先修复问题，但也不能保证它们就是万无一失的。

例如，如果从一开始就弄错需求，再好的测试或者静态分析都无法发现其中的问题。另一方面，代码评审考虑了需求，有助于在代码和测试场景中直观了解。这样就能发现需求与实际代码间的不一致。

SmartBear 最近一项调查显示，24% 的受访者表示代码评审是公司提高代码质量的首要途径。单元测试位列第二，静态代码分析稍显落后。这并不是说单元测试和静态代码分析不重要，可能是受访者认为代码评审有时会受到忽视，或者没有很好地执行。但显而易见的，单元测试和