选择一个编码规则检查器
我们的选择标准包括产品使用特点，但不是特点的细节（规则选择，规则执行，可量测性）。我们通过以下途径来建立这些标准：以前的使用编码规则检查器的经验，项目开发部门的反馈，产品评估报告。
能很灵活地修改规则：大多数编码规则检查器包括预执行的规格。拥有内含的规则可以减少规则执行的工作量。但是这些规则通常并不完全符合我们的编码风格。而且，因为大多规则中是简单地执行，不实的报错是常见的事，因而使得结果不具可靠性。我们需要一个简单的方法来自定义规则以排除异常情况，添加新的规则或者修改已存在的规则。类似于LINT的工具可以检查一些编码规则项，但缺少规则自定义的特点。尽管有些检查器也能为规则自定义提供参数修改，但我需要更多的灵活性来修改详细规则。
能在不同的级别上报告编码规则的遵守程度： 许多编码规则检查器支持文件级别的报告。然而，出于管理目的，文件包级和项目级的报告成为管理者们所希望有的。比如，要项目经理经常希望按文件包或项目来浏览编码规则违规以编码规则违规的趋势和对编码规则违规校正的优先级别，特别是在项目工期快要到了的时候。
能与开发环境相集成：许多规则违规能被很容易地校正。比如，像“使用TAB而不是空格进行缩进”之类的违规可以通过简单地用TAB替换空格就可以校正。在这样的情形中，有一个可以直接访问违规源代码（通过与开发环境紧密集成）的编码规则检查器，就可以非常有效地减少校正所需要的时间。
另外，当一个工程向前推进的时候，它将所含更多的文件和更的"include/directive"设定。如果检查器不在IDE内运行，那么检查器就要通过导入或同步IDE项目文件（如MAKEFILES，DSP/DSW文件等）来创建工程文件。
能为C/C++创建统一的规则：我们的主要的编程语言，C和C++，有一个相似的结构（除了C++具有更多的基于对象的和类属性编程）。在两种语言上为相同的项维护两种不同的规则将需要额外的资源。
能够识别语言变量：相比C，C++的历史比较短。编译器提供商们在ISO C/C++发布以前产出了他们自己人的C++编译器，并且研究显示，许多C++的实际应用并不能很好地支持C++ ISO标准(
http://www.ddj.com/184405483)。因为编码规则检查器经常分析源代码，所以能识别语言变量就显得非常重要了。
能检查未经预编译的头文件：一些编码规则检查器缺少对头文件的直接检查，取而代之的是，在头文件中的代码违规，是通过检查在预编译执行的文件中的头文件进行间接地报告。在这种情况下，一些代码违规被忽略了，如在头文件中与预处理程序指令和注释相关代码违规，这里通常包含一些被其他开发人员使用的重要信息。所以，直接对头文件的检查是一个我们所希望的功能。
使用检查器的经验
应用一个编码规则检查器可以减少在应用中的编码标准违规。然而，侦测和消除的违规数量取决于目标工程的特点和编码规则的质量。我们发现每个工程都有其相似的整体倾向，但同时又有影响编码规则检查的不同细节。因些，得出来的结果应该被看成是一个趋势而不是一个确定的样式。
直接的利益是指减少违规数量是如何提高代码质量的。
非直接利益是指其他不曾预料到的带给开发人员的好处。
图2显示了编码违规数量的总体趋势。为消除规则不断发展带来的影响，我们使用最新的规则来进行所有的检查。在一个从10月4日到1月5日间相对稳定的违规数量之后，在2月5日有一个大约1/8的违规减少。从2月5日到3月5日间，有一个不希望有的违规增加，但这是可以接受的，因为目标项目仍在继续向前推进。
图2：总的违规数量/每千行代码
图3显示了违规校正对只对当前模块有影响的违规数量。从采用检查器之日起，违规数量减少了6.6个百分比。这个数量没有包括注释规则--这通常不会有大的变化影响但确实是需要重要的进行变更的工作。
图3：小变化违规数量/每千行代码
图4显示了校正不只影响当前模块的违规数量。从引入检查器以来，违规减少了19.6个百分点
图4：有大的改变影响的违规的数量/每千行代码
代码规则检查给我们带来的一个意外收获，就是它对开发人员的教育和知识能力提升。新的开发人员，甚至是一些有经验的开发人员，在开始的时候不大理解一些编码规则项的意义和重要性。比如，编码规则项“最好进行初始化而不是分配”是被认为是一个有效的方法来初始化一个构造函数中的成员变量（可参考：《Effective C++》，作者：Scott Meyers，Addison-Wesley，1992）。一些开发人员不理解为什么在一个构造函数的列表中对成员进行初始化要比在构造函数体中对成员分配初始化值要更好。他们在查看检查器的检查结果时讨论这些问题。这就最终帮助开发人员完全理解了C++的特点，并且也展示了编码规则检查是如何帮助开发人员，使他们从犯错中进行学习成长的。
另一个间接带来的好处就是去除了那些不切实际的编码规则项。当我们应用编码规则一项目MOBILE中去的时候，我们发现大多数开发人员并不遵守这条规则即“每行不要80格”，这条规则的产生是因为有些老的开发环境是80格显示。我们检查了我们的开发环境并得出结论：在我们的条件下，这种有限制的开发环境很少使用，我们建议一行使用更长的格。”所有我们将一行的格数限制从80格改到150格。这种编码规则修改也可以提高开发人员对遵守编码规则的接受程度。
学到了什么
直到最近以前，我们的检查还只是QA部门在工程级别上检查是否遵守编码规则。这对于追踪缺陷倾向和维护一套规则是有效果的。但是会有一些缺点。
首先，报告的违规来源并不总是开发环境中的那段代码。开发人员通常并不在一个集中的源码库中操作，他们在自己的区域进行书写和修改代码，然后复制或check-in源码到集中的代码库中。如果开发源码和QA测试的代码不一样，那么开发人员要识别和修改报告违规的来源就比较困难了。
再者，开发人员希望立即能够验证到对于违规的校正已经消除了存在的问题。
基于这些原因，我们决定要让开发人员和QA一样可以运行编码规则检查工具。
那些不认真遵守规则的开发人员会产生很多有违规的代码，并且也通常不会去校正这些代码违规。这是尤其会产生与识别或设计相关的违规问题，这样会使得在以后的开发阶段来校正这些错误非常困难，因为那时进行这样的校正会有一个较大的，整个工程范围的影响。所以我们推荐将编码规则检查从早期的编码阶段就开始，这样违规代码就能在传出模块之前就得到校正。
为什么我们以前的工具没能在编码规则检查上发挥效应的也是因为在整个组织级别上缺乏对规则的维护。
在一套初始规则建立之后，规则应该得到不断的修改定义，因为某些规则也许不适用于特定的项目，开发风格会根据开发的领域不同而会有改变。一套规则应在项目不断往前推进的过程中根据项目的具体操作而进行不断的维护更新。
自动的编码规则检查是对代码走查的一个补充。在我们的开发过程中，代码走查是强制的，因为这样可以有效地找出开发人员的逻辑错误和失误。然而，开发人员也会因为工期太紧的压力跳过代码走查。根据我们的经验和研究显示，一些开发人员很容易被一些编码风格问题弄得很头痛，并在代码走查的过程中花很多工夫到这个上面（参见：D. Kelly和T. Shepard编写的"Qualitative Observations from Software Code Inspection Experiments"一书; CASCON, 2002），从而，一些开发人员将代码走查看作是一件耗时却收效甚微的工作，并不跳过这一步。这种情形可以通过在代码走查之前使用自动化的代码规则检查来消除代码违规的方法来进行避免。这样的话，在代码走查的时候我们就能将精力集中在发现逻辑错误和严重错误上来。而且，自动化的检查只能涉及到我们编码规则项中的大约50%（一些规则项用自动化工具具体执行起来非常复杂），所以代码走查需要用来检查剩余的规则项。
小结
我们应用C++TEST到了我们几个项目中并在每个项目中都取得了很好代码质量提高效果。我们准备将其应用到更多的项目中去，用其分析代码的质量。
在国内，深圳市华唐软件技术有限公司是Parasoft的核心合作伙伴与代理商，C++TEST在国内也应用得非常好，深受好评，有关产品详细情况可到华唐的网站：
http://www.superst.com.cn 进行参考，也可以向其索取详细产品资料或申请试用：
marketing@superst.com.cn
