代码静态分析

在代码构建过程中使用静态分析工具有助于发现代码缺陷，并提高代码的质量。本节关注三个代码静态分析工具的使用：Findbugs、PMD和Checkstyle。这三个工具各有不同的特点，联合使用有助于减少误报错误，提高报告的准确率。

使用目的

这三个工具检查的侧重点各有不同：

工具	目的	主要检查内容
FindBugs	基于Bug Patterns概念，查找java bytecode中的潜在bug。在目前版本中，它不检查java源文件。	主要检查bytecode中的bug patterns，也允许用户自定义特定的bug patterns。
PMD	检查java源文件中的潜在问题。	主要包括： ² 空try/catch/finally/switch语句块 ² 未使用的局部变量、参数和private方法 ² 空if/while语句 ² 过于复杂的表达式，如不必要的if语句等 ² 复杂类
CheckStyle	检查java源文件是否与代码规范相符	主要包括 ² Javadoc注释 ² 命名规范 ² Headers ² Imports ² Size冲突和度量，如过长的方法 ² Whitespace ² Modifiers ² Blocks ² Coding Problems ² Class Design ² 重复代码 ² Miscellaneous Checks ² Optional Checks

本文中三个工具各自的版本分别是：FindBugs 0.85、PMD 2.0和CheckStyle 3.3。这三个工具都可以从sourceforge下载，而且它们都为Eclipse提供了相应的plugin。

用法

关于IDE以及plugin如何使用在此不做介绍，本文主要关注它们如何与ant配合使用，使这些工具成为每次构建过程中的有机组成。

FindBugs

FindBugs的运行环境可能是这三个工具之中最苛刻的了。它工作在j2se1.4.0或以后的版本中，需要至少256MB内存。它的安装非常简单，下载之后简单的解压即可。为了与ant配合使用，它提供了对应的ant task。它的使用：

1. findbugs复制到项目的classpath中，并删除将这些文件纳入开发管理中很容易在另一台机器上重建构建环境。不建议向手册中所说的仅仅将findbugs-ant.jar复制到ANT_HOME/lib下。

2. 修改build.xml：

<!-- 定义findbugs所在目录，建议直接将findbugs复制到classpath中 -->

<property name="findbugs.home" value="lib/findbugs" />

<!-- 定义findbugs任务，以及所在的jar文件 -->

<taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"

classpath="${findbugs.home }/lib/findbugs-ant.jar"/>

<target name="findbugs">

<!-- 使用，所用参数介绍见后 -->

<findbugs home="${findbugs.home}"

output="html"

outputFile="findbugs.html" >

<!-- fog.jar所依赖的classpath引用 -->

<auxClasspath refid="classpath"/>

<!-- fog.jar对应的源文件 -->

<sourcePath path="src" />

<!-- 要分析的bytecode文件 -->

<class location="bin/lib/fog.jar" />

</findbugs>

</target>

3. 运行：ant findbugs。

4. 参数说明：

属性：

- home属性，指出findbugs的安装目录

- quietErrors属性，如果为true，那么严重分析错误和丢失类信息不会出现在输出中。缺省为false。

- reportLevel属性，指明报告输出bug的级别。”low”，所有bug全部输出；”medium”（缺省），输出中级和高级bug；”high”，只输出高级bug。

- output和outputFile属性，指明输出格式和文件名。

- sort属性，如果为true（缺省），输出按类名排序。

- debug属性，是否输出findbugs的调试信息，缺省为false。在自定义bug检测器时使用进行调试。

- visitors属性，用逗号分隔的类名，指明哪些bug检测器可以运行。缺省是所有。

- omitVisitors属性，相当于visitors属性取反，指明哪些bug检测器不能运行。

- excludeFilter和includeFilter属性，指明排除和包含的过滤器（即定义它的文件名）。

- projectFile属性，与findbug gui相关，略。

- jvmargs属性，指明需要传递给jvm的参数。

- timeout属性，超时设置，以毫秒为单位。缺省是600000ms，是10分钟。

- failOnError属性，为true时，如果有findbugs运行中出错，中止构建过程。缺省为false。

- workHard属性，用于将低输出的错误率，但是运行也最慢。缺省为false。

内嵌元素：

- class元素，要分析的bytecode。

- auxClasspath元素，class元素依赖的类。

- sourcePath元素，class元素对应的源文件，它用来指出findbugs输出内容所对应的源文件信息。

- systemProperty元素，定义系统属性。

使用过滤器。过滤器用来包含或排除特殊的bug报告。这样做有助于在特定的时间段内，聚焦我们的关注点。过滤器实际是在一个xml文件定义的，它的典型格式：

<FindBugsFilter>

<!-- 所有的bug检测器都与这个类匹配 -->

<Match class="com.foobar.ClassNotToBeAnalyzed" />

<!-- bugcode为DE,UrF,SIC与这个类匹配 -->

<Match class="com.foobar.ClassWithSomeBugsMatched">

<BugCode name="DE,UrF,SIC" />

</Match>

<!-- bugcode为XYZ的匹配所有的类 -->

<Match classregex=".*" >

<BugCode name="XYZ" />

</Match>

<!-- bugcode为DC的匹配这个类的这些方法 -->

<Match class="com.foobar.AnotherClass">

<Or>

<Method name="nonOverloadedMethod" />

<Method name="frob" params="int,java.lang.String" returns="void" />

<Method name="blat" params="" returns="boolean" />

</Or>

<BugCode name="DC" />

</Match>

</FindBugsFilter>

通过task的excludeFilter和includeFilter属性，可以在findbugs的输出报告中包含或排除匹配它们。具体每个bug检测器的bugcode，可以在plugin/coreplugin.jar/messages.xml中找到。其中messages.xml中的bugcode实际是findbugs.xml（也在coreplugin.jar中）每个Detector元素的reports属性的第一个缩写。如：reports属性为VO_VOLATILE_REFERENCE_TO_ARRAY，对应的bugcode=”VO”。

从使用来看，findbug还是相当简单的。但要用好，使用者还需要了解bug patterns的相关知识，如覆盖equals的同时需要覆盖hashcode。而且，findbugs也允许我们自定义bug patterns，使之方便的扩展。关于这部分内容，请参见developerworks上的文章《FindBugs，第 2 部分：编写自定义检测器》。

PMD

PMD的运行环境是j2se1.3或以后版本，安装过程同样也是解压即可。对应ant task的使用：

1. 把lib中所有的jar复制到项目的classpath中。

2. 将pmd-2.0.jar中的rulesets解压到指定目录，这里面定义了分析所需要的规则集合。

3. 修改build.xml文件。在这一版本中，提供了2个ant task。一个是pmd使用规则集合进行分析；另一个是检查代码中Copy & Paste代码。这2个任务对应的ant task使用：

PMD任务：

<target name="pmd">

<!-- 定义任务和任务所属类所在的classpath引用 -->

<taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask"

classpathref="classpath"/>

<!-- 检查使用的规则文件 -->

<pmd rulesetfiles="junit_lib/rulesets/imports.xml">

<!-- 输出格式和文件名 -->

<formatter type="html" toFile="pmd_report.html"/>

<!-- pmd所需要依赖包的classpath引用 -->

<classpath refid="classpath"/>

<!-- 要检查的项目源文件根目录 -->

<fileset dir="src">

<include name="**/*.java"/>

</fileset>

</pmd>

</target>

CPD任务：

<target name="cpd">

<!-- 定义任务和任务所属类所在的classpath -->

<taskdef name="cpd" classname="net.sourceforge.pmd.cpd.CPDTask"

classpathref="classpath"/>

<!-- 指明输出文件和判断属于copy & paste的标准 -->

<cpd minimumTokenCount="100" outputFile="cpd.txtl">

<!-- 要检查的项目源文件根目录 -->

<fileset dir="src">

<include name="**/*.java"/>

</fileset>

</cpd>

</target>

4. 运行ant pmd和ant cpd即可。

5. 参数说明：

- formatter，指明输出格式和文件。

- rulesetfiles，指明分析所需的规则文件，不同文件使用逗号分隔。

- failonerror，pmd执行出错是否中止构建过程。

- failOnRuleViolation，如果与规则冲突，是否中止构建过程。

- classpath，pmd所需的classpath。

- printToConsole，在发现问题时是否打印到ant log或控制台。

- shortFilenames，在输出报告中是否使用短文件名。

- targetjdk13，是否把目标定为jdk13，如不能使用assert。

- failuresPropertyName，在任务结束时，插入违反规则的号码

- encoding，读源文件时所采用的编码，如utf-8。

关于规则集合的说明，以及如何自定义规则请参见pmd的文档，文档中已说得相当清楚。

CheckStyle

使用ant task：

1. 复制checkstyle-all-3.3.jar到项目的classpath中。

2. 修改build.xml文件：

<taskdef resource="checkstyletask.properties"

classpath="${weblib.dir}/checkstyle-all-3.3.jar"/>

<target name="checkstyle" depends="init">

<!-- 指明checkstyle的分析所需的规则文件 -->

<checkstyle config="checkstyle33.xml">

<!-- 要检查的文件 -->

<fileset dir="${src.code}" includes="**/*.java"/>

<!-- 指明输出格式和文件名 -->

<formatter type="xml" toFile="report.xml"/>

</checkstyle>

<!-- 将xml文件转换成html文件 -->

<style in="report.xml" out="report.html" style="checkstyle-frames"/>

</target>

3. 运行ant checkstyle即可。

checkstyle的规则文件，即项目的代码规范，建议不要手工书写。可以使用checkstyle plug in在Eclipse配置后再导出。Checkstyle提供了缺省的xslt，用来进行xml的格式转换。它们都放在contrib目录中。Checkstyle同样也提供了自定义的check，但与PMD相比，书写要复杂。详细情况请参见checkstyle的文档。

检查表

- 为每个工具建立自己的目录和classpath变量。由于这些工具大多都使用了相同的开源软件，很容易会因为使用相同软件包的不同版本而相互干扰。这种问题非常隐蔽，在这种问题上花费时间和精力是非常不值得的。通过建立不同的目录和classpath，然后在对应的ant task中引用各自的classpath，可以有效的避免它。

- 将这些工具纳入项目的配置管理库中。这样可以方便而迅速的在另一台机器上重建构建环境，有效的保证了项目组中统一的构建环境。

- 重视这些输出，但是不要因为输出而困扰。它们仅仅是工具，要学会正确的对待它们。

- 三个工具都提供了自定义规则的接口，相比而言pmd书写最简单，findbugs功能最强。它们涉及AST（抽象语法树）和byte code相关的知识。