第二章 工具链搭建：PC-Lint安装与配置、Cppcheck安装与配置、SonarQube环境搭建
好，咱们直接进入正题。这一章我带你亲手把三把“手术刀”装好。静态分析工具说白了就是代码的X光机，装好了，你才能看清代码里那些看不见的“暗伤”。
我个人习惯先把环境搞利索了再干活。你想想看，工具都装不明白，后面分析出来的结果你敢信吗？
2.1 PC-Lint：老牌劲旅的安装与配置
PC-Lint这玩意儿，年纪比咱们很多程序员都大。但它老归老，查起C语言的“野指针”和“未初始化变量”来，那叫一个稳准狠。
第一步：获取安装包
去Gimpel Software官网下载。注意，它分PC-Lint和FlexeLint（跨平台版）。咱们在Windows上干活，用PC-Lint就行。
第二步：安装
双击安装包，一路Next。我建议你装到C:\lint这种没有空格的路径下。为什么？因为后面配置环境变量时，带空格的路径容易出幺蛾子。我在项目中遇到过因为路径带空格，导致整个项目报错找不到lint.exe的尴尬事。
第三步：配置环境变量
把C:\lint加到系统Path里。然后新建一个变量LINT，值设为C:\lint\lint-nt.exe。这样你在命令行里敲lint-nt就能直接跑了。
第四步：创建配置文件
PC-Lint的配置全靠.lnt文件。你需要创建一个std.lnt，里面写上你项目的头文件路径和编译选项。举个例子：
// std.lnt 示例
// 包含标准库配置
co-msc60.lnt
// 头文件路径
-I"C:\MyProject\inc"
-I"C:\MyProject\drivers"
// 错误级别
-w4
// 禁止某些烦人的警告
-e801 // 禁止“未使用的符号”警告
-e818 // 禁止“指针指向不同”的警告第五步：跑起来
在项目根目录执行：
lint-nt std.lnt source.c你会看到一堆输出。别慌，先看有没有Error开头的。Warning可以慢慢调，Error必须马上修。
2.2 Cppcheck：轻量级快枪手
Cppcheck跟PC-Lint不一样。它不依赖编译器，直接分析源码。说白了，它更适合快速扫描，发现那些明显的逻辑错误。
安装
去官网下载安装包。Windows下直接双击，Linux下用包管理器：
sudo apt-get install cppcheck基本用法
最简单的用法：
cppcheck --enable=all source.c但我不建议你上来就--enable=all。为什么？因为信息量太大，你会被淹没的。我建议先这样：
cppcheck --enable=warning,performance,portability source.c这样只显示警告、性能问题和可移植性问题。等你把这三类问题清干净了，再开style和information。
项目级扫描
如果你有一个大项目，别一个一个文件扫。用这个：
cppcheck --project=compile_commands.json前提是你得先生成compile_commands.json。CMake项目的话，加个-DCMAKE_EXPORT_COMPILE_COMMANDS=ON就行。
实战经验： 我在一个嵌入式项目中，用Cppcheck扫出了三个缓冲区溢出的隐患。那是个通信协议栈，如果没发现，设备在极端情况下会死机。嗯，从那以后，我把Cppcheck加到了CI流程里。
2.3 SonarQube：全流程质量看板
SonarQube不是单一的工具，它是一个平台。它能聚合PC-Lint、Cppcheck的结果，还能做代码覆盖率、重复代码检测。说白了，它就是你的代码质量“仪表盘”。
环境搭建
SonarQube依赖Java和数据库。我建议你用Docker，省心：
docker run -d --name sonarqube \
-p 9000:9000 \
-e SONAR_JDBC_URL=jdbc:postgresql://localhost:5432/sonar \
-e SONAR_JDBC_USERNAME=sonar \
-e SONAR_JDBC_PASSWORD=sonar \
sonarqube:lts-community等个一两分钟，打开浏览器访问http://localhost:9000。默认账号密码都是admin。
配置C语言插件
SonarQube社区版默认不支持C/C++。你需要安装插件。在Administration -> Marketplace里搜索“C”，找到“SonarCFamily”插件。注意，这个插件是收费的。但别急，社区版可以用“SonarCXX”这个开源替代品。
创建项目并分析
在SonarQube里创建一个项目，拿到一个token。然后在你的项目根目录执行：
sonar-scanner \
-Dsonar.projectKey=my_project \
-Dsonar.sources=. \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=你的token扫描完成后，刷新SonarQube页面。你会看到代码质量概览：
| 指标 | 说明 | 我的建议阈值 |
|---|---|---|
| Bugs | 明确的代码缺陷 | 0 |
| Vulnerabilities | 安全漏洞 | 0 |
| Code Smells | 代码坏味道 | 不超过代码行数的1% |
| Duplications | 重复代码比例 | 低于5% |
lint-nt std.lnt source.c 2>&1 | sonar-lint-report-converter转换成SonarQube能识别的格式。Cppcheck的话，用cppcheck --xml --xml-version=2 source.c 2> cppcheck-report.xml生成报告，然后在SonarQube里配置导入。
2.4 三剑客的协同工作流
你可能会问：“这三个工具都要用吗？”我的答案是：是的，而且有先后顺序。
- 本地开发时：用Cppcheck快速扫描。它快，能帮你拦住80%的低级错误。
- 提交代码前：跑PC-Lint。它查得细，能发现那些“编译器不报但运行时必崩”的问题。
- CI/CD流水线中：用SonarQube做全量分析。它把前两者的结果汇总，还能追踪历史趋势。
我曾经在一个项目中，团队只用了Cppcheck，觉得够了。结果上线后，一个PC-Lint能查出来的“未初始化变量”导致设备随机重启。嗯，从那以后，我坚持三件套必须齐全。
好了，工具链就搭到这里。下一章咱们开始实战，用这些工具去解剖一段真实的嵌入式C代码。你准备好了吗？