前言

Checkstyle是非常优秀的代码规范检查软件，可以大幅的提高代码质量， 当项目的开发人员比较多时，用它来统一代码风格是很有必要的

本文的写作，是由于公司的质量管理部门对代码格式进行了要求

Checksytle 是一款代码格式检查工具它可以根据设置好的编码规则来检查代码 比如符合规范的变量命名，良好的程序风格等等如果你的项目经理开会时说，我希望我们写出来的代码就象一个人写的！ 时，用Checkstyle绝对是正确选择:)

提醒：想修改代码格式，请使用Jalopy. 它和Checkstyle配合使用非常合适

Checkstyle的配置性极强，你可以只检查一种规则，也可以检查三十，四十种规则可以使用Checkstyle自带的规则， 也可以自己增加检查规则（这点跟Ant自定义target比较象）

支持几乎所有主流IDE，包括 Eclipse , IntelliJ, NetBeans, JBuilder 等11种

让您在几分钟之内了解Checkstyle的大致用法适合赶时间的朋友假设您已经安装好了Checkstyle的Eclipse插件

首先，我们建立一个eclipse的项目：test_checkstyle包含一个源文件夹：src，一个目标生成文件夹

在项目中开启Checkstyle: 打开该project的属性，点中左侧的Checkclipse后，将"Enable Checkstyle"前面打上勾

建立一个测试用的Class: 比如SomeClassToBeChecked，内容如下：

* Copyright (c) 2001-2008 Beijing BidLink Info-Tech Co., Ltd.

* $Id: learn_in_5_min.xml,v 1.3 2008/03/03 03:43:44 Administrator Exp $

用Checkstyle检查它：右键点项目名，选择"Build Project"，会把src文件夹进行编译，把class文件放到eclpise_build中 结束之后，我们可以看到：代码第10行处，有一个叹号，把鼠标移上去就会出现 提示

定制检查：Checkstyle没有图形化的定制器，所以需要手工修改配置文件比如，我们的代码需要符合下列规则：

长度方面：文件长度不超过1500行，每行不超过120个字，方法不超过60行

命名方面：类名不能小写开头，方法名不能大写开头，常量不能有小写字母

那么，我们的检查配置文件（如命名成 my_check.xml ） 应该是这样的：

    "-//Puppy Crawl//DTD Check Configuration 1.2//EN"

        <module >

            <property value="1500"/>

        <module >

                       <property value="120"/>

        <module >

            <property value="METHOD_DEF"/>

            <property value="60"/>

命名方面的检查，它们都使用了Checkstyle默认的规则

类名(class 或interface) 的检查

        <module />

        <module />

        <module />

        <module >

            <property value="3"/>

        </module>           

可以看出，想增加一个检查，就是增加一个<module/>结点具体的结点内容在后面的文档都会写明

让Checkstyle使用指定的检查配置文件：打开项目属性，在Checkclipse中的"Checkstyle Configuration File" 一栏中 选定我们的配置文件，然后确定

然后重新编译项目，就会发现，Checkstyle的规则如我们所愿：只检查我们在文件中配置的几项并且它们是以"Error"级别进行提示，而不是默认检查时出现的"Warning"级别 比如，我们把一个方法中，增加4层嵌套（共5个if），并将方法名大写

可以看到，出现了两个Error: 方法名的"Name xx must match pattern..." 和if嵌套的"Nested if-else depth is 4..." 把它们都改过来，程序就好了

代码的修正：依照上面的例子，把方法名小写，if循环嵌套3层，然后重新编译，OK

    "-//Puppy Crawl//DTD Check Configuration 1.2//EN"

<module >

    <!-- 重复代码的检查，超过8行就认为重复，UTF-8格式

       本检查一定要放在"TreeWalker"节点前，否则在

中会无法使用(在ant下可以)

    <module >

       <property value="8" />

       <property value="UTF-8" />

    <module >

       <!--不希望有任何 import a.b.*; 这样的语句 -->

       <module />

           以下几种import是没用/没意义的：

           3.import java.lang的

与该类在同一个package的

       <module />

       <!--PackageName检查包名设置成只能小写 -->

       <module >

           <property value="^[a-z]+(\.[a-z][a-z0-9]*)*$" />

       <!-- javadoc的检查 -->

       <!-- 检查所有的interface和class -->

       <module />

       <!-- 检查所有方法的javadoc，可以不声明RuntimeException -->

       <module >

           <property value="true" />

       <!-- 检查某个变量的javadoc -->

       <module />

       <!-- 命名方面的检查，它们都使用了Sun官方定的规则 -->

       <!-- 类名(class 或interface) 的检查 -->

       <module />

       <module />

       <module />

       <module " />

       <module />

<!-- 长度方面的检查 -->

       <!-- 文件长度不超过1500行 -->

       <module >

           <property value="1500" />

       <!-- 每行不超过120个字-->

       <module >

           <property value="120" />

       <!-- 方法不超过30行 -->

       <module >

           <property value="METHOD_DEF" />

           <property value="30" />

       <!-- 方法的参数个数不超过3个 -->

       <module >

           <property value="METHOD_DEF" />

           <property value="3" />

       <module />

       <!-- 不能出现空白区域 -->

       <module />

       <!-- 所有区域都要使用大括号 -->

       <module />

       <module >

<property value="true" />

       <!-- 编码方面的检查 -->

       <!-- 不许出现空语句 -->

       <module />

       <!-- 每个类都实现了equals()和hashCode() -->

       <module />

       <!-- 不许使用switch -->

       <module >

           <property value="LITERAL_SWITCH" />

       <module />

       <!-- 绝对不能容忍魔法数 -->

       <module />

       <!-- 循环控制变量不能被修改 -->

       <module />

       <!-- 多余的throw -->

       <module />

       <!-- 不许使用未被简化的条件表达式 -->

       <module />

       <!-- 不许使用未被简化的布尔返回值 -->

       <module />

       <!-- String的比较不能用!= 和 == -->

       <module />

       <!-- if最多嵌套3层 -->

       <module >

           <property value="3" />

       <!-- try最多被嵌套1层 -->

       <module />

       <!-- clone方法必须调用了super.clone() -->

       <module />

       <!-- finalize 必须调用了super.finalize() -->

       <module />

       <!-- 不能catch java.lang.Exception -->

       <module >

           <property value="java.lang.Exception" />

       <!-- JUnitTestCase 的核心方法存在 -->

       <module />

       <!-- 一个方法中最多有3个return -->

       <module >

           <property value="3" />

       <!-- 不许对方法的参数赋值 -->

       <module />

       <!-- 不许有同样内容的String -->

       <module />

<!-- 同一行不能有多个声明 -->

       <module />

       <!-- 布尔表达式的复杂度，不超过3 -->

       <module />

       <!-- 类数据的抽象耦合，不超过7 -->

       <module />

       <!-- 类的分散复杂度，不超过20 -->

       <module />

       <!-- 函数的分支复杂度，不超过10 -->

       <module />

       <!-- NPath复杂度，不超过200 -->

       <module />

       <!-- 禁止使用System.out.println -->

       <module >

           <property value="System\.out\.println" />

           <property value="true" />

       <!-- 不许使用与代码同行的注释 -->

       <module />

    <module />

本节看起来比较烦冗，建议使用哪些东东，就看哪个小节就象字典那样用

我挑的是看起来比较常用的检查一些另外的，比如空格的约定，J2EE，EJB的检查，没有包括在这里有需要的朋友请看官方文档

除非特别说明，否则检查代码的位置都要放在 TreeWalker 这个结点下面

Checkstyle中的各种检查的增加，都是以增加配置文件的内容来实现的比如想检查方法的长度，就需要在<module >节点下增加：

<module >

    <property value="METHOD_DEF"/>

    <property value="60"/>

</module>

如果没有特殊说明，一般是增加在<module >结点下

如果一个module节点的属性可以有多个值备选，那么这些值之间一般用","连接比如"tokens = LITERAL_STRING, LITERAL_INT"

是否需要我按照表示的形式来说明这些属性？也就是按照官方文档的格式？

检查所有的类和接口：

<module />               

<module >

       <property value="public"/>

       <property value="CLASS_DEF"/>

</module>

其中的"scope"属性指定了检查可见的范围，也就是说，如果是"private"，那么就可以见"private, protected, public"三种， 如果赋值为"protected"那么就只检查"protected,public"两种，如果赋值为"public"，就只检查"public"的类或接口默认是"private"

"tokens"属性指定了是检查类还是接口还是都检查默认是都检查可选的值是"CLASS_DEF"（检查类）和"INTERFACE_DEF"（检查接口）

<module />

<module >                    

       <property value="public"/>

</module>

其中的"scope"属性指定了检查可见的范围，也就是说，如果是"private"，那么就可以见"private, protected, public"三种， 如果赋值为"protected"那么就只检查"protected,public"两种，如果赋值为"public"，就只检查"public"的类或接口默认是"private"

如果被检查的方法是某个interface方法的实现，那么该方法的javadoc是：

/**

public void someMethod(){

}

也就是说，不用把接口的javadoc COPY过来，一样可以通过本检查（也一样能生成正确的javadoc）

比如，这样的参数说明会被检查认为是没有：

/**

public void someMethod(String somePara){

...

因为它没有对该参数的说明，应该加上如：

/**

*/                                                   

public void someMethod(String somePara){

...

<module />

这里可以对java中的各种命名进行检查，比如方法名，变量名，常量名等等

由于相互之间很类似，所以放在一个表中说明这些检查使用的<module> 的"name"属性见下表， 它们具有相同的"format"属性，需要赋予正则表达式，默认值已经被设置好了，是与相同的 如所示

ConstantName

^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$

LocalFinalVariableName

^[a-z][a-zA-Z0-9]*$

LocalVariableName

^[a-z][a-zA-Z0-9]*$

PackageName

^[a-z]+(\.[a-zA-Z_][a-zA-Z0-9_]*)*$

StaticVariableName

^[a-z][a-zA-Z0-9]*$

TypeName

^[A-Z][a-zA-Z0-9]*$

PackageName检查的format默认值是允许大写的包名的，建议设置成只能小写，如：

<module >

        value="^[a-z]+(\.[a-z][a-z0-9]*)*$"/>

</module>

TypeName的检查是可以通过修改"tokens"属性来指定检查Class还是Interface，默认是两者都检查如果只想检查Interface，可以这样：

<module >

              value="INTERFACE_DEF"/>

</module>                   

其中，tokens属性的值是：CLASS_DEF 和 INTERFACE_DEF.

Header

检查文件头区域是否包含指定的内容可以在headerFile属性中指定一个外部文件的位置，该文件保存了文件头信息也可以使用另外一种 方法：将文件头信息直接写在 header属性中这样就可以不用外部文件

属性 ignoreLines指定了头文件中可以不被检查的行数这个属性对于包含版权日期信息的文件头很有用比如下面的文件头：

/*

* Copyright (c) 2001-2008 Some Company Co., Ltd.

* $Id: checks.xml,v 1.8 2008/03/03 03:37:19 Administrator Exp $

其中第2,6行包含的日期信息会发生变化所以在检查时，最好通过设置 ignoreLines 属性把这两行忽略掉如：

<module >

    <property value="2, 6"/>

</module>

想严格对文件头进行检查，请把文件头定义在一个外部文件中，如：java_header_file.txt 然后使用"headerFile"属性：

<module >

    <property value="java_header_file.txt"/>

    <property value="2, 6"/>

</module>

AvoidStarImport

如果不希望有任何 import a.b.*; 这样的语句，请在配置文件中，增加：

<module />

<module >

   <property value="a.b.c,c.d"/>

没有被用到

重复的

进行检查：

<module />

             <property value="1500"/>

       </module>            

           <property value="120"/>

       </module>            

使用"max"属性可以设置最多的行数，默认150，"countEmpty"是否对空白或"//"注释行记数，默认是"true"，"tokens"可以指定 检查的是一般方法还是构造方法，默认都检查，可用的值是"METHOD_DEF, CTOR_DEF"

       <module >

          <property value="METHOD_DEF"/>

          <property value="30"/>

"max"属性可以设置最多的参数个数，默认7，"tokens"属性指定检查的是一般方法还是构造方法，默认都检查可用的值是"METHOD_DEF, CTOR_DEF"

<module >

   <property value="METHOD_DEF"/>

</module>

本检查约定方法名与左边圆括号之间不许出现空格例如，下列的代码格式是错误的，在方法名"wrongStyleMethod"后面紧跟的是个空格，而不是"()"：

...

public void wrongStyleMethod (){

...

方法名与圆括号不是一行默认也是不允许的，如：

...

public void wrongStyleMethod

                     (String para1, String para2){

...

<module />                

不允许左圆括号右边有空格，也不允许与右圆括号左边有空格例如下面的代码会报错，

...

public void wrongStyleMethod( String para1, String para2 ){

...

把对应的空格去掉才是正确的：

...

public void correctStyleMethod(String para1, String para2){

...

这样检查：

<module />

默认检查范围：构造函数的调用，方法的调用，左，右圆括号，父类构造函数的调用

在类型转换时，不允许左圆括号右边有空格，也不允许与右圆括号左边有空格例如下面的代码就会报错：

Object myObject = ( Object )other;

正确的应该是：

Object myObject = (Object)other;

使用本检查：

<module />

代码中不允许使用"tab"键('\t') 因为在不同的编辑器下有的tab占8个空格（如windows记事本），有的占4个（如当前大多数IDE）

使用本检查：

<module />

使用本检查前一定要先用代码格式化工具把"tab"转换成空格否则满屏幕的"Error"会吓人一跳:)

检查某些特定符号后是否有空格如果没有，就报错

tokens

被检查的范围

COMMA, SEMI, TYPECAST

<module >

       <property value="COMMA"/>

</module>

每个关键字都有正确的出现顺序比如 public static final XXX 是对一个常量的声明如果使用 static public final 就是错误的 这样：

<module />              

"tokens"属性定义了可以被检查的范围，包括："METHOD_DEF,VARIABLE_DEF,ANNOTATION_FIELD_DEF"默认都检查，

<module />

如果只想对一般方法做检查，这样：

<module >

    <property value="METHOD_DEF"/>

</module>

只要是{} 包含起来的，都是区域比如if , else, catch 后面紧跟的，都是区域可以对它们进行检查默认是检查所有区域：

<module />

比如，只有一条语句的 if ，对于大括号是可用可不用的也就是说，

and

}

它们是都可以通过编译的 但是良好的代码规范，都推荐使用后者的风格所以，想对此进行检查，请在配置文件中，加上：

<module >

    <property value="LITERAL_IF, LITERAL_ELSE"/>

</module>

其中"tokens"属性指定了被检查的区域，它的值可以是："LITERAL_DO, LITERAL_ELSE, LITERAL_IF, LITERAL_FOR, LITERAL_WHILE"， 默认值是全部这些值个人建议使用默认的配置：

<module />

比如，这样的代码是可以通过编译，但是风格很差的：

public void guessTheOutput()

{

    System.out.println("value = " + whichIsWhich);

}

因为它增加了一对很不必要的括号对它进行检查可以这样：

<module >

       <property value="true"/>

</module>

其中"allowInSwitchCase"属性指定了在switch区域中是否允许不必要的括号默认值是"false"

或者直接：

<module />

编码的习惯检查

如果一个数组定义的右括号 与最后一个元素不在同一行，就需要有一个逗号比如：

int[] a = new int[]

{

我对这种编程风格貌似没见过如果希望检查数组的最后一个元素后面是有逗号的，这样：

<module />

据说每个元素后面都带个逗号，有利于重新安排元素的各个顺序仁者见仁，智者见智了：）

也就是三目运算符" ? :" 有的内联条件让代码难以理解，比如：

String b = (a==null || a.length<1) ? null : a.substring(1);

想避免它出现，可以进行检查：

<module />

使用了本检查，也就是彻底禁止了"?:"的使用就连最简单的也不行，比如：

<module />

如果两个分号";"之前只有空格，那么后一个分号所定义的语句就是空的比如下面代码的第二行就是空语句：

想对它进行检查，请在配置文件中增加：

<module />

可以检查一个类是否覆写(override)了equals和hashCode方法，这样：

<module />

如果某个变量一直都没变，那么它就应该是final型的想检查它，请增加：

<module />

通过检查来确保程序员使用了工厂方法(factory method)，而不是构造函数 比如，规定不能通过new 来构造一个java.lang.Boolean，对应的检查应该是：

<module >

    <property value="java.lang.Boolean"/>

</module>

"classes"属性指定了不能使用构造函数的类的范围多个类之间用分号表示每个类名前都要有完整的package名字

很多大牛都建议在java中不要使用switch；另外，使用c++ 或 c-- 这样的后缀也会让可读性变差想进行这样的检查，使用：

<module />

就可以检查程序中是否使用了"swtich, ++后缀， --后缀"这三个不合适的符号如果想指定只检查"switch"，可以指定"tokens"属性：

<module >

       <property value="LITERAL_SWITCH"/>

</module>

想检查更多，请参考com.puppycrawl.tools.checkstyle.api.TokenTypes中定义的常量

如果有人这样写：String s = Integer.toString(i = 2); 是不是很想扁他？这样检查：

<module />

sex = 0

表示的什么意思？大多数时候，就连作者本人都要皱眉头想半天，汗所以，这里的"0" 就是一个魔法数如果这样写就好的多：

public static final int MALE= 0;

这样我们就知道，原来是把 sex 变量的值设成 男性想检查它，请增加：

<module />

如果只想对int型和double型的数做检查，而且忽略数字"0"和"0.05"，可以这样：

<module >

    <property value="NUM_DOUBLE, NUM_INT"/>

    <property value="0, 0.05"/>

</module>

该检查有两个属性："tokens"属性可以指定检查的范围，可用的值是"NUMBER_DOUBLE, NUM_FLOAT, NUM_INT, NUM_LONG"中的子集默认是全部 "ignoreNumbers"属性指定了可以忽略的数字，默认是"-1, 0, 1, 2"

魔法数的检查很有必要，可以让你的程序的可读性大大增加强烈建议使用:)

switch最好别用因为用了必须要有default分支才能逻辑正确否则的话，编译不报错但是运行起来会报错（把所有的case依次执行一遍）想检查它，请增加：

<module />

比如，一个for循环的 循环数是只应该在 最后的 i++ 中更改的，如果出现以下代码：

这里是极可能是程序员大意写出来的

则说明，这个循环节有90%是大意，写错了因为其中的循环控制变量 i 在一个循环中 ++ 了两次这样检查：

<module />

为异常声明中的多余的Excpetion（比如duplicate, unchecked异常，或者它们的子类）做检查默认检查，增加：

<module />

<module >

    <property value="true"/>

</module>

检查过度复杂的条件表达式，比如： (b == true), b || true, !false, 难读且容易出错

<module />

if (valid())

else

就可以写成：

return !valid();                    

Checkstyle作者自我调侃说：这个想法是从PMD的类似规则中剽窃过来的哈哈这样检查：

<module />                

if (x == "something")                  

而他实际的意思应该是：

if ("something".equals(x))

想检查，请增加：

<module />

通过指定来限制 if-else 的嵌套的层次所谓的嵌套的if，是指一个if被包含在另一个if中下面是嵌套数是"1"的代码:

if(true){

}

<module >

</module>

这个检查请大家宽容一点见过IBM的朋友写的代码里if嵌套的也比较多一般的项目就更是代码的改善是个持续的过程，耐心些

<module >

</module>

检查并确认一个类的clone()方法调用了父类的clone() 这样：

<module />

检查并确认一个类的finalize()调用了父类的finalize() 这样：

<module />

捕获 java.lang.Exception , java.lang.Error, java.lang.RuntimeError 是不合理的

新手经常把本应捕获多种异常的格式，简化写成：catch Exception 这一种（汗，我有时也是 -_-!），这样会导致无法正常捕获NPE，OutOfMemoryErrors这样的异常 而且也不能针对不同的异常进行不同的处理默认检查：

<module />

想检查 java.lang.Exception 和 your.package.Exception 是不合理的，可以这样：

<module >

       <property value="java.lang.Exception, your.package.Exception"/>

</module>

其中"illegalClassNames"属性指定了不合理的异常名称，多个名称之间用","号

确保某些类型（老外叫type，我们叫class, interface ==）不被throw. 比如说，声明抛出 java.lang.Error, java.lang.RuntimeException 就是不可以的默认检查：

<module />

想检查 java.lang.Exception 和 your.package.Exception 是不合理的，可以这样：

<module >

       <property value="java.lang.Exception, your.package.Exception"/>

</module>

其中"illegalClassNames"属性指定了不合理的异常名称，多个名称之间用","号

确保一个类有package声明如果一个 class 没有package声明，那么它就无法被引用，作者说很多新手都懒的写这个东东不过我还没见过呵呵

<module />

确保setUp(), tearDown() 方法被正确的命名，没有参数，void返回类型，而且是public 或者protected的 确保suite() 被正确的命名，没有参数，返回 junit,framework.Test, 而且是 public static 型注意：上面这几点经常被搞错的后果是写错的方法编译肯定通过，但是不会被junit执行

<module />

限制一个方法中return语句的数量默认是2忽略特定的方法（默认是equals()）如果return 语句太多，说明某个方法需要实现的功能太多，而且很难阅读（这个时候就需要重构，建议看看重构的Extract Method 和 Simplifying Conditional Expressions. 两章 ）想确保每个方法最多有3个return 语句，忽略equals()，这样做：

</module>                   

<module >

    <property value="^$"/>

</module>                   

其中"format"属性是一个 regular expression（正则表达式）"max"属性指定了可允许的最大数

class 声明首先是 public, 然后是protected , 然后是 package level （不包括access modifier ）最后是private . (多个class放在一个java文件中的情况）

变量声明 首先是 public, 然后是protected然后是 package level （不包括access modifier ）最后是private . (多个class放在一个java文件中的情况）

构造函数

方法

这样：

<module />

禁止对参数赋值

public someMethod(String para1){}

这样的语句

官方文档：对方法的参数赋值一般说来，是不好的编程技巧而强制开发人员声明一个final 参数也不太合适的所以让Checkstyle做检查正合适

想进行检查，这样：

<module />

确保某个class 在被使用时都已经被初始化成默认值(对象是null , 数字和字符是0 , boolean 变量是false.)了 这样检查：

<module />

确保switch语句的default一定在最后出现虽然java语法允许default可以放在switch中的任何位置，但是把它放在各个case的最下面是可读性最强的

p.s. 如果不写default , 就会产生逻辑错误，却没有提示非常不建议使用switch，请使用ifelse 代替当然了，如果没使用default,貌似本检查也能检查的出来 这样使用：

<module />

确保某个类定义了一个默认之外的构造函数这样：

<module />

检查每个switch只执行一个分支也就是说，检查某个case中是否有 break, return ,throw 或 continue语句

<module />

重构中建议，不使用switch（貌似在 简化条件表达式一章）

确保一个文件中的同样内容的字符串不出现多次重复的代码难以维护所以建议使用常量来代替多个相同字符串 默认只出现一次的检查：

<module />                  

最多重复两次的检查：

<module >

    <property value="2"/>

</module>                   

<module >

    <property value='^(("")|(", "))$'/>

</module>                   

上面例子中可以看出，"allowedDuplicates"属性指定了可以重复的最大数，默认1 "ignoreStringsRegexp"属性指定了被忽略的字符的正则表达式格式，默认是忽略空的字符串(^""$）

<module />

<module />

只检查变量，不检查方法：

<module >

    <property value="false"/>

</module>                   

"checkFields"属性指定了是否检查field（类的变量），默认是true, "checkMethods"属性指定了是否检查方法，默认是true.

检查不必要的圆括号(,)比如， if(((((true))))) 这样是不是很个性？这样：

<module />

不过很多时候圆括号的正确使用会提高代码的清晰度比如：

return ( SomeClassName.CONSTANT1 == variable )? result1 : result2;

是否使用请酌情选择

检查类成员的可见性只有static final 成员是public的，其他的类成员都是private的，除非在本检查的protectedAllowed和packagedAllowed属性中进行了设置默认检查：

<module />

允许包可见成员的检查：

<module >

    <property value="true"/>

</module>

不允许公共成员的检查：

<module >

    <property value="^$"/>

</module>                          

<module />

本检查就是实现了：

根据Bloch 的说法，一个interface用来描述一个type, 所以，在interface中不定义方法却只定义常量的做法是不合适的

本检查也可以配置成不允许marker interface，比如 java.io.Serializable这样的不包括方法和常量的类

<module />

原理：它的构造函数只应该是private 或 protected（如果它有子类的话）的 常见的错误是，忘记了隐藏默认的构造函数（它是public的）

如果想把一个构造函数定义成protected，你也许会考虑下面的构造函数的方法：例子．一个工具类

// not final to allow subclassing

public class StringUtils

{

        throw new UnsupportedOperationException();

    public static int count(char c, String s) {

}

这样检查：

<module />                

确保某个class是为了方便继承而设计的本检查可以强制实现这样的编程风格：在父类中使用空的方法，然后在子类中进行实现

规则是：在子类中overrided的非private ,非static方法，需要符合下列情况之一：

abstract

final

有空语句

原理（借用官方文档）：这个API设计风格保护了父类不被子类所破坏 缺点是子类的灵活性降低，子类无法阻止父类的代码被执行同时子类却也不会由于忘记调用父类的方法而破坏父类的状态

这样检查：

<module />                   

异常是methods interface的一部分一个方法如果声明抛出太多不同的异常，会导致异常处理(catch)混乱， 本检查强制规定一个方法的throws的次数

想配置每个方法最多抛出两个异常，使用：

<module >

</module>

本检查应该放在<module >结点下

重复代码的检查可以让你找到经过COPY/PAST出来的代码重复代码的典型缺点是增加维护代价， 因为需要你把一个BUG修改很多次，测试更多次 Checkstyle在实现该方面的检查过程中，考虑了以下的目标：

快速

避免无效的，错误的警告

支持模糊匹配（注释，空格，换行，变量重命名等）

checkstyle提供的是StrictDuplicateCode, 它速度很快，消耗的内存很少，不会出现错误的警告 当检查支持多种语言时，不支持模糊匹配（这也是它被称为strict（严格）检查的原因） 也就是说，如果一段重复代码，既在JSP中出现，又在JAVA中出现，就无法支持模糊查询

请注意，其实有很多相当出彩的商业性的重复代码检查工具最具有代表性的就是RedHill咨询公司的它很好的实现了以上需求的折中它在各个方面都优于checkstyle包中的其他类，价格很有诱惑力（对非商业用途免费），因而被checkstyle用作一个插件（plugin）

Simian

非常快

低

非常小的几率会出现

有限度的支持

当代码只是在缩进上有所不同时，就把它们逐行的进行比较，并报告是否重复忽略import , 其他的内容，包括javadoc, 方法间隔的空白行，等都会被包含进来，进行比较

使用默认检查：

<module />

<module >

    <property value="15"/>

    <property value="UTF-8"/>

</module>

本检查会把空白行算在检查范围里如果代码中存在一段多于"min"属性所定义的空白行时，也会报错例如，"min"=8时， 如果代码中存在9个连续的空白行，就会报错

本检查一定要放在"TreeWalker"节点前面，否则在Checkclipse中无法使用（Eclipse 3.2, Europa都是） 但是在Ant中却正常

编码时的各种量度，很理论化我还没在国内的其他文档中看到此类内容，所以把内容基本照搬来了，大家共同学习吧:)

限制一个布尔表达式中的 &&, || 和^的个数可以让代码看起来更清晰，容易排错和维护默认检查：

<module />                   

<module >

</module>

ClassDataAbstractionCoupling

检查一个类中建立的其他类的实例的个数这种类型的耦合不是由继承或面向对象的聚合而引起的 一般而言，任何一个抽象数据类型，如果将其他抽象数据类型作为自己的成员，那么它都会产生数据抽象耦合(DAC)； 换句话说，如果一个类使用了其他类的实例作为自己的成员变量，那么就会产生数据抽象耦合 耦合度越高，这个系统的数据结构就越复杂

原文：This metric measures the number of instantiations of other classes within the given class. This type of coupling is not caused by inheritance or the object oriented paradigm. Generally speaking, any abstract data type with other abstract data types as members has data abstraction coupling; therefore, if a class has a local variable that is an instantiation (object) of another class, there is data abstraction coupling. The higher the DAC, the more complex the data structure (classes) of the system.

申思维注：也就是说，一个类中如果使用太多其他的类，是肯定会增加系统复杂度的使用其他的类越少，耦合度就越少

<module >

</module>

ClassFanOutComplexity

一个类依靠的其他类的个数这个数字的平方也会被显示出来，以表示最少需要的修改个数

原文：The number of other classes a given class relies on. Also the square of this has been shown to indicate the amount of maintenence required in functional programs (on a file basis) at least.

<module >

    <property value="10"/>

</module>

CyclomaticComplexity

确保函数的分支复杂度没有超出限制该复杂度是通过考察大部分函数（构造函数，一般方法，静态初始函数，实例初始化函数） 中的 if, while, do, for, ? : , catch, switch, case 语句 和 &&, || 的操作符的数目来计算得到的 它表示了通过一个函数的最少分支数，也因此体现了需要进行的测试数目 一般而言1-4 是优秀，5-7是合格8-10看情况重构11个以上一定要马上重构！

<module >

</module>

NpathComplexity

NPATH 量度 计算了一个函数的可执行的分支个数它很重视条件语句的嵌套和多个部分组成的布尔表达式 （比如， A&&B, C||D, 等等）

Nejmeh说，他的小组有一个非正式的NPATH约定：不超过200NPATH超过这个数字的函数就一定要被分解

原文：The NPATH metric computes the number of possible execution paths through a function. It takes into account the nesting of conditional statements and multi-part boolean expressions (e.g., A && B, C || D, etc.).

Rationale: Nejmeh says that his group had an informal NPATH limit of 200 on individual routines; functions that exceeded this value were candidates for further decomposition - or at least a closer look.

<module >

    <property value="40"/>

</module>

很难归类的杂项

为代码问题而做的检查 用户可以通过本检查来控制某些代码的使用比如，禁止在代码中使用"System.out.println"的检查：

<module >

    <property value="System\.out\.println"/>

</module>

其中"format"属性指定了非法的字符的正则表达式的格式（"."用"\."表示），完整的属性表如所示

检查文件末尾是否有一个回车

原理：源文件和文本文件一般应该以一个新行（回车）作为结尾特别是在使用源代码控制系统比如CVS的时候如果没有以新行作为文件结尾，CVS甚至会显示警告（ 貌似我没遇到过，也许用的是WINCVS？）

本检查应该放在<module >结点下

默认检查：

<module />

<module >

    <property value="lf"/>

</module>

    <property value="java, xml, py"/>

</module>

lineSeparator

行分隔符号

下列值之一："system", "crlf"(windows), "cr"(Mac) 和"If"(Unix)

system

对于//TODO： 的检查事实上就是用一个正则表达式来匹配JAVA文件的注释内容，

<module >

    <property value="WARNING"/>

</module>

其中"format"属性指定了被检查的字符串的内容，默认是"TODO:"，格式是正则表达式

为了保证翻译的正确性而检查所有的属性文件(propertiy files)的键(key)是否一致 如果两个属性文件描述的是同一个东东的不同语言版本，那么它们应该包含相同的键

本检查应该放在<module >结点下

假如有同一个目录下的两个属性文件：

#messages.properties

hello=Hello

cancel=Cancel

#messages_de.properties

hell=Hallo

ok=OK

使用本检查就会找出错误：默认文件 messages.properties中，缺少了hell, ok两个键，而在德文文件 messages_de.properties中，缺少了hello, cancel键所以下面就是提示：

messages_de.properties: Key 'hello' missing.

messages_de.properties: Key 'cancel' missing.

messages.properties: Key 'hell' missing.

messages.properties: Key 'ok' missing.

本检查的算法，就是把若干语言包文件中的key合并到一个集合中，去掉重复项，然后再依次对比每个文件缺少的key做提示很适合对支持多语言的项目做检查

这样就可以：

<module />

<module >

    <property value="zh-CN, jp"/>

</module>

其中"fileExtensions"指定了被检查文件的扩展名默认是"properties"

原理：Main()函数通常被用于调试，在JUnit出现之后Main()有所减少，但是也有人喜欢用我们调试完后很容易就忘掉删了它 它修改了API，增加了class或者jar文件的体积所以，除了正常的程序入口之外，所有的main方法都应该被删掉或注释掉

默认检查：

<module />

可以设置"excludedClasses"属性来不检查某个类，类型是正则表达试，默认值是"^$"如果不想检查名称中以"Main"结尾的类，可以这样：

<module >

       <property value="^Main&"/>

</module>

检查并确保所有的常量中的L都是大写的也就是在常量中没有使用l而是用的L，比如long型常量，都要以L结尾这与相一致小写的字母l 跟数字1 太象了

<module />

检查数组类型的定义有两种风格：java风格的： String[] args 或者 C/C++ 风格的：String args[]

<module />

<module >

    <property value="false"/>

</module>

检查并确保方法，构造函数，和catch区域中的参数是final的 Interface 和 抽象类不会被检查，因为它们中没有实现代码，所以它们中的也就没有被修改的可能

原理：在函数中的参数会很让人感到迷惑，也是个很差的习惯避免该情况的好办法是把参数声明成 final型

默认：在一般方法和构造函数中检查：

<module />

只在构造函数中检查：

<module >

    <property value="CTOR_DEF"/>

</module>

因为"tab"在不同的文本编辑器下的缩进是不同的，所以最好都使用空格

默认配置：基本缩进 4个空格，新行的大括号：0新行的case 4个空格

<module />

本检查为了确保每个注释都是单独的一行对于以 //开头的注释，它所在行的前面只能是空格但是，如果一段注释不是一行的结尾，比如

Thread.sleep( 10 <some comment here> );               

那么该行就不会被检查

原理：Steve McConnel在Code Complete（代码大全）中认为与代码同行的注释是个不好的习惯与代码同行的注释也就是说，该行前面是代码，后面是注释比如：

a = b + c;      // Some insightful comment

d = e / f;        // Another comment for this line

引用代码大全作为佐证：

"The comments have to be aligned so that they do not interfere with the visual structure of the code. If you don't align them neatly, they'll make your listing look like it's been through a washing machine."

注释一定要排列整齐，这样你的程序结构就不会受到视觉上的扰乱如果不把它们排列整齐，那么杂乱的注释会让你的代码看起来象被洗衣机搅拌过一样

"Endline comments tend to be hard to format...It takes time to align them. Such time is not spent learning more about the code; it's dedicated solely to the tedious task of pressing the spacebar or tab key."

每行结尾的注释难于被格式化排列它们很需要时间可这些时间却不是被用在学习代码上，而是被浪费在枯燥的按空格和tab键上

"Endline comments are also hard to maintain. If the code on any line containing an endline comment grows, it bumps the comment farther out, and all the other endline comments will have to bumped out to match. Styles that are hard to maintain aren't maintained...."

每行结尾的注释也很难被维护如果任何包含结尾注释的行发生了增长，那么该行的结尾注释的开端就会相应的右移，那么其他行的结尾注释的开端同样需要右移，来与之对应难于被维护的风格基本不会被维护的

"Endline comments also tend to be cryptic. The right side of the line doesn't offer much room and the desire to keep the comment on one line means the comment must be short. Work then goes into making the line as short as possible instead of as clear as possible. The comment usually ends up as cryptic as possible...."

每行结尾的注释也很难全部显示出来每行的右边没多少闲余的空间，而且如果一定要把注释与代码放在同一行，造成了注释肯定长不了于是程序员的工作就变成了尽力将每行变的越短越好，而不是越干净越好这个结尾的注释也通常越来越难被看到而失去意义

"A systemic problem with endline comments is that it's hard to write a meaningful comment for one line of code. Most endline comments just repeat the line of code, which hurts more than it helps."

每行结尾的注释的影响到系统的问题是，它很难为一行代码写出有意义的内容大部分情况下，它只是把代码的字面意思重复一下，而这个代码也是弊大于利

他的关于 当行改变时代码难于维护的阐述，随着可以自动化重构的时代的到来变的更重要了

His comments on being hard to maintain when the size of the line changes are even more important in the age of automated refactorings.

默认这样检查：

<module />                

<module >

    <property value="^\\s*$"/>

</module>

"format"属性指定了 与代码同行的注释 前面部分的代码，是一个正则表达式，默认是"^[\\s\\}\\);]*$"

确保代码中存在某个字符串的检查该检查不关心它出现的位置在哪儿，只要它出现了就可以比如，检查代码中必须出现了版权的字样, This code is copyrighted：

<module >

   <property value="This code is copyrighted"/>

</module>

"format"属性指定了 必须出现的字符串的 正则表达式默认是空"^$"