一、实验目的
1） 了解代码审查的含义；
2） 掌握相关编程规范检查工具的安装与使用；
二、实验内容及要求
Code Review中文应该译作"代码审查"或是"代码评审"或"代码复查"，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。Code Review主要用来在软件工程过程中改进代码质量，通过代码评审可以达到如下目的：
●在项目早期就能够发现代码中的BUG
●帮助初级开发人员学习高级开发人员的经验，达到知识共享
●避免开发人员犯一些很常见，很普通的错误
●保证项目组人员的良好沟通
●项目或产品的代码更容易维护
代码评审主要内容是编程规范，重构方法，架构设计，性能安全，日志，可读性，扩展性等问题。通过代码评审可查找和修复引入到开发阶段的应用程序的错误，提高软件的整体素质和开发者的技能。代码评审的作用和意义已在很多技术团队内达成共识，可是很多时候并未被有效执行，甚至被认为是一项费时费力的工作。借助一些工具可以更容易，更有效率地来进行Code Review。
1、以小组形式，针对前面"实验一"中所完成的代码，进行代码评审(走查)，重点检查以下情况。你也可有查询相关材料，建立更细化的检查清单（check list）
- 程序是否能正常工作，代码是否实现预期的功能，逻辑是否正确。
- 代码是否遵循的编程规范
- 代码是否尽可能的模块化
- 所有的数据输入是否都进行了检查
- 是否有注释，并且描述了代码的意图
- 代码的可理解性和可测试性
2、按"实验二"的分组方式，两人一组，随机分配另一组的代码作为本组评审和分析的对象
一些编码规范的检查工具如下，也可自行查找工具使用。
三、实验过程
（1）配置代码审查工具。要求采用屏幕截图的方式配置的过程；
C++语言
- 可使用Google代码规范工具Cpplint。
- Cpplint是一个python脚本，Google使用它作为自己的C++代码规范检查工具，VSCcode可配置Cpplint对C++代码进行规范检查。
本次代码审查的是第26组使用C++语言编写的生命游戏代码，故选择Cpplint代码规范工具进行审查，相关配置如下：
首先下载Python2.7，并配置path系统环境变量。再下载Cpplint代码规范工具，并通过添加外部工具的方式集成到VS2015，注意命令和参数，方便后续的代码审查。
Cpplint参考链接https://github.com/huangjj27/Personal_code_set/blob/master/cpplint.py
图1-Python27环境变量配置
图2-VS2015添加外部工具Cpplint
（2）使用工具对原始代码进行评审和分析，记录结果，期间不要有任何修改；
在VS2015中使用外部工具Cpplint进行代码规范审查，结果如下图所示，共有errors 208。
图3
图4
（3）对工具执行结果进行人工分析，结合检查清单和人工走查的出代码修改建议；
对代码审查时发现的问题进行分类归纳，总共分为以下几种问题。对每种问题进行分析，得出如下修改建议。
1. Streams are highly discouraged. [readability/streams] [3]
不鼓励使用流。 不要使用流, 除非是日志接口需要. 使用 printf 之类的代替。
2. Do not use namespace using-directives. Use using-declarations instead. [build/namespaces] [5]
不能用std全部空间，建议使用具体用到的函数。
3. Should have a space between // and comment [whitespace/comments] [4]
应该在//和注释之间有一个空格。
4. { should almost always be at the end of the previous line [whitespace/braces] [4]
{几乎总是在前一行的末尾。
5. Line ends in whitespace. Consider deleting these extra spaces. [whitespace/end_of_line] [4]
代码行最后存在空格。
6. private: should be indented +1 space inside class CWorld [whitespace/indent] [3]
private:应该在类CWorld中缩进+1个空格。
7. At least two spaces is best between code and comments [whitespace/comments] [2]
代码和注释之间最好至少有两个空格。
8. Extra space before last semicolon. If this should be an empty statement, use {} instead. [whitespace/semicolon] [5]
最后一个分号前有多余的空格。如果这应该是一个空语句，请改用{}。
9. Lines should be <= 80 characters long [whitespace/line_length] [2]
行长度应<=80个字符。
10. public: should be indented +1 space inside class CWorld [whitespace/indent] [3]
public:应在类CWorld中缩进+1空格。
11. Using C-style cast. Use reinterpret_cast<SCell *>(...) instead [readability/casting] [4]
使用C样式转换。使用reinterpret_cast<SCell*>（…）代替。
12. Redundant blank line at the end of a code block should be deleted. [whitespace/blank_line] [3]
应删除代码块末尾的多余空行。
13. Consider using rand_r(...) instead of rand(...) for improved thread safety. [runtime/threadsafe_fn] [2]
考虑使用rand_r（…）而不是rand（…）来提高线程安全性。
14. An else should appear on the same line as the preceding } [whitespace/newline] [4]
else应该与前面的}出现在同一行上。
15. Tab found; better to use spaces [whitespace/tab] [1]
找到制表符；最好使用空格。
16. Lines should very rarely be longer than 100 characters [whitespace/line_length] [4]
行应该很少超过100个字符。
17. Missing space after , [whitespace/comma] [3]
逗号后缺少空格。
（4）通过github issues向项目维护者提交问题(issue),注意一个issue 只报告一个问题，多个问题需放在多个issue中，以便跟踪。
将代码审查发现的问题提交给项目维护者，小组提交的结果如下所示
图5
图6
（5）记录总结实验过程中遇到的问题和解决过程
在本次实验过程中，对于代码审查中发现的问题进行归纳分析。对于一些问题不知道发生的原因，通过查找相关资料，进行小组讨论，寻找问题的解决办法。
实验小结
通过本次实验我认识到了代码规范的重要性，掌握了Cpplint代码审查工具的使用，在审查C++代码时发现了一些从未注意到的问题。通过对问题的分析讨论，我对审查时发现的问题有了更深刻的认识，我将会在以后的编码工程中注意代码规范问题。