代码静态检查工具PC-Lint运用实践
代码静态检查工具PC-Lint运用实践
如何提交zero bug的产品，如何尽早发现bug，是软件开发工程师和测试工程师都需要思考的问题。我认为高质量的代码是关键，具体实施保障办法有：框架约束，代码评审，以及测试用例的设计和执行。
l 框架约束，可以将程序员从编写没有营养、易出错的代码工作中解放出来。程序员只需要写一些配置或描述，就可以由框架生成可运行的代码框架。这既提高了程序员的工作效率，使程序员关注在业务逻辑实现上，也由于框架的约束使程序形成了统一的风格和代码结构。同时由于是自动生成的框架代码，这部分经过严格的测试，可以确保是高质量的代码，大大降低Bug数。
l 代码评审，可以发现一些表面问题，如缺乏注释、大量使用全局变量以及明显的一些可能引发Bug的问题（如在不知道字符串长度的情况下使用Copy等），这其中包括程序员编码的基本素质和编程风格两个因素。良好的编程风格，可以从根本上减少bug隐患，也可以减少代码维护成本。
l 测试用例的设计和执行，可以发现一些代码逻辑上的问题，也是一道检验程序健壮性的保护屏。
在实际项目执行阶段，可能会没有框架约束，而且开发团队的工作任务繁忙，前期阶段他们根本没有太多的时间去进行代码评审。那么如何保证代码的高质量呢？我们测试团队研究并使用了一种代码静态分析工具PC-Lint，它类似于自动化地源代码评审，使得在项目前期阶段，测试人员除了写测试用例外，还可以尽早地发现程序中的bug，为开发人员提供修改意见。
PC-Lint是Gimpel Software公司开发的一个C/C++代码静态检查工具。它支持几乎所有流行的编辑环境和编译器，比如Borland C++从1.x到5.x各个版本、Borland C++ Build、GCC、VC，VC.net、Source insight等等，也支持16/32/64位的平台环境。它主要由以下文件组成：
- Lint-nt.exe Windows下的执行文件
- msg.txt 全部选项帮助说明文件
- PC-Lint.pdf 帮助文件
- config.exe 配置程序
- std.lnt 标准配置文件
- options.lnt 选项配置文件
- .\Lnt子目录下的各种开发编译环境的配置文件
由于它有可执行文件Lint-nt.exe，所以我们可以将它整合到编辑环境中，例如VC6。VC6环境下PC-lint的命令参数示例-u -iC:\lint std.lnt $(FileName)。Source insight环境下PC-lint的命令参数示例d:\lint\lint-nt.exe -u -iC:\lint std.lnt env-si %f, 如果需要Lint当前打开文件的同一目录下所有文件，可以将%f改成%d\*.cpp。
其中，std.lnt文件中可以包含其他配置文件，还可以包含各种配置选项，有点类似C的头文件，里面可以include许多其他头文件，不过PC-Lint配置文件包含其他配置文件不需要写include,直接写文件名就可以了。std.lnt内容示例如下：
// Microsoft C and Visual C++ 6.x, -si4 -sp4, lib-stl.lnt lib-w32.lnt
// Standard lint options
au-ds.lnt
co-msc60.lnt //PC-Lint提供的对VC6的告警屏蔽文件
lib-stl.lnt lib-w32.lnt //PC-Lint提供的对stl和VC6库头文件的告警屏蔽文件
options.lnt -si4 -sp4 //自定义的选项文件
env-vc6.lnt //用来设置编辑环境的配置文件
-id:\vc6\vc98\include //include目录
如果把PC-Lint集成到某个编辑环境中，那么输入的格式必须和对应环境吻合，才能保证在鼠标点击(或双击)错误消息条目时，可自动定位到对应源代码行，这类配置放置在env-xxx.lnt文件中，这些文件在PC-lint安装时，就自带的，在.\Lnt子目录下，如VC6是env-vc6.lnt，SourceInsight是env-si.lnt。我们只需找到与自己的编辑环境相匹配的env-xxx.lnt文件，然后将它写入std.lnt中即可。
源代码在编辑环境中链接通过后，我们就可以使用PC-Lint命令做静态检查了。它可以说是一种更加严格的编译器，不仅可以查出一般的语法错误，还可以检查出那些虽然合乎语法要求，但很可能是潜在的、不易发现的错误。
PC-Lint告警分为0～4级，其中0级是内部错误或致命错误，1级告警是句法错误，2级告警是警告，3级是信息，4级是可选的，4级缺省是不打开的。告警级别定义如下表，
|
C |
C++ |
Warning Level |
|
|
Syntax Errors |
1 – 199 |
1001 – 1199 |
1 |
|
Internal Errors |
200 – 299 |
|
0 |
|
Fatal Errors |
300 – 399 |
|
0 |
|
Warnings |
400 – 699 |
1400 – 1699 |
2 |
|
Informational |
700 – 899 |
1700 – 1899 |
3 |
|
Elective Notes |
900 – 999 |
1900 – 1999 |
4 |
任何事物都有两面性，PC-Lint也不例外。它也会经常有一些误报，为了消除这些误报，我们不得不使用一些PC-Lint选项来屏蔽这些告警。常用选项如下：
- -i选项
这个选项主要是用来设置include路径的
如：-iD:\VC6\VC98\Include
- -e#选项
这个选项主要是用来屏蔽告警号为#的告警
如：-e818 表示不显示告警号为818的告警
- -esym(#, 符号名)选项
这个选项主要是用来屏蔽告警号为#的某个符号的告警，
如-esym(39, std)
- -emacro(#,宏名称)选项
这个选项主要是用来屏蔽告警号为#的某个宏的告警
其中，0～2级告警都不能使用-e选项进行屏蔽，只能使用-esym，-emacro，-sem之类的选项进行屏蔽；3级告警要根据具体情况，有些可以使用-e选项进行屏蔽，有些不可以。
通过对PC-Lint告警的分析，我们总结出一些C++编写规范。
- 过分依赖C表达式中的运算符优先规则; 例如：else if (m_nSize+STEP_KEYCOUNT > m_nMaxCount), 最好能加个括号。
- 变量定义了，却没什么作用。
- 在构造函数中尽量不要分配内存，否则会有告警error 1732。
- 函数可以申明为const类型，通常都是一些没有修改成员变量的函数会有这类告警error 1762。
- 成员变量使用前没有初始化。
- 类指针成员没有释放，尤其是异常返回的时候，忘记释放指针成员，这很容易引起内存泄漏。
- 在使用指针成员时，没有判断是否为空指针。
- 设计阶段，就想好接口变量类型，减少类型转换的频率。
- 判断条件有问题，这就是逻辑错误。运用PC-lint也很难检查出来，需要开发人员特别小心。
总之，PC-lint是个简单易用的代码静态检查工具。它可以帮助开发人员，检查出语法逻辑上的错误，还能够提出程序在空间利用、运行效率上的改进点。它也可以帮助测试人员，检查源码是否符合C/C++代码编写规范，是否有语法错误，如不匹配的参数、未使用过的变量、空指针的引用等。如果测试人员水平高的话，也可以找出代码逻辑性、合理性上的问题，如：不适当的循环嵌套和分支嵌套、不允许的递归和可疑的计算等；还可以利用静态检查的结果做进一步的查错，且能为测试用例的编写提供些许的指导。