这个文档目前只包括 安装 和 配置 的部分，而对于使用，因为笔者也在学习和熟悉中，所以暂时无法提供更多的分享。
网上关于pc-lint的介绍几乎千篇一律，偶有一些带有个人（有的还比较独特）的看法。
此外，从我在自己的小圈子里咨询朋友，一些论坛里发帖请教的 情况来看。
我的个人观点是，pc-lint这个工具在国内似乎被使用的不多。
而我们从网上这些千篇一律的介绍里可以了解到：pc-lint作为一个“历史悠久”（IT世界的30年的确配得上“古老”一词。）
功能异常强劲的 静态检查工具。
更重要的是，包括微软在内的一些著名IT公司，在调试程序以前，让代码通过pc-lint检查是第一个门槛。
Pc-lint本身可以简单认为是一个 比一般编译器 更加严格的检查工具，此外它还能检查指示出一些 在语法上没有错误，但存在隐患和风险的错误和警告。通过它的检查，我们可以把代码写的更严谨，减少调试时间和难度等调试成本
——一般来说，在越往前的阶段能够找到错误，其相应的修改和调试成本就更低。
说了这么多，我们还是先把这个工具用起来再说。
pc-lint这个工具的使用方式主要有两种，一是 单独安装后，配置集成入使用的ide或者其他，主要是 编辑器 当中使用。
而这种配置背后则是它的最基本使用方式——命令行。
这也是造成pc-lint比较难以使用的主要原因——先不说如何设置和使用，单单是配置好就很费劲。
由于是使用命令行，在文件的路径等问题上经常会遇到一些麻烦——最简单的麻烦就是，你要么打很长很长的文件路径，要么就得被逼把很多很多东西放到同一个文件夹下（当然这是不熟悉命令行的我的个人感受）。
这种事让我觉得很郁闷很不爽。
最后，在我在三个ide下集成配置好了pc-lint以后，我终于渐渐意识到并且决定。
使用以下这个方案：
在一个功能比较强悍的经典的 编辑器 中设置好pc-lint以后，以后每一次不管是什么项目，什么MCU，什么ide,我都可以只是简单修改一下 批命令脚本，然后就一本万利地使用pc-lint。
因为还不是非常熟悉如何配置pc-lint，而网上的很多教程和资料都是针对 source insight为多，所以我选择source insight这一个功能非常强大的编辑器。
以下的配置过程 都是 针对 source insight
——当然，事后我发现至少我看的教程都不很完整，因此尽管我因为教程的原因选择了SI,但后来我都是一半靠猜一半靠不断百度才搞定的情况来看，选择任何一款你喜欢的更熟悉的编辑器似乎没有什么区别。
因为在linux下编译程序时，参考过几个不同makefile后，知道一些看起来很爽的写法。本来试图在cmd下也类似地使用到这些方法。
比如说设置临时的 环境变量，好让 头文件的路径 和 pc-lint的安装路径 如同宏一样只需要一次改动，方便使用，同时也让bat脚本看起来更加容易理解。
不过，搞了一下set这个命令似乎有点问题。
所以还是先把目前的设置方法总结好先吧！命令行的东西看来真的是要慢慢积累的呵呵~
前面说了，为了让我们写的命令行可以尽可能少改动在不同的项目中反复使用，我们需要一个通用的文件夹组织模版。
下面先说说如何组织我们的工程项目。
任何一个项目工程，实际上肯定不只是包含源代码或者编译调试时自动产生的那些我们一般不会看（也看不懂）的文件。
它还包含 我们的文档以及其他附加的部分（比如这次我们加进去的pc-lint检查）。
按照不同的功能分类文件夹，可以让整个项目组织层次明晰——同时，在ide以及其他诸如pc-lint的命令行中组织文件路径也会相对方便一些。
现在我们只需要知道。
在pc-lint这个文件夹下就是我使用source insight做pc-lint检查的一些配置文件以及相应的说明记录文档。（比如就包含这个文件）
最重要的是——
用SI建立的这个项目的根目录 就是 pc-lint这个文件夹（E：\GeneralFramework\pc-lint）
这个文件夹中有很多文件我们可以先不管他，因为它们是建立SI项目时自动生成的，我也不知道他们是干嘛的。
只要关注 两个文件
lintSI.bat SI_std.lnt
至于 pc-lint result.txt 这个事实上是我 另存输出结果的文档——我还不知道如何设置命令能让它自动 生成 这个文件。
至于 sub file这个文件夹，它类似于 上一层目录 中的 file，不过它只属于 pc-lint这个子系统的文档，故而叫 sub file
所有的设置和命令都在 那个bat和lnt文件夹里。
下面我们展开这两个文件的内容：
lintSI.bat的内容：
c:\lint\lint-nt.exe -u SI_std.lnt
这个最简单，实际上它就是使用lint-nt.exe这个命令而已。
C：\lint\是pc-lint的安装路径——在很多教程里都推荐最好就装在这个默认路径下，特别提醒不要放在类似Program File之类的文件夹下，以免有时会惹出麻烦。
我没有做过太多尝试，但依我的理解是问题仅仅只是因为 文件路径里出现了空格，而pc-lint对此似乎经常会出问题。所以应该可以换到其他路径下，只要不要出现空格，并且尽可能短。
这里要注意这个 –u选项。它是一个选择使用 .lnt文件的命令前缀。因为我们的命令变量都写在 std.lnt这个脚本里，所以在它前面要加这个前缀。
SI_std.lnt的内容比较复杂：
总的来说，我们可以这样理解这个lnt文件就是 lint-nt.exe这个命令后的变量。
它主要是 选择对应的co-文件（这是选择使用的编译器选项） 以及其他选项——不过鉴于目前我尚且不熟悉如何设置那几百个选项。所以我只是对这个最熟悉。
还有就是要检查的源文件和所包含的头文件的路径。
// IAR C, -mD -si2 -spn2 -spf4
// Standard lint options
//这两条应该是一些其他选项，鉴于还不懂，为了能让pc-lint先工作起来，我们先把它们注释掉。
c:\lint\au-misra2.lnt
c:\lint\co-iar.lnt
//这里，因为我这个项目是在IAR里做的针对stm8s的程序，而我在co-列表里没有找到专门的对应stm
//的，所以参考教程，我选择了 iar这个编译器选项（co就是指 compiler 编译器）
//至于misra2，这个是指MISRA-C 2004标准，是一个从汽车工业起源，用于对安全性有高要求的嵌入//式系统的一个检查标准。
//options.lnt -mD -si2 -spN2 -spF4
// IAR install position:
//"C:\Program Files\IAR Systems\Embedded Workbench 6.0 Kickstart\common\bin\IarIdePm.exe"
//这两句我也看不太懂，所以也先注释掉。
-i"C:\Program Files\IAR Systems\Embedded Workbench 6.0 Kickstart\stm8\inc"
-i"C:\Program Files\IAR Systems\Embedded Workbench 6.0 Kickstart\stm8\inc\c"
//这里是系统安装时IAR的头文件夹路径
-i"..\User\Hardware Layer\inc"
-i"..\User\Module Layer\inc"
-i"..\User\Application Layer\inc"
-i"..\User\Hardware Layer\stm8s_inc"
//这是我自己定义的头文件夹路径
"..\User\Application Layer\main.c"
"..\User\Hardware Layer\src\gpio.c"
//这些是我要检查的源文件。
//目前还是只会这种看起来比较弱智的办法，全部源文件写进去，以让它能够对整个 项目做检查。
// end of file
有了这些以后。我们只要在pc-lint这个文件夹下建立一个Source Insight(SI)项目。选择相对路径方式。
然后简单的添加一条 自定义 工具命令 就可以使用 了。
具体方法是：
1. 建立SI项目。
打开SI。 Project – New Project.然后输入相应的名字和指定文件夹路径，往下走时，在 New Project setting里确定使用这个文件夹路径即可——
默认时，都是使用相对路径，从此这就是这个项目的根目录。
所以以后在它里面调用任何东西，我们都可以简单的通过 一个 “\”就代表这个项目文件的根目录路径。
2. 自定义pc-lint工具命令。
Options – Custom Command
看着图可能更容易理解。所以我把我的设置截图上来。
从上往下
Command:
PC-Lint Check Current File —— 这个是你设置的这个命令的名字，随你怎么起，只要好记就好了（我最初是参考教程做的，所以名字上是检查单源文件。）
Run:
lintSI.bat
这是让它跑我写的批处理脚本。
其他的保持默认即可。
你可以先 点一下 Run按钮让它泡一下。也可以先确定这个命令的定制。然后再回到 Option下。就会看到多了这个
PC-Lint Check Current File选项。一点就可以运行pc-lint检查——按照我们写的 bat和lnt脚本。
至于输出的结果，看起来还比较晕，具体的使用先放下。
这个文档的内容到此结束。
引用: quner 发表于 2017-12-12 18:08
版主，最近还在用静态检查工具么？这个PC-lint好不好用？
引用: 辛昕 发表于 2017-12-13 10:14
很久没弄了。
不过，有一个后来的想法：
一开始最好从小代码开始测试。
一开始就把ST库这种根本没经过 ...
引用: quner 发表于 2017-12-13 11:17
是啊，我测了一个带UCOS的实际项目，有6000+的错误，吓哭了，正在改成满足misrac规则的代码
京公网安备 11010802033920号
