【C/C++】代码质量控制手段

问题引入

多人协作开发的项目，没有统一的代码规范，那么最终的编写状态必定风格迥异，产生的结果：对内，阅读审核代码是很痛苦的；对外，公司形象就是差。

单干的项目也必须要严格按照代码规范，因为最终还是会对内和对外。

要改变一个误解的常识，代码规范并不影响代码质量，代码质量的维度可从运行稳定、执行性能、易维护性三方面考虑。

解决方法

将代码规范控制在源头：格式化工具 Astyle -- 易维护性

阶段性检查代码质量：静态检查工具 Cppcheck -- 运行稳定

最终的质量保证手段：业务流程化和审核专业化 -- 执行性能

人是最容易犯错的，减少犯错就得借助三化：工具化、流程化、专业化。

方案论证

格式化工具：
Astyle
官网：http://astyle.sourceforge.net/
功能介绍：
A Free, Fast, and Small Automatic Formatter for C, C++, C++/CLI, Objective‑C, C#, and Java Source Code.

许可：开源且商用免费
源码：https://sourceforge.net/p/astyle/code/HEAD/tree/
优劣：功能强大、易用、免费，支持以IDE插件方式使用，如MDK、IAR、SourceInsignt、VS-Code、Notepad等，但不支持代码风格检查

Cpplint
官网：https://google.github.io/styleguide/cppguide.html
功能介绍：
Cpplint is a command-line tool to check C/C++ files for style issues following Google's C++ style guide. Cpplint is developed and maintained by Google Inc. at google/styleguide, also see the wikipedia entry
许可：开源且商用免费
源码：https://github.com/cpplint/cpplint
优劣：功能强大，遵从Google C++代码规范的强烈建议使用，支持以IDE插件方式使用，但自有代码规范需要修改源码，难度较大

静态检查工具：

静态检查工具罗列：https://github.com/analysis-tools-dev/static-analysis

部分介绍

Cppcheck
官网：http://cppcheck.net/
功能介绍：
Cppcheck is a static analysis tool for C/C++ code. It provides unique code analysis to detect bugs and focuses on detecting undefined behaviour and dangerous coding constructs.
The goal is to have very few false positives. Cppcheck is designed to be able to analyze your C/C++ code even if it has non-standard syntax (common in embedded projects).

许可：开源且商用免费
源码：https://github.com/danmar/cppcheck
优劣：功能强大、免费、易用，支持 windows、linux

SonarQube
官网：https://www.sonarqube.org/
功能介绍：

许可：社区版和收费版，C/C++收费版才有
源码：社区版
优劣：功能强大，但用于C/C++需要付费

推荐文章（工具对比）：《C++静态检测工具有哪些值得推荐？》
简要如下图，详细参见上述链接
静态检查项：

工具对比：

推荐文章（工具对比）：《九大顶级静态代码分析工具 - 知乎 (zhihu.com)》

推荐文章（工具对比）：《C++静态代码扫描哪家强？》

简要如下图，详细参见上述链接

从易用性和免费角度出发的最终方案选择：

Astyle 可在源头有效控制编码风格且免费易用，故选择Astyle作为编码风格工具

Cppcheck 功能强大，支持单文件和目录方式检查，可与Jenkins集成，检查规则全面且检查出的问题都是编译正常的且免费易用

接受收费的情况下，建议选择 SonarQube，功能很强大，支持语言丰富，检查规则全面，易于集成且支持多阶段检查，出问题时技术支持也更迅速

实施过程

AStyle推荐文章：

《在IAR中利用AStyle插件格式化代码》：https://blog.csdn.net/qq_20222919/article/details/103857352

《STM32开发中Keil使用Astyle自动格式化整理代码》：https://blog.csdn.net/yuleitao/article/details/103408567

《如何在notepad++实现代码自动化排版(调用Astyle)》：https://www.cnblogs.com/libra13179/p/9120360.html

《vscode添加 Artistic Style（AStyle）》：https://blog.csdn.net/tianma666666/article/details/103478792

《Source Insight 4.0集成格式化工具AStyle》：https://blog.csdn.net/redeagle_gbf/article/details/81566871

详细使用方法见官方手册：http://astyle.sourceforge.net/astyle.html

Cppcheck检查演示

数组越界赋值：

类模板递归次数太多潜在问题：

详细使用方法见Cppcheck官方手册：https://cppcheck.sourceforge.io/manual.html

总结建议

规范的代码可提升团队开发效率；

规范的代码可减少编写引入的bug；

规范的代码可降低维护的成本；

规范的代码可使代码审查更容易；

规范的代码可帮助自身和公司成长；

工具、流程只是为了将犯错减少但并不能实现零错误，所以为了将犯错降至更低只能以专业化的态度认真对待代码规范这个事，只有对代码质量报以敬畏之心，代码才会有质量可言，切不可迷之自信！

建议业务流程：

1、代码编写/修改，实现业务功能

2、Astyle格式化，满足公司或团队的代码风格，也是为了后期维护

3、Cppcheck静态检查，将隐含错误遏制在开发阶段

4、开发本地功能验证，主要是验证功能逻辑的准确性，这一步是必须要做的，是代码质量的第一道关卡，无法用工具替代

5、Jenkins构建版本，且生成Cppcheck检查报告，与步骤3相互印证，检查上库代码是否与仓代码冲突，是否有语法错误，有问题回到步骤1

6、Gerrit代码审核（专业团队），任何工具都无法检测逻辑正确性，所以审核者要对编码规范、语法错误、功能逻辑要认真审核，有问题回到步骤1，这是代码质量的关键环节

7、构建版本开发验证，有问题回到步骤1，无问题即可Merge到代码仓

8、构建版本测试验证，Jira提单跟踪反馈至开发，这一步是对外发布的最后一道关卡，必须严格按照测试用例进行验证，同步骤5一样是代码质量的关键环节

9、测试用例满足，即可对外发布