Static Check with CPPLINT during Code Review

以下分享一些实践的经验关于如何在code review里加入C++代码的静态检查。

一. 什么是代码静态检查

静态检查是指在不执行代码的情况下对其进行分析评估的过程，是软件质量和软件安全保障的重要一环。它通过词法分析、语义分析、控制流分析、数据流分析等技术对代码逐行解析暴露问题，从而协助我们将许多在运行时才会暴露的棘手麻烦扼杀于摇篮之中。

二. C++代码静态检查工具

Cpplint是一个依据Google's C++ style guide规范的对C/C++文件进行静态检查的命令行工具。在这里我们使用Cpplint工具对看图的C++代码进行静态检查。

三. 配置步骤

1. 配置Cpplint运行环境

假设你的环境里已经安装过python了，支持python2和3。

pip install cpplint

安装完成后，可以直接用命令行进行检查了

cpplint [Options] files

也可以用以下命令获得更多cpplint的帮助

cpplint --help

2. 安装Jenkins Violation Comments to Gitlab插件

在进行第二步之前，假设环境里已经有了Gitlab plugin, 并且做好了相应的配置。若没有，请参考我的另一篇文章GitLab Code Review进行配置

3. Jenkins静态检查工程配置

创建一个新freestyle的工程，在工程配置里，首页要把GitLab trigger打开，这样才会当一个GitLab Merge Request创建了之后，自动触发这个代码静态检查的工程，进行后续的代码审查确认

，

执行cpplint步骤：在jenkins build step里增加"Execute shell"。以下是亲测比较有用的一些参数，检查的是src目录下（包括子目录）所有后缀名是.cpp和.h的文件。并且将结果输出到cpplint.xml中待后续步骤使用。

另外增加|| exit 0，是因为cpplint执行返回的结果是非0，会导致Jenkins job结果失败

cpplint.exe --extensions=cpp,h --recursive --filter=-whitespace/tab --linelength=120 src 2> cpplint.xml || exit 0

cpplint.xml报告的格式如下：

src\utility\http\HttpRequest.h:0: No copyright message found. You should have a line: "Copyright [year] " [legal/copyright] [5]src\utility\http\HttpRequest.h:14: Found C system header after other header. Should be: HttpRequest.h, c system, c++ system, other. [build/include_order] [4]src\utility\http\HttpRequest.h:15: Found C++ system header after other header. Should be: HttpRequest.h, c system, c++ system, other. [build/include_order] [4]src\utility\http\HttpRequest.h:16: Found C++ system header after other header. Should be: HttpRequest.h, c system, c++ system, other. [build/include_order] [4]src\utility\http\HttpRequest.h:17: Found C system header after other header. Should be: HttpRequest.h, c system, c++ system, other. [build/include_order] [4]src\utility\http\HttpRequest.h:18: Found C system header after other header. Should be: HttpRequest.h, c system, c++ system, other. [build/include_order] [4]src\utility\http\HttpRequest.h:27: { should almost always be at the end of the previous line [whitespace/braces] [4]src\utility\http\HttpRequest.h:28: public: should be indented +1 space inside class HttpRequestUserData [whitespace/indent] [3]src\utility\http\HttpRequest.h:36: { should almost always be at the end of the previous line [whitespace/braces] [4]src\utility\http\HttpRequest.h:37: public: should be indented +1 space inside class HttpRequestTask [whitespace/indent] [3]src\utility\http\HttpRequest.h:38: Missing space before { [whitespace/braces] [5]src\utility\http\HttpRequest.h:39: Missing space before { [whitespace/braces] [5]src\utility\http\HttpRequest.h:45: { should almost always be at the end of the previous line [whitespace/braces] [4]src\utility\http\HttpRequest.h:56: { should almost always be at the end of the previous line [whitespace/braces] [4]src\utility\http\HttpRequest.h:57: Redundant blank line at the start of a code block should be deleted. [whitespace/blank_line] [2]src\utility\http\HttpRequest.h:57: Redundant blank line at the end of a code block should be deleted. [whitespace/blank_line] [3]src\utility\http\HttpRequest.h:60: { should almost always be at the end of the previous line [whitespace/braces] [4]src\utility\http\HttpRequest.h:61: Redundant blank line at the start of a code block should be deleted. [whitespace/blank_line] [2]src\utility\http\HttpRequest.h:61: Redundant blank line at the end of a code block should be deleted. [whitespace/blank_line] [3]src\utility\http\HttpRequest.h:80: At least two spaces is best between code and comments [whitespace/comments] [2]src\utility\http\HttpRequest.h:80: Use int16/int64/etc, rather than the C type long [runtime/int] [4]src\utility\http\HttpRequest.h:89: { should almost always be at the end of the previous line [whitespace/braces] [4]src\utility\http\HttpRequest.h:96: { should almost always be at the end of the previous line [whitespace/braces] [4]src\utility\http\HttpRequest.h:97: Redundant blank line at the start of a code block should be deleted. [whitespace/blank_line] [2]src\utility\http\HttpRequest.h:97: Redundant blank line at the end of a code block should be deleted. [whitespace/blank_line] [3]src\utility\http\HttpRequest.h:100: { should almost always be at the end of the previous line [whitespace/braces] [4]

接下来在构建后步骤里添加"Report Violation to GitLab"，按照截图进行配置。

配置完成后，可以创建一个GitLab Merge Request来测试下。

截取部分Jenkins build log比较有价值的信息：

从上面的Jenkins build log里可以看出，cpplint是对src目录下做了全量检查，总共发现了15144个缺陷。GitLab Violation Comments to GitLab插件比对Merge Request改动的文件和改动的部分，只报告跟Merge Request里改动相关的缺陷。所以最终发现了一个ERROR级别的缺陷。

打开GitLab 对应的Merge Request，就可以看到在Disucction里多一条跟violation相关的缺陷报告，并且GitLab也会给提交者发邮件提醒，开发人员可根据缺陷内容（文件/行数/缺陷内容）做相应的处理。

这样可以提高代码的质量，将一些缺陷在Merge之前修改掉。

3. 只检查Merge Request里改动的文件

按照上面的步骤是对所有仓库里的后缀名是.cpp/.h的文件进行检查，进行的是全量检查。如果我们想把代码静态检查放在code review的流程里，那么我们就会想只需要对修改过的文件进行扫描就可以了。这样可以更加有效率，更有针对性。

我是通过小段shell脚本做了处理：

echo "gitlabMergeRequestLastCommit is $gitlabMergeRequestLastCommit" changeFileList=`git show --pretty="" --name-only $gitlabMergeRequestLastCommit`

echo "Changed file list $changeFileList"

for changeFile in $changeFileList

do

    cpplint.exe --extensions=cpp,h --recursive  --linelength=120 $changeFile 2>> cpplint.xml || exit 0

done

---