静态分析工具及使用总结（二）CheckStyle

这里主要介绍三种开源的工具，PMD、CheckStyle和FindBugs，着重是在Ant里的调用，据说商业软件JTest也是著名的代码分析工具，哈哈，要花钱的没有用过。

 

Checkstyle （http://checkstyle.sourceforge.net/）版本4.2

简介: Checkstyle 是一个开发工具，可以帮助程序员遵循代码规范的编写代码，

它自动的处理这些让人厌烦但却十分重要的工作，它具有高可配置性，支持绝大多数的代码规范，比如Sun推荐的代码约定（http://java.sun.com/docs/codeconv/）和其它众所周知的约定，Checkstyle可以检查代码的很多方面，从传统观点看，它主要是用来检查代码层面的，自从第三版以后，它的内部架构作了重大改变，很多其它意图的检测加了进来，现在Checkstyle可以检查像类设计的问题，重复代码，如锁的双重检查的bug模式。

 

配置: Checkstyle 配置插件式的modules应用在java代码上，modules是一个以

Checker module 为根的树形结构，根下的层次包括：

FileSetChecks 取一组输入文件，并提示错误信息

Filters 过滤审核事件，包括错误信息

AuditListeners 报告接受的事件

许多的检查是TreeWalker FileSetChecks module下的submodules，TreeWalker单独的转换每个java源文件成抽象的语法树，然后根据这些submodules处理得到结果，这些submodules会轮流的查看树的某个方面。Checkstyle从一个XML文档中获得配置，XML的元素指定了module的层次配置和属性，如果用命令行的方式调用Checkstyle，需要提供一个包含配置文档的文件，在Ant中调用也是。Checkstyle发布版本中的doc目录下包含一个示例配置文件sun_checks.xml，这个文件配置Checkstyle检查代码是否符合Sun的代码约定。

 

    如：

<module name="Checker">
    <module name="PackageHtml"/>
    <module name="TreeWalker">
        <module name="AvoidStarImport"/>
        <module name="ConstantName"/>
        <module name="EmptyBlock"/>
    </module>
</module>

在这个配置里，根Check module包括PackageHtml（检查所有的包都必须包含包说明）和TreeWalker（检查java源代码方面的），以上Checkstyle通过module的名字来装载一个类，还有其它的方式来装载module类，比如指定带包全名的类，如<module name="com.puppycrawl.tools.checkstyle.TreeWalker">。

每个module都会有一些默认的属性，如果默认值不符合你的要求，你可以指定它，更详细的参考请参阅文档。

 

用法： 可以在命令行下执行Checkstyle，如：

    java com.puppycrawl.tools.checkstyle.Main -c docs/sun_checks.xml -r src/

表示对src下的所有java源文件进行检查，而配置文件是用的sun_checks.xml

我主要介绍在Ant中的调用

      下面列出主要的Ant配置信息：

 < path  id ="checkstyle.path" >     
     < fileset  dir ="${lib.dir}/checkstyle-4.2" > 
         < include  name ="**/*.jar"   /> 
     </ fileset > 
 </ path > 
 
 < target  name ="checkstyle" > 
     < taskdef  resource ="checkstyletask.properties"  classpathref ="checkstyle.path" /> 
 < checkstyle  config ="${lib.dir}/checkstyle-4.2/sun_checks.xml" 
        failureProperty ="checkstyle.failure" 
        failOnViolation ="false" > 
         <!--  uncomment to print to console as well  --> 
         <!-- formatter type="plain"/ --> 
         < formatter  type ="xml"  tofile ="d:checkstyle.xml" /> 
         < fileset  dir ="${src.dir}" > 
             < include  name ="**/*.java" /> 
         </ fileset > 
     </ checkstyle > 
     < style  in ="d:checkstyle.xml"  out ="d:checkstyle.html"  
style ="${lib.dir}/checkstyle-4.2/contrib/checkstyle-noframes.xsl" /> 
 </ target > 

自带检查介绍: Checkstyle 自带了很多的检查，其网站上有按功能划分的参考，分为标准

检查和可选检查，可选检查提供了J2EE方面的检查，如EJB和LocalHomeInterface等的一些检查。标准检查涵盖以下方面：

Javadoc Comments 和javadoc注释有关的检查，如检查类、方法等的javadoc注释

Naming Conventions 命名规范的检查，可以按照正则表达式去检查类、方法等的命名

Headers 检查文件是否以某些行开头，如“Copyright All rights reserved”

Imports 和import有关的检查，如检查是否有使用“*”的import

Size Violations 代码块大小的检查，如类、方法等的代码行数

Whitespace 空白处的检查，如检查是否有tab符合（’ ’）

Modifiers 修饰符号的检查，如修饰符号的顺序

Block Checks 块的检查，如检查是否有空块或不必要、无效的块等

Coding 编码相关的一系列检查，如空的条件，私有变量如果没有改变值应该声明成

Final ，代码中的魔法数字，Switch缺少default等

Class Design 类设计的有关检查，如只有私有构造函数的类应该声明为final

Duplicate Code 检查重复代码

Metrics 度量方面的检查，如布尔表达式的复杂，类依赖的复杂，算法的复杂

Miscellaneous 其它混杂的检查，如文件是否以新行结尾，TODO的注释，没有注释main

方法

 

扩展Checkstyle: Checkstyle 有三种方式进行扩展，编写checks、编写filters和编写

listeners 。

 

编写checks

Checkstyle 有两种checks，在你开始之前，你要想好想要实现哪种检查，Checkstyle的功能是由可嵌入它的modules进行扩展的，modules中也可以包含modules，它们可以构成一个树形结构，直接访问Checkstyle内核的顶级module扩展了FileSetCheck接口，实际上也是一个module，它构成树形结构的根，这很好理解，它们读入一组输入文件，并且引发错误信息。Checkstyle提供了一些FileSetCheck的扩展，比如说TreeWalker，TreeWalker分别转换java源文件成一个抽象语法树，根据每个submodules去处理结果，这些submodules会轮流检查树的某些方面。

 

每个java程序是由文件组织的，文件又由一些特定的结构构成，你必须对基本的java语法很了解，Checkstyle是使用ANTLR（http://www.antlr.org/）去解析java代码的，这个工具可以把java源文件中的字符流转换成一个树形的结构。Checkstyle提供了一个GUI的工具，它可以把java源文件转换成树形结构。

 

当ASTs（抽象语法树）工作时，我们可以很简单的通过一个方法去确定AST的节点，但这不是编写插件的方法，这些类不会具有检查功能，而TreeWalker包括遵循Check接口的一系列对象，它是一个抽象类并且提供了一些有用的方法，它提供一些以AST做参数的方法，这些方法可以对AST进行检查操作，如visitToken()。单独的Checks不能在AST里移动，而是TreeWalker会从AST的根节点到叶节点进行递归，并且调用检查方法，移动采用的是深度优先算法。

当一个检查方法调用时，TreeWalker会调用beginTree()使Checks可以做一些初始化的操作，然后从根节点到叶节点的递归过程中，会调用visitToken()，当一个节点处理完，TreeWalker从这个节点返回前会调用leaveToken()，离开根的时候会调用finishTree()。

 

    编写好后，我们可以通过下面方式集成：

<module name="Checker">
  <module name="TreeWalker">
    <!-- your Check goes here -->
    <module name="com.mycompany.checks.MethodLimitCheck">
      <property name="max" value="45"/>
    </module>
  </module>
</module>

这种方式编写的Checks有两个缺陷，不能确定具体的表达式的类型和不能访问其它文件的内容。另一种方式是编写FileSetChecks，编写FileSetChecks更简单，只要继承

AbstractFileSetCheck 和实现process(File[] files)方法，这种Checks没有限制，所以我们甚至可以做，找一个全局的代码问题，如未使用的public方法，重复的代码，或者像TreeWalker检查java那样检查C#代码。

 

编写filters

当Checks通过监听器生成报告时，审核事件上有一组的过滤器，Filter接口和类FilterSet通过一组过滤器支持审核事件的过滤。我们编写Filters可以选择实现接口Filter或继承类FilterSet。

 

编写listeners

一个Checkstyle listener在一个Checker检查文件的期间会监视进度，一个Checker在重大事件发生时会通知其上的listeners，比如检查开始或记录错误，listeners会适当的响应，一个Checker能附加任意数量的listeners，一次审核总会加上发布版本里的listeners以报告事件，如DefaultLogger或XMLLogger，DefaultLogger在事件发生时会输出简单的文本，而XMLLogger会输入XML文档。对一般用户来说，这两个我们已经够用了，但如果你有别的需要，那你就需要定制你的listener了，比如说，你想在Checkstyle运行时，得到详细的进度信息，或者过滤错误事件。

 

一个listener必须实现AuditListener接口，在一次审核过程中，Checker会通知其上的AuditListener六种事件，审核开始/结束，过滤开始/结束，记录错误/异常。有事件发生需要通知listener时的事件称为AuditEvent，一个文件相关的事件包含文件名，记录错误的事件包含错误信息，严重级别，信息产生的源比如说是一个Checker，和文件行数、和错误有关的列数，异常通知的事件包含错误的AuditEvent和异常细节。

 

定制listener时需实现AuditListener，如果有可配置的属性，就必须继承AutomaticBean。Checkstyle的文档里提供了两个listeners的例子，一个是使用当前的Logger记录信息CommonLoggingListener，一个是用邮件发送审核报告MailLogger。

 

 

参考文档：

Checkstyle 官方文档（http://checkstyle.sourceforge.net/）

代码静态分析（http://blog.donews.com/foxgem/archive/2005/04/23/347444.aspx）