简介PC-lint Plus 是 Gimpel Software 推出的 C/C 静态分析工具本资源面向需要在编码阶段排查潜在缺陷、规范编程习惯并优化性能的开发者尤其适合大型项目与团队协作场景。压缩包共 26 个文件约 29.7MB包含 6 个 exe 可执行程序如 pclp32、pclp64 及调试版本、11 个 lnt 配置规则文件覆盖 MISRA、AUTOSAR、CERT C 等规范、2 个 pdf 文档含试用许可证与使用手册、1 个 url 快捷链接以及 js、h、yaml、txt、c、py 等辅助脚本与配置文件Windows 平台安装与规则定制所需内容基本齐备。目前已有 779 人学习下载。借助其中的规则集与配置脚本读者可快速搭建静态检查环境按项目需求启用对应规范在编码阶段发现并修复问题降低调试与维护成本。1. 拿到 pclp-1_plus 压缩包之后它到底能替你挡住哪些 C/C 的坑刚接手一个跑了七八年的 C/C 老项目编译能过、测试能跑但每次上线前心里都没底——指针越界、未初始化变量、隐式类型截断这些玩意儿编译器根本不会拦你。这时候静态分析工具就是那道额外的防线而 PC-lint Plus圈里常叫 pclintplus 或 pc-lint就是这条防线上最老牌的那一类工具。它不跑代码只扫源码把 MISRA、AUTOSAR、CERT C 这些规范里最容易翻车的写法一条条揪出来。这次拆的pclp-1_plus压缩包本质上是 PC-lint Plus 在 Windows 下的一套可运行环境加配置集合。里面既有pclp32.exe、pclp64.exe这样的主程序也有au-misra3.lnt、au-certc.lnt、au-autosar.lnt这些规则配置文件还有pclp_config.py、compilers.yaml这类辅助脚本。它解决的不是“帮你写代码”而是“在你提交之前告诉你哪里写得不干净”。适合谁适合那些项目里 C/C 代码量已经大到人工 review 看不过来、又不想等运行时崩溃才回头查的团队。如果你只是写几十行练手代码这东西的配置成本可能比收益还高但只要代码上了万行、还要过功能安全或代码规范审计它就值得你花一个下午把环境跑通。2. 拆开 pclp-1_plus主程序、规则集与配置脚本怎么分工2.1 可执行文件与调试版本的区别压缩包里最显眼的是四个 exepclp32.exe、pclp64.exe、pclp32_debug.exe、pclp64_debug.exe。32 和 64 的区别不用多说取决于你分析的目标代码是 32 位还是 64 位编译环境。真正容易被忽略的是带_debug后缀的那两个——它们不是给你调试自己代码用的而是当 PC-lint Plus 本身行为异常时用来输出更详细的内部日志。常见做法是日常分析用pclp64.exe如果发现某条规则误报或者程序直接崩了换pclp64_debug.exe跑一遍把日志留下来排查。这里有个血泪经验很多人拿到包直接双击pclp64.exe发现窗口一闪而过以为工具坏了。其实 PC-lint Plus 是命令行工具双击没有传参自然就退了。正确姿势是开 cmd 或 PowerShellcd 到解压目录再带参数调用。2.2 规则配置文件au- 前缀那一堆 .lnt 是什么au-misra3.lnt、au-misra3-amd1.lnt、au-misra2.lnt、au-misra-cpp.lnt、au-autosar.lnt、au-certc.lnt、au-barr.lnt——这些是 PC-lint Plus 最核心的资产。au-前缀是 Gimpel 官方对“AU”系列规则集的命名习惯后面跟的 MISRA3、MISRA2、AUTOSAR、CERT C、Barr 都是行业里常见的编码标准。你不需要自己从零写规则只要在配置文件里-restore或者-include对应的 .lnt就能把整套规则挂上去。au-misra3-amd1.lnt是 MISRA C:2012 的 Amendment 1 补充规则做汽车电子或工业控制的基本绕不开。au-misra-cpp.lnt则是给 C 项目用的 MISRA C 规则。选哪套取决于你的项目要过什么认证不是越多越好——规则开太多误报会把真正的问题淹没。2.3 env- 与 x86-builtins环境适配层env-xml.lnt、env-html.lnt、env-iar.lnt这几个是输出格式和环境适配文件。env-xml.lnt让分析结果输出成 XML方便接 CI 做自动化解析env-html.lnt生成 HTML 报告给人看比较友好env-iar.lnt是给 IAR 编译器环境做适配的。x86-builtins.lnt和x86-builtins.h则是告诉 PC-lint Plus 在 x86 平台上哪些是编译器内置函数避免它把__builtin_xxx这类东西当成未定义标识符报出来。compilers.yaml和pclp_config.py是配置辅助。compilers.yaml里通常记录了不同编译器的预定义宏和包含路径pclp_config.py则是一个 Python 脚本用来生成或修改 PC-lint Plus 的配置文件。如果你用的是 CMake 或 Makefile 构建的项目常见做法是用pclp_config.py从编译数据库里提取包含路径和宏定义再喂给 PC-lint Plus省得手动一条条写-I和-D。3. 在 Windows 上把 pclp64.exe 跑起来从命令行到项目级配置3.1 最小可运行命令与参数含义先把压缩包解到一个没有中文和空格的路径比如D:\tools\pclp。然后开 PowerShellcd D:\tools\pclp .\pclp64.exe --help如果能看到帮助信息说明主程序能跑。接下来拿一个最简单的 C 文件试水.\pclp64.exe -iconfig -idoc .\test.c这里-i是 include 路径指向config和doc目录让 PC-lint Plus 能找到自带的配置文件。test.c是你的目标源文件。跑完之后它会输出一堆警告和错误每条都带规则编号和行号。但实际项目不可能只有一个文件。常见做法是写一个project.lnt配置文件把所有源文件、头文件路径、宏定义都写进去// project.lnt -isrc -iinclude -ithird_party -DPLATFORM_WIN32 -DDEBUG0 au-misra3.lnt env-xml.lnt test.c main.c driver.c然后这样调用.\pclp64.exe project.lnt report.xml-i指定头文件搜索路径-D定义预处理器宏au-misra3.lnt挂载 MISRA C:2012 规则env-xml.lnt让输出变成 XML。最后重定向到report.xml方便后续用脚本解析。3.2 用 pclp_config.py 从编译数据库生成配置手动维护project.lnt在文件少的时候还行文件一多就是灾难。pclp_config.py就是干这个的。它通常配合compilers.yaml使用从compile_commands.json里提取每个文件的编译参数。# 示例调用 pclp_config.py 生成配置 import subprocess subprocess.run([ python, pclp_config.py, --compilers, compilers.yaml, --compile-commands, compile_commands.json, --output, generated.lnt ])--compilers指定编译器描述文件--compile-commands是 CMake 或 Bear 生成的编译数据库--output是生成的 lnt 文件。跑完之后generated.lnt里就包含了每个源文件对应的-I和-D你只需要在它后面追加规则集和源文件列表就行。注意compile_commands.json里的路径如果是相对路径pclp_config.py可能解析出错。常见做法是先用 CMake 的CMAKE_EXPORT_COMPILE_COMMANDS生成绝对路径版本再喂给脚本。3.3 规则集的选择与裁剪不是每个项目都需要把 MISRA、AUTOSAR、CERT 全开。我一般会先跑一遍全规则看看误报率再决定裁剪哪些。比如一个纯应用层的 C 项目au-autosar.lnt里很多规则是针对嵌入式的开了只会增加噪音。// 裁剪示例只保留 MISRA C 和 CERT C au-misra-cpp.lnt au-certc.lnt // 关闭某条误报严重的规则 -e970-e后面跟规则编号表示禁用该规则。规则编号在 PC-lint Plus 的手册manual.pdf里有完整列表。裁剪的原则是先全开跑一遍把误报的规则记下来逐条确认后禁用而不是一上来就凭感觉关。4. 避坑与排查pclp-1_plus 在真实项目里最容易翻车的五个点4.1 现象跑完没有任何输出或者只输出一行“PC-lint Plus”就退出原因通常是命令行参数没传对或者目标文件路径不存在。PC-lint Plus 不会像图形界面工具那样弹窗告诉你“文件没找到”它可能直接静默退出。解决方法是加-v参数输出详细过程或者先用一个绝对路径的简单文件测试。另外如果project.lnt里引用的源文件用了相对路径而你在别的目录下调用pclp64.exe也会找不到文件。我一般会在 lnt 文件里统一用相对于 lnt 文件所在目录的路径并且调用时先 cd 到那个目录。4.2 现象大量“未定义标识符”报错但代码明明能编译过原因通常是 PC-lint Plus 不知道你的编译器预定义了哪些宏或者头文件搜索路径不全。比如 GCC 的__GNUC__、MSVC 的_MSC_VER如果没通过-D传进去PC-lint Plus 就会把相关条件编译分支走错。解决方法是把编译器实际使用的宏定义全部提取出来写进 lnt 文件。compilers.yaml里通常已经预置了常见编译器的宏但如果你用的是自定义工具链就得手动补。4.3 现象MISRA 规则报了几千条根本看不过来原因是你把规则集全开了但项目本身并没有按照 MISRA 从零写起。对于存量项目正确做法是先用-e关掉那些“历史遗留但不会导致实际 bug”的规则只保留和内存安全、未定义行为相关的。另一个技巧是用-summary参数只输出统计摘要先看哪类规则报得最多再决定是修代码还是关规则。不要试图一次性修完所有 MISRA 违规那会导致项目停滞。4.4 现象分析速度极慢一个文件要跑十几秒原因可能是头文件路径太多或者开了-vf跟随所有 include导致重复解析。常见做法是给系统头文件加-w或者用-libdir指定库目录让 PC-lint Plus 跳过对系统头文件的深度分析。另外x86-builtins.lnt如果没正确加载PC-lint Plus 会尝试解析编译器内置函数也会拖慢速度。确认x86-builtins.lnt在配置文件里被 include 了。4.5 现象XML 报告里中文注释乱码原因通常是源文件编码和 PC-lint Plus 输出编码不一致。Windows 下中文项目常见 GBK 编码而env-xml.lnt默认可能按 UTF-8 输出。解决方法是在 lnt 文件里加-encodinggbk或者把源文件统一转成 UTF-8。如果项目里混用编码那就只能先统一编码再分析否则报告里的中文全是问号排查起来更费劲。5. 把 PC-lint Plus 接进日常流程增量分析与报告过滤的实用技巧环境跑通之后真正决定这东西能不能长期用下去的是你怎么把它塞进日常开发流程。全量分析一个几万行的项目跑一次可能要十几分钟没人愿意每次提交都等。我一般会做两件事增量分析和报告过滤。增量分析的核心思路是只分析本次改动涉及的文件。如果你用 Git可以这样拿改动文件列表git diff --name-only HEAD~1 HEAD -- *.c *.cpp *.h changed_files.txt然后写一个简单的 Python 脚本把changed_files.txt里的文件拼成 lnt 文件# gen_incremental_lnt.py with open(changed_files.txt, r) as f: files [line.strip() for line in f if line.strip()] with open(incremental.lnt, w) as f: f.write(au-misra3.lnt\n) f.write(env-xml.lnt\n) for file in files: f.write(file \n)跑完之后调用pclp64.exe incremental.lnt incremental_report.xml。这样每次只分析改动文件速度从十几分钟降到几十秒。但要注意增量分析会漏掉跨文件的全局问题比如头文件里的宏定义改了但没重新分析所有包含它的源文件。所以我的习惯是每天下班前跑一次全量日常提交用增量。报告过滤是另一个关键。PC-lint Plus 的 XML 报告里信息量很大直接丢给开发看会被淹没。我一般会写个脚本按规则编号和严重级别过滤# filter_report.py import xml.etree.ElementTree as ET tree ET.parse(incremental_report.xml) root tree.getroot() for issue in root.iter(issue): rule issue.find(rule).text severity issue.find(severity).text if severity in (error, warning) and rule not in (970, 971): file issue.find(file).text line issue.find(line).text msg issue.find(message).text print(f{file}:{line} [{rule}] {msg})这个脚本把 error 和 warning 级别的、且不在忽略列表里的问题打印出来info 级别的直接丢掉。规则编号 970 和 971 通常是一些环境相关的提示误报率高我一般会过滤掉。过滤后的结果可以直接贴到代码审查工具里或者生成一个 HTML 页面给团队看。还有一个容易被忽略的点PC-lint Plus 的规则编号在不同版本之间可能会有细微差异。manual.pdf里有一章专门讲规则编号的映射关系升级版本之后最好对照一下别把该禁用的规则编号搞错了。我一般会在项目根目录放一个lint_rules.md记录当前版本下禁用了哪些规则、为什么禁用、谁批准的。这样换人维护的时候不至于一脸懵。从那以后我每次拿到新的静态分析工具包都强制先跑一个最小文件、再跑一个真实文件、最后才接项目配置三步走完再谈规则裁剪。希望帮到你。本文还有配套的精品资源点击获取
PC-lint Plus 静态分析实战：pclp-1_plus 配置、规则裁剪与增量分析
简介PC-lint Plus 是 Gimpel Software 推出的 C/C 静态分析工具本资源面向需要在编码阶段排查潜在缺陷、规范编程习惯并优化性能的开发者尤其适合大型项目与团队协作场景。压缩包共 26 个文件约 29.7MB包含 6 个 exe 可执行程序如 pclp32、pclp64 及调试版本、11 个 lnt 配置规则文件覆盖 MISRA、AUTOSAR、CERT C 等规范、2 个 pdf 文档含试用许可证与使用手册、1 个 url 快捷链接以及 js、h、yaml、txt、c、py 等辅助脚本与配置文件Windows 平台安装与规则定制所需内容基本齐备。目前已有 779 人学习下载。借助其中的规则集与配置脚本读者可快速搭建静态检查环境按项目需求启用对应规范在编码阶段发现并修复问题降低调试与维护成本。1. 拿到 pclp-1_plus 压缩包之后它到底能替你挡住哪些 C/C 的坑刚接手一个跑了七八年的 C/C 老项目编译能过、测试能跑但每次上线前心里都没底——指针越界、未初始化变量、隐式类型截断这些玩意儿编译器根本不会拦你。这时候静态分析工具就是那道额外的防线而 PC-lint Plus圈里常叫 pclintplus 或 pc-lint就是这条防线上最老牌的那一类工具。它不跑代码只扫源码把 MISRA、AUTOSAR、CERT C 这些规范里最容易翻车的写法一条条揪出来。这次拆的pclp-1_plus压缩包本质上是 PC-lint Plus 在 Windows 下的一套可运行环境加配置集合。里面既有pclp32.exe、pclp64.exe这样的主程序也有au-misra3.lnt、au-certc.lnt、au-autosar.lnt这些规则配置文件还有pclp_config.py、compilers.yaml这类辅助脚本。它解决的不是“帮你写代码”而是“在你提交之前告诉你哪里写得不干净”。适合谁适合那些项目里 C/C 代码量已经大到人工 review 看不过来、又不想等运行时崩溃才回头查的团队。如果你只是写几十行练手代码这东西的配置成本可能比收益还高但只要代码上了万行、还要过功能安全或代码规范审计它就值得你花一个下午把环境跑通。2. 拆开 pclp-1_plus主程序、规则集与配置脚本怎么分工2.1 可执行文件与调试版本的区别压缩包里最显眼的是四个 exepclp32.exe、pclp64.exe、pclp32_debug.exe、pclp64_debug.exe。32 和 64 的区别不用多说取决于你分析的目标代码是 32 位还是 64 位编译环境。真正容易被忽略的是带_debug后缀的那两个——它们不是给你调试自己代码用的而是当 PC-lint Plus 本身行为异常时用来输出更详细的内部日志。常见做法是日常分析用pclp64.exe如果发现某条规则误报或者程序直接崩了换pclp64_debug.exe跑一遍把日志留下来排查。这里有个血泪经验很多人拿到包直接双击pclp64.exe发现窗口一闪而过以为工具坏了。其实 PC-lint Plus 是命令行工具双击没有传参自然就退了。正确姿势是开 cmd 或 PowerShellcd 到解压目录再带参数调用。2.2 规则配置文件au- 前缀那一堆 .lnt 是什么au-misra3.lnt、au-misra3-amd1.lnt、au-misra2.lnt、au-misra-cpp.lnt、au-autosar.lnt、au-certc.lnt、au-barr.lnt——这些是 PC-lint Plus 最核心的资产。au-前缀是 Gimpel 官方对“AU”系列规则集的命名习惯后面跟的 MISRA3、MISRA2、AUTOSAR、CERT C、Barr 都是行业里常见的编码标准。你不需要自己从零写规则只要在配置文件里-restore或者-include对应的 .lnt就能把整套规则挂上去。au-misra3-amd1.lnt是 MISRA C:2012 的 Amendment 1 补充规则做汽车电子或工业控制的基本绕不开。au-misra-cpp.lnt则是给 C 项目用的 MISRA C 规则。选哪套取决于你的项目要过什么认证不是越多越好——规则开太多误报会把真正的问题淹没。2.3 env- 与 x86-builtins环境适配层env-xml.lnt、env-html.lnt、env-iar.lnt这几个是输出格式和环境适配文件。env-xml.lnt让分析结果输出成 XML方便接 CI 做自动化解析env-html.lnt生成 HTML 报告给人看比较友好env-iar.lnt是给 IAR 编译器环境做适配的。x86-builtins.lnt和x86-builtins.h则是告诉 PC-lint Plus 在 x86 平台上哪些是编译器内置函数避免它把__builtin_xxx这类东西当成未定义标识符报出来。compilers.yaml和pclp_config.py是配置辅助。compilers.yaml里通常记录了不同编译器的预定义宏和包含路径pclp_config.py则是一个 Python 脚本用来生成或修改 PC-lint Plus 的配置文件。如果你用的是 CMake 或 Makefile 构建的项目常见做法是用pclp_config.py从编译数据库里提取包含路径和宏定义再喂给 PC-lint Plus省得手动一条条写-I和-D。3. 在 Windows 上把 pclp64.exe 跑起来从命令行到项目级配置3.1 最小可运行命令与参数含义先把压缩包解到一个没有中文和空格的路径比如D:\tools\pclp。然后开 PowerShellcd D:\tools\pclp .\pclp64.exe --help如果能看到帮助信息说明主程序能跑。接下来拿一个最简单的 C 文件试水.\pclp64.exe -iconfig -idoc .\test.c这里-i是 include 路径指向config和doc目录让 PC-lint Plus 能找到自带的配置文件。test.c是你的目标源文件。跑完之后它会输出一堆警告和错误每条都带规则编号和行号。但实际项目不可能只有一个文件。常见做法是写一个project.lnt配置文件把所有源文件、头文件路径、宏定义都写进去// project.lnt -isrc -iinclude -ithird_party -DPLATFORM_WIN32 -DDEBUG0 au-misra3.lnt env-xml.lnt test.c main.c driver.c然后这样调用.\pclp64.exe project.lnt report.xml-i指定头文件搜索路径-D定义预处理器宏au-misra3.lnt挂载 MISRA C:2012 规则env-xml.lnt让输出变成 XML。最后重定向到report.xml方便后续用脚本解析。3.2 用 pclp_config.py 从编译数据库生成配置手动维护project.lnt在文件少的时候还行文件一多就是灾难。pclp_config.py就是干这个的。它通常配合compilers.yaml使用从compile_commands.json里提取每个文件的编译参数。# 示例调用 pclp_config.py 生成配置 import subprocess subprocess.run([ python, pclp_config.py, --compilers, compilers.yaml, --compile-commands, compile_commands.json, --output, generated.lnt ])--compilers指定编译器描述文件--compile-commands是 CMake 或 Bear 生成的编译数据库--output是生成的 lnt 文件。跑完之后generated.lnt里就包含了每个源文件对应的-I和-D你只需要在它后面追加规则集和源文件列表就行。注意compile_commands.json里的路径如果是相对路径pclp_config.py可能解析出错。常见做法是先用 CMake 的CMAKE_EXPORT_COMPILE_COMMANDS生成绝对路径版本再喂给脚本。3.3 规则集的选择与裁剪不是每个项目都需要把 MISRA、AUTOSAR、CERT 全开。我一般会先跑一遍全规则看看误报率再决定裁剪哪些。比如一个纯应用层的 C 项目au-autosar.lnt里很多规则是针对嵌入式的开了只会增加噪音。// 裁剪示例只保留 MISRA C 和 CERT C au-misra-cpp.lnt au-certc.lnt // 关闭某条误报严重的规则 -e970-e后面跟规则编号表示禁用该规则。规则编号在 PC-lint Plus 的手册manual.pdf里有完整列表。裁剪的原则是先全开跑一遍把误报的规则记下来逐条确认后禁用而不是一上来就凭感觉关。4. 避坑与排查pclp-1_plus 在真实项目里最容易翻车的五个点4.1 现象跑完没有任何输出或者只输出一行“PC-lint Plus”就退出原因通常是命令行参数没传对或者目标文件路径不存在。PC-lint Plus 不会像图形界面工具那样弹窗告诉你“文件没找到”它可能直接静默退出。解决方法是加-v参数输出详细过程或者先用一个绝对路径的简单文件测试。另外如果project.lnt里引用的源文件用了相对路径而你在别的目录下调用pclp64.exe也会找不到文件。我一般会在 lnt 文件里统一用相对于 lnt 文件所在目录的路径并且调用时先 cd 到那个目录。4.2 现象大量“未定义标识符”报错但代码明明能编译过原因通常是 PC-lint Plus 不知道你的编译器预定义了哪些宏或者头文件搜索路径不全。比如 GCC 的__GNUC__、MSVC 的_MSC_VER如果没通过-D传进去PC-lint Plus 就会把相关条件编译分支走错。解决方法是把编译器实际使用的宏定义全部提取出来写进 lnt 文件。compilers.yaml里通常已经预置了常见编译器的宏但如果你用的是自定义工具链就得手动补。4.3 现象MISRA 规则报了几千条根本看不过来原因是你把规则集全开了但项目本身并没有按照 MISRA 从零写起。对于存量项目正确做法是先用-e关掉那些“历史遗留但不会导致实际 bug”的规则只保留和内存安全、未定义行为相关的。另一个技巧是用-summary参数只输出统计摘要先看哪类规则报得最多再决定是修代码还是关规则。不要试图一次性修完所有 MISRA 违规那会导致项目停滞。4.4 现象分析速度极慢一个文件要跑十几秒原因可能是头文件路径太多或者开了-vf跟随所有 include导致重复解析。常见做法是给系统头文件加-w或者用-libdir指定库目录让 PC-lint Plus 跳过对系统头文件的深度分析。另外x86-builtins.lnt如果没正确加载PC-lint Plus 会尝试解析编译器内置函数也会拖慢速度。确认x86-builtins.lnt在配置文件里被 include 了。4.5 现象XML 报告里中文注释乱码原因通常是源文件编码和 PC-lint Plus 输出编码不一致。Windows 下中文项目常见 GBK 编码而env-xml.lnt默认可能按 UTF-8 输出。解决方法是在 lnt 文件里加-encodinggbk或者把源文件统一转成 UTF-8。如果项目里混用编码那就只能先统一编码再分析否则报告里的中文全是问号排查起来更费劲。5. 把 PC-lint Plus 接进日常流程增量分析与报告过滤的实用技巧环境跑通之后真正决定这东西能不能长期用下去的是你怎么把它塞进日常开发流程。全量分析一个几万行的项目跑一次可能要十几分钟没人愿意每次提交都等。我一般会做两件事增量分析和报告过滤。增量分析的核心思路是只分析本次改动涉及的文件。如果你用 Git可以这样拿改动文件列表git diff --name-only HEAD~1 HEAD -- *.c *.cpp *.h changed_files.txt然后写一个简单的 Python 脚本把changed_files.txt里的文件拼成 lnt 文件# gen_incremental_lnt.py with open(changed_files.txt, r) as f: files [line.strip() for line in f if line.strip()] with open(incremental.lnt, w) as f: f.write(au-misra3.lnt\n) f.write(env-xml.lnt\n) for file in files: f.write(file \n)跑完之后调用pclp64.exe incremental.lnt incremental_report.xml。这样每次只分析改动文件速度从十几分钟降到几十秒。但要注意增量分析会漏掉跨文件的全局问题比如头文件里的宏定义改了但没重新分析所有包含它的源文件。所以我的习惯是每天下班前跑一次全量日常提交用增量。报告过滤是另一个关键。PC-lint Plus 的 XML 报告里信息量很大直接丢给开发看会被淹没。我一般会写个脚本按规则编号和严重级别过滤# filter_report.py import xml.etree.ElementTree as ET tree ET.parse(incremental_report.xml) root tree.getroot() for issue in root.iter(issue): rule issue.find(rule).text severity issue.find(severity).text if severity in (error, warning) and rule not in (970, 971): file issue.find(file).text line issue.find(line).text msg issue.find(message).text print(f{file}:{line} [{rule}] {msg})这个脚本把 error 和 warning 级别的、且不在忽略列表里的问题打印出来info 级别的直接丢掉。规则编号 970 和 971 通常是一些环境相关的提示误报率高我一般会过滤掉。过滤后的结果可以直接贴到代码审查工具里或者生成一个 HTML 页面给团队看。还有一个容易被忽略的点PC-lint Plus 的规则编号在不同版本之间可能会有细微差异。manual.pdf里有一章专门讲规则编号的映射关系升级版本之后最好对照一下别把该禁用的规则编号搞错了。我一般会在项目根目录放一个lint_rules.md记录当前版本下禁用了哪些规则、为什么禁用、谁批准的。这样换人维护的时候不至于一脸懵。从那以后我每次拿到新的静态分析工具包都强制先跑一个最小文件、再跑一个真实文件、最后才接项目配置三步走完再谈规则裁剪。希望帮到你。本文还有配套的精品资源点击获取
