Checkstyle4.3 中文手册
Checkstyle4.3 中文手册
加入OpenDoc前的 预览版。
申 思维
1.0
版权 © 2008 申思维
本文根据Checkstyle4.3 英文官方文档而来。我打算发布成OpenDoc, 欢迎大家给我来信，多提意见！谢谢
目录
1. 前言
1. 介绍
1.1. 概述
1.2. 特点
1.3. 下载
2. N分钟入门
3. 常用的检查
3.1. 典型的配置文件
4. 用的最多的20%功能
5. 在Ant中使用Checkstyle
5.1. N分钟极速入门
5.2. 安装与配置
5.3. 典型例子
5.4. checkstyle任务的参数
5.5. 可以嵌套的ant元素
6. 在Eclipse中使用Checkstyle
6.1. 下载和安装
6.2. 配置方法
6.3. 使用
6.4. 常见问题
7. 各种检查
7.1. 如何配置检查
7.2. JavaDoc注释
7.2.1. 类和接口的javadoc
7.2.2. 方法的javadoc
7.2.3. 方法的javadoc
7.2.4. 变量的javadoc
7.3. 命名约定
7.3.1. 模块一览
7.3.2. 注意
7.4. 文件头
7.5. Imports
7.5.1. import中避免星号"*"
7.5.2. 没用的import
7.6. 长度限制
7.6.1. 文件长度
7.6.2. 每行长度
7.6.3. 方法长度
7.6.4. 方法的参数个数
7.7. 空格
7.7.1. 方法名与左边圆括号之间
7.7.2. 圆括号附近的空格
7.7.3. 类型转换中圆括号附近的空格
7.7.4. 对"Tab"的检查
7.7.5. 特定符号后的空格
7.8. 关键字
7.8.1. 关键字的出现顺序
7.8.2. 多余的关键字
7.9. 对区域(empty block)的检查
7.9.1. 空白区域
7.9.2. 对左侧括号{ 的检查（略）
7.9.3. 需要括号的区域
7.9.4. 对右侧括号} 的检查（略）
7.9.5. 不必要的括号
7.10. 编码的检查
7.10.1. 数组尾巴的逗号
7.10.2. 避免内联(inline)条件判断
7.10.3. override的equals方法
7.10.4. 空语句(statement)
7.10.5. equals和hashCode方法
7.10.6. 应该声明成final的局部变量
7.10.7. 不合适的初始化
7.10.8. 不合适的token
7.10.9. 内部赋值语句
7.10.10. 魔法数
7.10.11. 丢了default分支的switch
7.10.12. 被更改的循环控制变量
7.10.13. 多余的throw
7.10.14. 未被简化的条件表达式
7.10.15. 未被简化的布尔返回值
7.10.16. 字符串(String)的比较
7.10.17. 嵌套的if 层次
7.10.18. 嵌套的try 层次
7.10.19. 调用父类的clone
7.10.20. 父类的finalize
7.10.21. 不合理的catch
7.10.22. 不合理的throws
7.10.23. package 声明
7.10.24. JUnitTestCase
7.10.25. return 语句的数量
7.10.26. 声明的顺序
7.10.27. 参数被赋值
7.10.28. 详尽的变量初始化
7.10.29. switch语句的default位置排在最后
7.10.30. 丢失的构造函数
7.10.31. switch中错误分支。
7.10.32. 多个内容相同的字符串变量
7.10.33. 同一行禁止声明多个变量
7.10.34. 不使用this
7.10.35. 不必要的圆括号
7.11. Class的设计
7.11.1. 可见的修改方法
7.11.2. Final class
7.11.3. Interfacels Type
7.11.4. 隐藏工具类的构造方法
7.11.5. 方便继承(extention)而进行的设计
7.11.6. throws的数量
7.12. 重复的代码
7.12.1. StrictDuplicateCode 严格的重复代码检查
7.13. 各种量度
7.13.1. 布尔表达式的复杂度
7.13.2. 类数据的抽象耦合
7.13.3. 类的分散复杂度
7.13.4. 函数的分支复杂度
7.13.5. Npath复杂度
7.14. 杂项
7.14.1. 禁止使用的表达式
7.14.2. 文件结尾的回车
7.14.3. Todo注释
7.14.4. 翻译属性文件
7.14.5. 没有被注释掉的Main函数
7.14.6. 大写的L
7.14.7. 声明数组的风格
7.14.8. final型的参数
7.14.9. 缩进
7.14.10. 与代码同行的注释
7.14.11. 必须出现的字符串
术语表
参考书目
插图清单
2.1. 测试如何使用checkstyle的项目
2.2. 开启Checkstyle
2.3. 代码窗口中的错误提示
2.4. Problems窗口中的错误提示
2.5. 增加了class的注释后的效果图
2.6. 使用自定义的Checkstyle配置文件
2.7. 定制配置的检查结果
2.8. 修正后的定制配置的检查结果
5.1. 在Ant环境下Checkstyle的所须文件
5.2. Ant下Checkstyle检查正确的结果
5.3. Ant下Checkstyle检查错误的结果
6.1. 成功安装Checkclipse后的Preferences窗口
6.2. 配置单个项目的Checkclipse
6.3. 设置单个项目的Checkclipse的文件过滤器(file filter)
6.4. 出错信息中的检查名
6.5. Problems的过滤器中配置Checkclipse。
6.6. 右键菜单中的checkstyle选项
表格清单
5.1. checkstyle任务属性表
5.2. formatter元素的属性
7.1. 命名约定检查模块一览表
7.2. WhitespaceAfter 属性列表
7.3. 重复代码插件的特性摘要：
7.4. GenericIllegalRegexp的属性列表
7.5. NewlineAtEndOfFile的属性列表
7.6. Indentation的属性列表
前言
Preface
Checkstyle是非常优秀的代码规范检查软件，可以大幅的提高代码质量， 当项目的开发人员比较多时，用它来统一代码风格是很有必要的。
本文的写作，是由于公司的质量管理部门对代码格式进行了要求。 在网上也没有发现有比较详细全面的中文文档。所以参考Checkstyle4.3的官方文档写就。
有个比较神奇的20%-80%规律是这样说的：一本书，用的最多的只是20%的内容，它的出现几率是80%； 而剩下的80%内容，被使用的不到20%。这个规律也同样适用在其他东东上。只是数据上稍有差异。 所以我特意安排了 第 4 章 用的最多的20%功能 ，作为典型的使用方法。
对于赶时间的朋友，也可以直接看第 2 章 N分钟入门 ，可以让你在最快的时间内入门。 对于时间充沛的朋友，建议多看看文档。因为作者一再的强调“it is worth reading the documentation”。
第 5 章 在Ant中使用Checkstyle 说明了在ant下的用法。第 6 章 在Eclipse中使用Checkstyle 说明了Eclipse的插件Checkclipse的用法。
对于初次接触代码规范的朋友，我安排了第 3 章 常用的检查 ，里面是个人以为满足大多数公司要求的检查，包括一个配置文件。
第 7 章 各种检查 是各种检查的详细用法，读起来比较枯燥，建议象查字典那样有需要时翻阅，所以放在最后。
[小心] 欢迎意见
为了加入OpenDoc , 欢迎各位朋友指出文档中的任何错误和不足，也可以给我任何意见。请Email给我：shensiwei(at)sina.com
希望本文对您有用。谢谢！
第 1 章 介绍
Introduction
目录
1.1. 概述
1.2. 特点
1.3. 下载
1.1. 概述
Checksytle 是一款代码格式检查工具。它可以根据设置好的编码规则来检查代码。 比如符合规范的变量命名，良好的程序风格等等。如果你的项目经理开会时说，“我希望我们写出来的代码就象一个人写的！” 时，用Checkstyle绝对是正确选择。:)
本文档就是在4.3的基础上完成。截止到2008-02-22，最新的版本是4.4。
需要强调的是，Checkstyle只能做检查，而不能做修改代码。
[小心] 提醒
想修改代码格式，请使用Jalopy. 它和Checkstyle配合使用非常合适。
1.2. 特点
Checkstyle的配置性极强，你可以只检查一种规则，也可以检查三十，四十种规则。可以使用Checkstyle自带的规则， 也可以自己增加检查规则。（这点跟 Ant 自定义target比较象）
支持几乎所有主流IDE，包括 Eclipse , IntelliJ, NetBeans, JBuilder 等11种。
1.3. 下载
最新的发布版本在 ： 这里
4.4使用了SVN，关闭了CVS。SVN在 这里
各种插件下载，见 Checkstyle主页 中的列表。
第 2 章 N分钟入门
extreme learning
让您在几分钟之内了解Checkstyle的大致用法。适合赶时间的朋友。假设您已经安装好了Checkstyle的Eclipse插件。
[小心] 测试
欢迎在阅读下一行之前，记录下当前的时间，然后在读完本节之后，算算您用了多少时间。 如果方便，请将您用的时间告诉我，谢谢:)
1.
首先，我们建立一个eclipse的项目：test_checkstyle。包含一个源文件夹：src，一个目标生成文件夹 eclipse_build. 如 图 2.1 “测试如何使用checkstyle的项目” 所示。
测试如何使用checkstyle的项目
图 2.1. 测试如何使用checkstyle的项目
2.
在项目中开启Checkstyle: 打开该project的属性，点中左侧的Checkclipse后，将"Enable Checkstyle"前面打上勾。 如 图 2.2 “开启Checkstyle” 所示。
开启Checkstyle
图 2.2. 开启Checkstyle
3.
建立一个测试用的Class: 比如SomeClassToBeChecked，内容如下：
/*
* Copyright (c) 2001-2008 Beijing BidLink Info-Tech Co., Ltd.
* All rights reserved.
* Created on 2008-2-22
*
* $Id: learn_in_5_min.xml,v 1.3 2008/03/03 03:43:44 Administrator Exp $
*/
package test;
public class SomeClassToBeChecked {
}
只有一个头部注释，没有方法，啥啥都没有。
4.
用Checkstyle检查它：右键点项目名，选择"Build Project"，会把src文件夹进行编译，把class文件放到eclpise_build中。 结束之后，我们可以看到： 图 2.3 “代码窗口中的错误提示” 中的代码第10行处，有一个叹号，把鼠标移上去就会出现 提示"Missing a Javadoc comment."
代码窗口中的错误提示
图 2.3. 代码窗口中的错误提示
同时，在Problems窗口中也有提示，如 图 2.4 “Problems窗口中的错误提示” 所示。
Problems窗口中的错误提示
图 2.4. Problems窗口中的错误提示
5.
修改代码：既然提示说缺少了Javadoc注释，我们就把它加上。 如 图 2.5 “增加了class的注释后的效果图” 所示。
增加了class的注释后的效果图
图 2.5. 增加了class的注释后的效果图
然后重新编译，可以看出，Warning没有了。检查通过。
[小心] 注意
上面的很简单是吧？恩，我也这么觉得。但别走！如果以为这样就可以用Checkstyle， 那你就错了。你可以试一下用同样的方式来编译一个项目，会发现根本是Warning满天飞。为什么？因为Checkstyle自带的检查非常变态， 随便一个项目都可以弄出几千个Warning。所以，想用它，一定要使用自己的定制检查。:)
6.
定制检查：Checkstyle没有图形化的定制器，所以需要手工修改配置文件。比如，我们的代码需要符合下列规则：
*
长度方面：文件长度不超过1500行，每行不超过120个字，方法不超过60行.
*
命名方面：类名不能小写开头，方法名不能大写开头，常量不能有小写字母。
*
编码方面：不能用魔法数(Magic Number），if最多嵌套3层。
那么，我们的检查配置文件（如命名成 my_check.xml ） 应该是这样的：
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC
"-//Puppy Crawl//DTD Check Configuration 1.2//EN"
"http://www.puppycrawl.com/dtds/configuration_1_2.dtd">
<module name="Checker">
<module name="TreeWalker">
<!-- 长度方面的检查 -->
<!-- 文件长度不超过1500行 -->
<module name="FileLength">
<property name="max" value="1500"/>
</module>
<!-- 每行不超过120个字-->
<module name="LineLength">
<property name="max" value="120"/>
</module>
<!-- 方法不超过60行 -->
<module name="MethodLength">
<property name="tokens" value="METHOD_DEF"/>
<property name="max" value="60"/>
</module>
<!-- 命名方面的检查，它们都使用了Checkstyle默认的规则。 -->
<!-- 类名(class 或interface) 的检查 -->
<module name="TypeName"/>
<!-- 方法名的检查 -->
<module name="MethodName"/>
<!-- 常量名的检查 -->
<module name="ConstantName"/>
<!-- 编码方面的检查 -->
<!-- 不能用魔法数 -->
<module name="MagicNumber"/>
<!-- if最多嵌套3层 -->
<module name="NestedIfDepth">
<property name="max" value="3"/>
</module>
</module>
</module>
可以看出，想增加一个检查，就是增加一个<module/>结点。具体的结点内容在后面的文档都会写明。
7.
让Checkstyle使用指定的检查配置文件：打开项目属性，在Checkclipse中的"Checkstyle Configuration File" 一栏中 选定我们的配置文件，然后确定。如 图 2.6 “使用自定义的Checkstyle配置文件” 所示。
使用自定义的Checkstyle配置文件
图 2.6. 使用自定义的Checkstyle配置文件
然后重新编译项目，就会发现，Checkstyle的规则如我们所愿：只检查我们在文件中配置的几项。并且它们是以"Error"级别进行提示，而不是默认检查时出现的"Warning"级别。 比如，我们把一个方法中，增加4层嵌套（共5个if），并将方法名大写，就会出现 图 2.7 “定制配置的检查结果” :
定制配置的检查结果
图 2.7. 定制配置的检查结果
可以看到，出现了两个Error: 方法名的"Name xx must match pattern..." 和if嵌套的"Nested if-else depth is 4..."。 把它们都改过来，程序就好了。
8.
代码的修正：依照上面的例子，把方法名小写，if循环嵌套3层，然后重新编译，OK。如： 图 2.8 “修正后的定制配置的检查结果”
修正后的定制配置的检查结果
图 2.8. 修正后的定制配置的检查结果
到这里就结束了。看明白了吗？欢迎给我意见，以及看到这里所用的时间。:)
想在N分钟内了解ant下checkstyle的使用方法，请看 第 5.1 节 “N分钟极速入门”
第 3 章 常用的检查
目录
3.1. 典型的配置文件
Checkstyle自带了两个配置文件：checkstyle_checks.xml 和 sun_checks.xml。前者是checkstyle作者定义的，后者是严格符合Sun编码规范 的。 可惜它们的检查太过严格，任何一个项目都会搞出上千个Warning来。
所以这里提供了一个配置文件，包含了比较常用的检查，去掉了对空格位置，大括号位置等国内不注重的内容， 建议个人使用。
如果是公司使用，建议把它再精简些。因为对公司来说，这个配置文件还是比较苛刻的。
3.1. 典型的配置文件
下面是一个典型的checkstyle配置文件，应该适合于大多数情况的要求。每个检查前的注释说明了它的作用。本文的PDF文档 无法正常显示其中的汉字，建议本节使用HTML版查看。:)
<!DOCTYPE module PUBLIC
"-//Puppy Crawl//DTD Check Configuration 1.2//EN"
"http://www.puppycrawl.com/dtds/configuration_1_2.dtd">
<module name="Checker">
<!-- 重复代码的检查，超过8行就认为重复，UTF-8格式
本检查一定要放在"TreeWalker"节点前，否则在
Checkclipse中会无法使用。(在ant下可以)
-->
<module name="StrictDuplicateCode">
<property name="min" value="8"/>
<property name="charset" value="UTF-8"/>
</module>
<module name="TreeWalker">
<!-- javadoc的检查 -->
<!-- 检查所有的interface和class -->
<module name="JavadocType"/>
<!-- 检查所有方法的javadoc，可以不声明RuntimeException -->
<module name="JavadocMethod">
<property name="allowUndeclaredRTE" value="true"/>
</module>
<!-- 检查某个变量的javadoc -->
<module name="JavadocVariable"/>
<!-- 命名方面的检查，它们都使用了Sun官方定的规则。 -->
<!-- 类名(class 或interface) 的检查 -->
<module name="TypeName"/>
<!-- 变量的检查 -->
<module name="MemberName"/>
<!-- 方法名的检查 -->
<module name="MethodName"/>
<!-- 方法的参数名 -->
<module name="ParameterName "/>
<!-- 常量名的检查 -->
<module name="ConstantName"/>
<!-- 长度方面的检查 -->
<!-- 文件长度不超过1500行 -->
<module name="FileLength">
<property name="max" value="1500"/>
</module>
<!-- 每行不超过120个字-->
<module name="LineLength">
<property name="max" value="120"/>
</module>
<!-- 方法不超过30行 -->
<module name="MethodLength">
<property name="tokens" value="METHOD_DEF"/>
<property name="max" value="30"/>
</module>
<!-- 方法的参数个数不超过3个。 -->
<module name="ParameterNumber">
<property name="max" value="3"/>
</module>
<!-- 多余的关键字 -->
<module name="RedundantModifier"/>
<!-- 对区域的检查 -->
<!-- 不能出现空白区域 -->
<module name="EmptyBlock"/>
<!-- 所有区域都要使用大括号。 -->
<module name="NeedBraces"/>
<!-- 多余的括号 -->
<module name="AvoidNestedBlocks">
<property name= "allowInSwitchCase"
value="true"/>
</module>
<!-- 编码方面的检查 -->
<!-- 不许出现空语句 -->
<module name="EmptyStatement"/>
<!-- 每个类都实现了equals()和hashCode() -->
<module name="EqualsHashCode"/>
<!-- 不许使用switch -->
<module name="IllegalToken">
<property name="tokens"
value="LITERAL_SWITCH"/>
</module>
<!-- 不许内部赋值 -->
<module name="InnerAssignment"/>
<!-- 绝对不能容忍魔法数 -->
<module name="MagicNumber"/>
<!-- 循环控制变量不能被修改 -->
<module name="ModifiedControlVariable"/>
<!-- 多余的throw -->
<module name="RedundantThrows"/>
<!-- 不许使用未被简化的条件表达式 -->
<module name="SimplifyBooleanExpression"/>
<!-- 不许使用未被简化的布尔返回值 -->
<module name="SimplifyBooleanReturn"/>
<!-- String的比较不能用!= 和 == -->
<module name="StringLiteralEquality"/>
<!-- if最多嵌套3层 -->
<module name="NestedIfDepth">
<property name="max" value="3"/>
</module>
<!-- try最多被嵌套1层 -->
<module name="NestedTryDepth"/>
<!-- clone方法必须调用了super.clone() -->
<module name="SuperClone"/>
<!-- finalize 必须调用了super.finalize() -->
<module name="SuperFinalize"/>
<!-- 不能catch java.lang.Exception -->
<module name="IllegalCatch">
<property name="illegalClassNames"
value="java.lang.Exception"/>
</module>
<!-- JUnitTestCase 的核心方法存在。 -->
<module name="JUnitTestCase"/>
<!-- 一个方法中最多有3个return -->
<module name="ReturnCount">
<property name="max" value="3"/>
</module>
<!-- 不许对方法的参数赋值 -->
<module name="ParameterAssignment"/>
<!-- 不许有同样内容的String -->
<module name="MultipleStringLiterals"/>
<!-- 同一行不能有多个声明 -->
<module name="MultipleVariableDeclarations"/>
<!-- 各种量度 -->
<!-- 布尔表达式的复杂度，不超过3 -->
<module name="BooleanExpressionComplexity"/>
<!-- 类数据的抽象耦合，不超过7 -->
<module name="ClassDataAbstractionCoupling"/>
<!-- 类的分散复杂度，不超过20 -->
<module name="ClassFanOutComplexity"/>
<!-- 函数的分支复杂度，不超过10 -->
<module name="CyclomaticComplexity"/>
<!-- NPath复杂度，不超过200 -->
<module name="NPathComplexity"/>
<!-- 杂项 -->
<!-- 禁止使用System.out.println -->
<module name="GenericIllegalRegexp">
<property name="format" value="System\.out\.println"/>
<property name="ignoreComments" value="true"/>
</module>
<!-- 不许使用与代码同行的注释 -->
<module name="TrailingComment"/>
</module>
<!-- 检查翻译文件 -->
<module name="Translation"/>
</module>
第 4 章 用的最多的20%功能
Core 20%
这里列出了个人以为的20%的最常用功能。欢迎您把自己认为的20%发过来，我会进行一个统计，及时更新本节。
*
命名符合规范
类，方法，成员变量等等的命名，一般要遵循 Sun编码规范 。
*
编码中的长度问题
类，方法的长度不应该过大。
*
编码习惯的检查
检查代码中是否有过多的if嵌套，魔法数，switch丢失的default, 复杂的条件表达式等。
*
重复的代码
如果两个代码段出现了一定行数的严格重复，就判定它们已经重复。
第 5 章 在Ant中使用Checkstyle
目录
5.1. N分钟极速入门
5.2. 安装与配置
5.3. 典型例子
5.4. checkstyle任务的参数
5.5. 可以嵌套的ant元素
如果您赶时间，请看第 5.1 节 “N分钟极速入门” 。:)
5.1. N分钟极速入门
（请打开一个秒表记时，谢谢）
需要"checkstyle-all-4.3.jar"，该jar文件包含了checkstyle所用的几乎所有类。
需要有一个指定的配置文件，比如当前项目中的"./config/my_check.xml"。
另外，把checkstyle-all.jar放在一个合适的目录中，比如"./lib"。
最后，设置Ant的输出文件夹为"./ant_build" 如 图 5.1 “在Ant环境下Checkstyle的所须文件” 所示。
在Ant环境下Checkstyle的所须文件
图 5.1. 在Ant环境下Checkstyle的所须文件
ant的配置文件中需要指定一个taskdef来定义checkstyle任务, 然后在checkstyle任务中指定配置文件(config属性)， 和需要被检查的文件夹(fileset)。本例使用的ant文件是这样的：
<?xml version="1.0" ?>
<project>
<taskdef resource="checkstyletask.properties"
classpath="./lib/checkstyle-all-4.3.jar"/>
<target name="my_check">
<checkstyle config="config/my_check.xml">
<fileset dir="src" includes="**/*.java"/>
</checkstyle>
</target>
</project>
如果checkstyle检查通过，则会看到"BUILD SUCCESSFUL"， 如 图 5.2 “Ant下Checkstyle检查正确的结果” 所示。
Ant下Checkstyle检查正确的结果
图 5.2. Ant下Checkstyle检查正确的结果
如果checkstyle检查到出错，就会输出错误信息，包括所有检查到的错误。比如，我们把一个方法的长度超过60，方法名大写，就会看到出错信息，并且"BUILD FAILED" 如 图 5.3 “Ant下Checkstyle检查错误的结果” 所示。
Ant下Checkstyle检查错误的结果
图 5.3. Ant下Checkstyle检查错误的结果
本节结束，欢迎您把看明白本节所用的时间通过Email告诉我。因为我想知道标题中的 "N" 是多少。 :)谢谢。
5.2. 安装与配置
其实本节内容已经被包含在了 第 5.1 节 “N分钟极速入门” 中，就是拥有checkstyle-all-4.3.jar 这个文件，并且在 ant的配置文件中进行task声明，如：
<taskdef resource="checkstyletask.properties"
classpath="./lib/checkstyle-all-4.3.jar"/>
然后通过<checkstyle/>任务来运行。
5.3. 典型例子
本节假定使用checkstyle任务的前提条件都已满足。
使用my_check.xml文件，对src目录下的所有java文件进行检查:
<checkstyle config="config/my_check.xml">
<fileset dir="src" includes="**/*.java"/>
</checkstyle>
使用my_check.xml文件，对src目录下的所有java文件进行检查，并且把出错的信息分别写到两个文件中:ant_build目录下的 checkstyle_errors.txt 和checkstyle_errors.xml中:
<checkstyle config="config/my_check.xml">
<fileset dir="src" includes="**/*.java"/>
<formatter type="plain" toFile="ant_build/checkstyle_errors.txt"/>
<formatter type="xml" toFile="ant_build/checkstyle_errors.xml"/>
</checkstyle>
值得一提的是，xml格式的文件里面把错误的信息格式弄的很清晰，调试起来比较方便。如果需要的话可以比较方便的扩展到诸如cruisecontrol里。
使用定义了package的文件：
<checkstyle config="config/my_check.xml"
packageNamesFile="myPackageNames.xml"
file="src/test/SomeClass.java"/>
5.4. checkstyle任务的参数
checkstyle任务的参数如 表 5.1 “checkstyle任务属性表” 所示。
表 5.1. checkstyle任务属性表
名字 描述 是否必须
file
被检查的文件。
一个file或者fileset
config
Checkstyle的配置文件。配置文件的使用方法见：第 7.1 节 “如何配置检查”
config或configURL必具其一
configURL
指定了Checkstyle配置文件的URL。用法
config或configURL必具其一
properties
定义了ant使用到的属性的文件。
否
packageNamesFile
定义了Checkstyle配置文件中检查的package name的文件。
否
failOnViolation
有violation时是否继续检查，默认是"true"
否
failureProperty
The name of a property to set in the event of a violation.
否
maxErrors
停止build前允许出现的"Error"的最大数目。默认是"0"
否
maxWarnings
停止build前允许出现的"Warning"的最大数目。默认是"2147483647"，也就是Integer.MAX_VALUE.
否
classpath
类路径，默认是当前使用的classpath。
否
classpathref
类路径的引用。
否
5.5. 可以嵌套的ant元素
checkstyle任务中可以前台以下元素: <filese>, <classpath>, <formatter> 以及<property>
formatter元素的属性如 表 5.2 “formatter元素的属性” 所示。
表 5.2. formatter元素的属性
名字 描述 是否必须
type
结果的输出方式，可用的值是：
plain :使用了 DefaultLogger
xml : 使用了XMLLogger
默认是 plain.
否
toFile
输出到的文件。默认是标准输出（控制台）
否
useFile
是否把结果输出到文件中。 true或false. 默认是"true"
否
第 6 章 在Eclipse中使用Checkstyle
目录
6.1. 下载和安装
6.2. 配置方法
6.3. 使用
6.4. 常见问题
6.1. 下载和安装
下载在Checkstyle的 Checkstyle主页 ，有一个插件列表。 截止到2008-02-26，Eclipse插件的可用的地址是：EclipseCS 和 Checkclipse
本节讲解的是后者，也就是Checkclipse。
Checkclipse安装的方法同其他的Eclipse插件一样。不清楚的朋友可以看这篇文章：Eclipse基础－－使用links方式安装Eclipse插件 。links方式 适用于Eclipse3.0, 3.1, 3.2 和 Europa
6.2. 配置方法
当Checkclipse成功安装后，在"window->Preferences"中可以看到checkclipse的选项， 如 图 6.1 “成功安装Checkclipse后的Preferences窗口” 所示。
成功安装Checkclipse后的Preferences窗口
图 6.1. 成功安装Checkclipse后的Preferences窗口
Checkclipse有两个渠道可以进行配置，一个是全局的，一个是单个项目(Project)的。全局的可以在整个Eclipse的workbench中生效， 而单个项目的配置可以在指定的项目中生效，它优先于全局的配置。
对于单个项目：右键点某个项目，然后选择"Properties"就可以看到Checkclipse的窗口。在"Configuration"标签中，"Enable Checkstyle"一行前面打勾， 然后在"Checkstyle Configuration File:" 一行中选择你的Checkstyle配置文件就可以了。
如 图 6.2 “配置单个项目的Checkclipse” 所示。
配置单个项目的Checkclipse
图 6.2. 配置单个项目的Checkclipse
对于全局的设置："window->preferences"就可以看到。设置方法跟单个项目的设置是一样的。
经过上面的设置，Checkclipse就可以使用了。如果你想设置需要被检查的文件名，那么就在"File Filter"标签中修改被包含的文件。可以使用"Add","Remove","Change"等按钮进行编辑。 Included Resources 中显示了被检查的文件清单。
如 图 6.3 “设置单个项目的Checkclipse的文件过滤器(file filter)” 所示。
设置单个项目的Checkclipse的文件过滤器(file filter)
图 6.3. 设置单个项目的Checkclipse的文件过滤器(file filter)
[小心] 注意
除非很有必要，否则不要改FileFilter。使用默认的就满足95%的情况。
官方帮助可以在Eclipse的"Help-> HelpeContents" 中的"Checkclipse - Checkstyle Plugin" 中找到。内容还是很详尽的。
6.3. 使用
Checkclipse的使用非常简单，它的每次检查是跟随Eclipse的"Build Project"一起进行的。如果有错误，会显示在"Problems"子窗口中。 另外，对于默认的检查，错误是Warning级的，对于设置了配置文件后的检查，错误都是Error级的。 看一下
加入OpenDoc前的 预览版。
申 思维
1.0
版权 © 2008 申思维
本文根据Checkstyle4.3 英文官方文档而来。我打算发布成OpenDoc, 欢迎大家给我来信，多提意见！谢谢
目录
1. 前言
1. 介绍
1.1. 概述
1.2. 特点
1.3. 下载
2. N分钟入门
3. 常用的检查
3.1. 典型的配置文件
4. 用的最多的20%功能
5. 在Ant中使用Checkstyle
5.1. N分钟极速入门
5.2. 安装与配置
5.3. 典型例子
5.4. checkstyle任务的参数
5.5. 可以嵌套的ant元素
6. 在Eclipse中使用Checkstyle
6.1. 下载和安装
6.2. 配置方法
6.3. 使用
6.4. 常见问题
7. 各种检查
7.1. 如何配置检查
7.2. JavaDoc注释
7.2.1. 类和接口的javadoc
7.2.2. 方法的javadoc
7.2.3. 方法的javadoc
7.2.4. 变量的javadoc
7.3. 命名约定
7.3.1. 模块一览
7.3.2. 注意
7.4. 文件头
7.5. Imports
7.5.1. import中避免星号"*"
7.5.2. 没用的import
7.6. 长度限制
7.6.1. 文件长度
7.6.2. 每行长度
7.6.3. 方法长度
7.6.4. 方法的参数个数
7.7. 空格
7.7.1. 方法名与左边圆括号之间
7.7.2. 圆括号附近的空格
7.7.3. 类型转换中圆括号附近的空格
7.7.4. 对"Tab"的检查
7.7.5. 特定符号后的空格
7.8. 关键字
7.8.1. 关键字的出现顺序
7.8.2. 多余的关键字
7.9. 对区域(empty block)的检查
7.9.1. 空白区域
7.9.2. 对左侧括号{ 的检查（略）
7.9.3. 需要括号的区域
7.9.4. 对右侧括号} 的检查（略）
7.9.5. 不必要的括号
7.10. 编码的检查
7.10.1. 数组尾巴的逗号
7.10.2. 避免内联(inline)条件判断
7.10.3. override的equals方法
7.10.4. 空语句(statement)
7.10.5. equals和hashCode方法
7.10.6. 应该声明成final的局部变量
7.10.7. 不合适的初始化
7.10.8. 不合适的token
7.10.9. 内部赋值语句
7.10.10. 魔法数
7.10.11. 丢了default分支的switch
7.10.12. 被更改的循环控制变量
7.10.13. 多余的throw
7.10.14. 未被简化的条件表达式
7.10.15. 未被简化的布尔返回值
7.10.16. 字符串(String)的比较
7.10.17. 嵌套的if 层次
7.10.18. 嵌套的try 层次
7.10.19. 调用父类的clone
7.10.20. 父类的finalize
7.10.21. 不合理的catch
7.10.22. 不合理的throws
7.10.23. package 声明
7.10.24. JUnitTestCase
7.10.25. return 语句的数量
7.10.26. 声明的顺序
7.10.27. 参数被赋值
7.10.28. 详尽的变量初始化
7.10.29. switch语句的default位置排在最后
7.10.30. 丢失的构造函数
7.10.31. switch中错误分支。
7.10.32. 多个内容相同的字符串变量
7.10.33. 同一行禁止声明多个变量
7.10.34. 不使用this
7.10.35. 不必要的圆括号
7.11. Class的设计
7.11.1. 可见的修改方法
7.11.2. Final class
7.11.3. Interfacels Type
7.11.4. 隐藏工具类的构造方法
7.11.5. 方便继承(extention)而进行的设计
7.11.6. throws的数量
7.12. 重复的代码
7.12.1. StrictDuplicateCode 严格的重复代码检查
7.13. 各种量度
7.13.1. 布尔表达式的复杂度
7.13.2. 类数据的抽象耦合
7.13.3. 类的分散复杂度
7.13.4. 函数的分支复杂度
7.13.5. Npath复杂度
7.14. 杂项
7.14.1. 禁止使用的表达式
7.14.2. 文件结尾的回车
7.14.3. Todo注释
7.14.4. 翻译属性文件
7.14.5. 没有被注释掉的Main函数
7.14.6. 大写的L
7.14.7. 声明数组的风格
7.14.8. final型的参数
7.14.9. 缩进
7.14.10. 与代码同行的注释
7.14.11. 必须出现的字符串
术语表
参考书目
插图清单
2.1. 测试如何使用checkstyle的项目
2.2. 开启Checkstyle
2.3. 代码窗口中的错误提示
2.4. Problems窗口中的错误提示
2.5. 增加了class的注释后的效果图
2.6. 使用自定义的Checkstyle配置文件
2.7. 定制配置的检查结果
2.8. 修正后的定制配置的检查结果
5.1. 在Ant环境下Checkstyle的所须文件
5.2. Ant下Checkstyle检查正确的结果
5.3. Ant下Checkstyle检查错误的结果
6.1. 成功安装Checkclipse后的Preferences窗口
6.2. 配置单个项目的Checkclipse
6.3. 设置单个项目的Checkclipse的文件过滤器(file filter)
6.4. 出错信息中的检查名
6.5. Problems的过滤器中配置Checkclipse。
6.6. 右键菜单中的checkstyle选项
表格清单
5.1. checkstyle任务属性表
5.2. formatter元素的属性
7.1. 命名约定检查模块一览表
7.2. WhitespaceAfter 属性列表
7.3. 重复代码插件的特性摘要：
7.4. GenericIllegalRegexp的属性列表
7.5. NewlineAtEndOfFile的属性列表
7.6. Indentation的属性列表
前言
Preface
Checkstyle是非常优秀的代码规范检查软件，可以大幅的提高代码质量， 当项目的开发人员比较多时，用它来统一代码风格是很有必要的。
本文的写作，是由于公司的质量管理部门对代码格式进行了要求。 在网上也没有发现有比较详细全面的中文文档。所以参考Checkstyle4.3的官方文档写就。
有个比较神奇的20%-80%规律是这样说的：一本书，用的最多的只是20%的内容，它的出现几率是80%； 而剩下的80%内容，被使用的不到20%。这个规律也同样适用在其他东东上。只是数据上稍有差异。 所以我特意安排了 第 4 章 用的最多的20%功能 ，作为典型的使用方法。
对于赶时间的朋友，也可以直接看第 2 章 N分钟入门 ，可以让你在最快的时间内入门。 对于时间充沛的朋友，建议多看看文档。因为作者一再的强调“it is worth reading the documentation”。
第 5 章 在Ant中使用Checkstyle 说明了在ant下的用法。第 6 章 在Eclipse中使用Checkstyle 说明了Eclipse的插件Checkclipse的用法。
对于初次接触代码规范的朋友，我安排了第 3 章 常用的检查 ，里面是个人以为满足大多数公司要求的检查，包括一个配置文件。
第 7 章 各种检查 是各种检查的详细用法，读起来比较枯燥，建议象查字典那样有需要时翻阅，所以放在最后。
[小心] 欢迎意见
为了加入OpenDoc , 欢迎各位朋友指出文档中的任何错误和不足，也可以给我任何意见。请Email给我：shensiwei(at)sina.com
希望本文对您有用。谢谢！
第 1 章 介绍
Introduction
目录
1.1. 概述
1.2. 特点
1.3. 下载
1.1. 概述
Checksytle 是一款代码格式检查工具。它可以根据设置好的编码规则来检查代码。 比如符合规范的变量命名，良好的程序风格等等。如果你的项目经理开会时说，“我希望我们写出来的代码就象一个人写的！” 时，用Checkstyle绝对是正确选择。:)
本文档就是在4.3的基础上完成。截止到2008-02-22，最新的版本是4.4。
需要强调的是，Checkstyle只能做检查，而不能做修改代码。
[小心] 提醒
想修改代码格式，请使用Jalopy. 它和Checkstyle配合使用非常合适。
1.2. 特点
Checkstyle的配置性极强，你可以只检查一种规则，也可以检查三十，四十种规则。可以使用Checkstyle自带的规则， 也可以自己增加检查规则。（这点跟 Ant 自定义target比较象）
支持几乎所有主流IDE，包括 Eclipse , IntelliJ, NetBeans, JBuilder 等11种。
1.3. 下载
最新的发布版本在 ： 这里
4.4使用了SVN，关闭了CVS。SVN在 这里
各种插件下载，见 Checkstyle主页 中的列表。
第 2 章 N分钟入门
extreme learning
让您在几分钟之内了解Checkstyle的大致用法。适合赶时间的朋友。假设您已经安装好了Checkstyle的Eclipse插件。
[小心] 测试
欢迎在阅读下一行之前，记录下当前的时间，然后在读完本节之后，算算您用了多少时间。 如果方便，请将您用的时间告诉我，谢谢:)
1.
首先，我们建立一个eclipse的项目：test_checkstyle。包含一个源文件夹：src，一个目标生成文件夹 eclipse_build. 如 图 2.1 “测试如何使用checkstyle的项目” 所示。
测试如何使用checkstyle的项目
图 2.1. 测试如何使用checkstyle的项目
2.
在项目中开启Checkstyle: 打开该project的属性，点中左侧的Checkclipse后，将"Enable Checkstyle"前面打上勾。 如 图 2.2 “开启Checkstyle” 所示。
开启Checkstyle
图 2.2. 开启Checkstyle
3.
建立一个测试用的Class: 比如SomeClassToBeChecked，内容如下：
/*
* Copyright (c) 2001-2008 Beijing BidLink Info-Tech Co., Ltd.
* All rights reserved.
* Created on 2008-2-22
*
* $Id: learn_in_5_min.xml,v 1.3 2008/03/03 03:43:44 Administrator Exp $
*/
package test;
public class SomeClassToBeChecked {
}
只有一个头部注释，没有方法，啥啥都没有。
4.
用Checkstyle检查它：右键点项目名，选择"Build Project"，会把src文件夹进行编译，把class文件放到eclpise_build中。 结束之后，我们可以看到： 图 2.3 “代码窗口中的错误提示” 中的代码第10行处，有一个叹号，把鼠标移上去就会出现 提示"Missing a Javadoc comment."
代码窗口中的错误提示
图 2.3. 代码窗口中的错误提示
同时，在Problems窗口中也有提示，如 图 2.4 “Problems窗口中的错误提示” 所示。
Problems窗口中的错误提示
图 2.4. Problems窗口中的错误提示
5.
修改代码：既然提示说缺少了Javadoc注释，我们就把它加上。 如 图 2.5 “增加了class的注释后的效果图” 所示。
增加了class的注释后的效果图
图 2.5. 增加了class的注释后的效果图
然后重新编译，可以看出，Warning没有了。检查通过。
[小心] 注意
上面的很简单是吧？恩，我也这么觉得。但别走！如果以为这样就可以用Checkstyle， 那你就错了。你可以试一下用同样的方式来编译一个项目，会发现根本是Warning满天飞。为什么？因为Checkstyle自带的检查非常变态， 随便一个项目都可以弄出几千个Warning。所以，想用它，一定要使用自己的定制检查。:)
6.
定制检查：Checkstyle没有图形化的定制器，所以需要手工修改配置文件。比如，我们的代码需要符合下列规则：
*
长度方面：文件长度不超过1500行，每行不超过120个字，方法不超过60行.
*
命名方面：类名不能小写开头，方法名不能大写开头，常量不能有小写字母。
*
编码方面：不能用魔法数(Magic Number），if最多嵌套3层。
那么，我们的检查配置文件（如命名成 my_check.xml ） 应该是这样的：
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC
"-//Puppy Crawl//DTD Check Configuration 1.2//EN"
"http://www.puppycrawl.com/dtds/configuration_1_2.dtd">
<module name="Checker">
<module name="TreeWalker">
<!-- 长度方面的检查 -->
<!-- 文件长度不超过1500行 -->
<module name="FileLength">
<property name="max" value="1500"/>
</module>
<!-- 每行不超过120个字-->
<module name="LineLength">
<property name="max" value="120"/>
</module>
<!-- 方法不超过60行 -->
<module name="MethodLength">
<property name="tokens" value="METHOD_DEF"/>
<property name="max" value="60"/>
</module>
<!-- 命名方面的检查，它们都使用了Checkstyle默认的规则。 -->
<!-- 类名(class 或interface) 的检查 -->
<module name="TypeName"/>
<!-- 方法名的检查 -->
<module name="MethodName"/>
<!-- 常量名的检查 -->
<module name="ConstantName"/>
<!-- 编码方面的检查 -->
<!-- 不能用魔法数 -->
<module name="MagicNumber"/>
<!-- if最多嵌套3层 -->
<module name="NestedIfDepth">
<property name="max" value="3"/>
</module>
</module>
</module>
可以看出，想增加一个检查，就是增加一个<module/>结点。具体的结点内容在后面的文档都会写明。
7.
让Checkstyle使用指定的检查配置文件：打开项目属性，在Checkclipse中的"Checkstyle Configuration File" 一栏中 选定我们的配置文件，然后确定。如 图 2.6 “使用自定义的Checkstyle配置文件” 所示。
使用自定义的Checkstyle配置文件
图 2.6. 使用自定义的Checkstyle配置文件
然后重新编译项目，就会发现，Checkstyle的规则如我们所愿：只检查我们在文件中配置的几项。并且它们是以"Error"级别进行提示，而不是默认检查时出现的"Warning"级别。 比如，我们把一个方法中，增加4层嵌套（共5个if），并将方法名大写，就会出现 图 2.7 “定制配置的检查结果” :
定制配置的检查结果
图 2.7. 定制配置的检查结果
可以看到，出现了两个Error: 方法名的"Name xx must match pattern..." 和if嵌套的"Nested if-else depth is 4..."。 把它们都改过来，程序就好了。
8.
代码的修正：依照上面的例子，把方法名小写，if循环嵌套3层，然后重新编译，OK。如： 图 2.8 “修正后的定制配置的检查结果”
修正后的定制配置的检查结果
图 2.8. 修正后的定制配置的检查结果
到这里就结束了。看明白了吗？欢迎给我意见，以及看到这里所用的时间。:)
想在N分钟内了解ant下checkstyle的使用方法，请看 第 5.1 节 “N分钟极速入门”
第 3 章 常用的检查
目录
3.1. 典型的配置文件
Checkstyle自带了两个配置文件：checkstyle_checks.xml 和 sun_checks.xml。前者是checkstyle作者定义的，后者是严格符合Sun编码规范 的。 可惜它们的检查太过严格，任何一个项目都会搞出上千个Warning来。
所以这里提供了一个配置文件，包含了比较常用的检查，去掉了对空格位置，大括号位置等国内不注重的内容， 建议个人使用。
如果是公司使用，建议把它再精简些。因为对公司来说，这个配置文件还是比较苛刻的。
3.1. 典型的配置文件
下面是一个典型的checkstyle配置文件，应该适合于大多数情况的要求。每个检查前的注释说明了它的作用。本文的PDF文档 无法正常显示其中的汉字，建议本节使用HTML版查看。:)
<!DOCTYPE module PUBLIC
"-//Puppy Crawl//DTD Check Configuration 1.2//EN"
"http://www.puppycrawl.com/dtds/configuration_1_2.dtd">
<module name="Checker">
<!-- 重复代码的检查，超过8行就认为重复，UTF-8格式
本检查一定要放在"TreeWalker"节点前，否则在
Checkclipse中会无法使用。(在ant下可以)
-->
<module name="StrictDuplicateCode">
<property name="min" value="8"/>
<property name="charset" value="UTF-8"/>
</module>
<module name="TreeWalker">
<!-- javadoc的检查 -->
<!-- 检查所有的interface和class -->
<module name="JavadocType"/>
<!-- 检查所有方法的javadoc，可以不声明RuntimeException -->
<module name="JavadocMethod">
<property name="allowUndeclaredRTE" value="true"/>
</module>
<!-- 检查某个变量的javadoc -->
<module name="JavadocVariable"/>
<!-- 命名方面的检查，它们都使用了Sun官方定的规则。 -->
<!-- 类名(class 或interface) 的检查 -->
<module name="TypeName"/>
<!-- 变量的检查 -->
<module name="MemberName"/>
<!-- 方法名的检查 -->
<module name="MethodName"/>
<!-- 方法的参数名 -->
<module name="ParameterName "/>
<!-- 常量名的检查 -->
<module name="ConstantName"/>
<!-- 长度方面的检查 -->
<!-- 文件长度不超过1500行 -->
<module name="FileLength">
<property name="max" value="1500"/>
</module>
<!-- 每行不超过120个字-->
<module name="LineLength">
<property name="max" value="120"/>
</module>
<!-- 方法不超过30行 -->
<module name="MethodLength">
<property name="tokens" value="METHOD_DEF"/>
<property name="max" value="30"/>
</module>
<!-- 方法的参数个数不超过3个。 -->
<module name="ParameterNumber">
<property name="max" value="3"/>
</module>
<!-- 多余的关键字 -->
<module name="RedundantModifier"/>
<!-- 对区域的检查 -->
<!-- 不能出现空白区域 -->
<module name="EmptyBlock"/>
<!-- 所有区域都要使用大括号。 -->
<module name="NeedBraces"/>
<!-- 多余的括号 -->
<module name="AvoidNestedBlocks">
<property name= "allowInSwitchCase"
value="true"/>
</module>
<!-- 编码方面的检查 -->
<!-- 不许出现空语句 -->
<module name="EmptyStatement"/>
<!-- 每个类都实现了equals()和hashCode() -->
<module name="EqualsHashCode"/>
<!-- 不许使用switch -->
<module name="IllegalToken">
<property name="tokens"
value="LITERAL_SWITCH"/>
</module>
<!-- 不许内部赋值 -->
<module name="InnerAssignment"/>
<!-- 绝对不能容忍魔法数 -->
<module name="MagicNumber"/>
<!-- 循环控制变量不能被修改 -->
<module name="ModifiedControlVariable"/>
<!-- 多余的throw -->
<module name="RedundantThrows"/>
<!-- 不许使用未被简化的条件表达式 -->
<module name="SimplifyBooleanExpression"/>
<!-- 不许使用未被简化的布尔返回值 -->
<module name="SimplifyBooleanReturn"/>
<!-- String的比较不能用!= 和 == -->
<module name="StringLiteralEquality"/>
<!-- if最多嵌套3层 -->
<module name="NestedIfDepth">
<property name="max" value="3"/>
</module>
<!-- try最多被嵌套1层 -->
<module name="NestedTryDepth"/>
<!-- clone方法必须调用了super.clone() -->
<module name="SuperClone"/>
<!-- finalize 必须调用了super.finalize() -->
<module name="SuperFinalize"/>
<!-- 不能catch java.lang.Exception -->
<module name="IllegalCatch">
<property name="illegalClassNames"
value="java.lang.Exception"/>
</module>
<!-- JUnitTestCase 的核心方法存在。 -->
<module name="JUnitTestCase"/>
<!-- 一个方法中最多有3个return -->
<module name="ReturnCount">
<property name="max" value="3"/>
</module>
<!-- 不许对方法的参数赋值 -->
<module name="ParameterAssignment"/>
<!-- 不许有同样内容的String -->
<module name="MultipleStringLiterals"/>
<!-- 同一行不能有多个声明 -->
<module name="MultipleVariableDeclarations"/>
<!-- 各种量度 -->
<!-- 布尔表达式的复杂度，不超过3 -->
<module name="BooleanExpressionComplexity"/>
<!-- 类数据的抽象耦合，不超过7 -->
<module name="ClassDataAbstractionCoupling"/>
<!-- 类的分散复杂度，不超过20 -->
<module name="ClassFanOutComplexity"/>
<!-- 函数的分支复杂度，不超过10 -->
<module name="CyclomaticComplexity"/>
<!-- NPath复杂度，不超过200 -->
<module name="NPathComplexity"/>
<!-- 杂项 -->
<!-- 禁止使用System.out.println -->
<module name="GenericIllegalRegexp">
<property name="format" value="System\.out\.println"/>
<property name="ignoreComments" value="true"/>
</module>
<!-- 不许使用与代码同行的注释 -->
<module name="TrailingComment"/>
</module>
<!-- 检查翻译文件 -->
<module name="Translation"/>
</module>
第 4 章 用的最多的20%功能
Core 20%
这里列出了个人以为的20%的最常用功能。欢迎您把自己认为的20%发过来，我会进行一个统计，及时更新本节。
*
命名符合规范
类，方法，成员变量等等的命名，一般要遵循 Sun编码规范 。
*
编码中的长度问题
类，方法的长度不应该过大。
*
编码习惯的检查
检查代码中是否有过多的if嵌套，魔法数，switch丢失的default, 复杂的条件表达式等。
*
重复的代码
如果两个代码段出现了一定行数的严格重复，就判定它们已经重复。
第 5 章 在Ant中使用Checkstyle
目录
5.1. N分钟极速入门
5.2. 安装与配置
5.3. 典型例子
5.4. checkstyle任务的参数
5.5. 可以嵌套的ant元素
如果您赶时间，请看第 5.1 节 “N分钟极速入门” 。:)
5.1. N分钟极速入门
（请打开一个秒表记时，谢谢）
需要"checkstyle-all-4.3.jar"，该jar文件包含了checkstyle所用的几乎所有类。
需要有一个指定的配置文件，比如当前项目中的"./config/my_check.xml"。
另外，把checkstyle-all.jar放在一个合适的目录中，比如"./lib"。
最后，设置Ant的输出文件夹为"./ant_build" 如 图 5.1 “在Ant环境下Checkstyle的所须文件” 所示。
在Ant环境下Checkstyle的所须文件
图 5.1. 在Ant环境下Checkstyle的所须文件
ant的配置文件中需要指定一个taskdef来定义checkstyle任务, 然后在checkstyle任务中指定配置文件(config属性)， 和需要被检查的文件夹(fileset)。本例使用的ant文件是这样的：
<?xml version="1.0" ?>
<project>
<taskdef resource="checkstyletask.properties"
classpath="./lib/checkstyle-all-4.3.jar"/>
<target name="my_check">
<checkstyle config="config/my_check.xml">
<fileset dir="src" includes="**/*.java"/>
</checkstyle>
</target>
</project>
如果checkstyle检查通过，则会看到"BUILD SUCCESSFUL"， 如 图 5.2 “Ant下Checkstyle检查正确的结果” 所示。
Ant下Checkstyle检查正确的结果
图 5.2. Ant下Checkstyle检查正确的结果
如果checkstyle检查到出错，就会输出错误信息，包括所有检查到的错误。比如，我们把一个方法的长度超过60，方法名大写，就会看到出错信息，并且"BUILD FAILED" 如 图 5.3 “Ant下Checkstyle检查错误的结果” 所示。
Ant下Checkstyle检查错误的结果
图 5.3. Ant下Checkstyle检查错误的结果
本节结束，欢迎您把看明白本节所用的时间通过Email告诉我。因为我想知道标题中的 "N" 是多少。 :)谢谢。
5.2. 安装与配置
其实本节内容已经被包含在了 第 5.1 节 “N分钟极速入门” 中，就是拥有checkstyle-all-4.3.jar 这个文件，并且在 ant的配置文件中进行task声明，如：
<taskdef resource="checkstyletask.properties"
classpath="./lib/checkstyle-all-4.3.jar"/>
然后通过<checkstyle/>任务来运行。
5.3. 典型例子
本节假定使用checkstyle任务的前提条件都已满足。
使用my_check.xml文件，对src目录下的所有java文件进行检查:
<checkstyle config="config/my_check.xml">
<fileset dir="src" includes="**/*.java"/>
</checkstyle>
使用my_check.xml文件，对src目录下的所有java文件进行检查，并且把出错的信息分别写到两个文件中:ant_build目录下的 checkstyle_errors.txt 和checkstyle_errors.xml中:
<checkstyle config="config/my_check.xml">
<fileset dir="src" includes="**/*.java"/>
<formatter type="plain" toFile="ant_build/checkstyle_errors.txt"/>
<formatter type="xml" toFile="ant_build/checkstyle_errors.xml"/>
</checkstyle>
值得一提的是，xml格式的文件里面把错误的信息格式弄的很清晰，调试起来比较方便。如果需要的话可以比较方便的扩展到诸如cruisecontrol里。
使用定义了package的文件：
<checkstyle config="config/my_check.xml"
packageNamesFile="myPackageNames.xml"
file="src/test/SomeClass.java"/>
5.4. checkstyle任务的参数
checkstyle任务的参数如 表 5.1 “checkstyle任务属性表” 所示。
表 5.1. checkstyle任务属性表
名字 描述 是否必须
file
被检查的文件。
一个file或者fileset
config
Checkstyle的配置文件。配置文件的使用方法见：第 7.1 节 “如何配置检查”
config或configURL必具其一
configURL
指定了Checkstyle配置文件的URL。用法
config或configURL必具其一
properties
定义了ant使用到的属性的文件。
否
packageNamesFile
定义了Checkstyle配置文件中检查的package name的文件。
否
failOnViolation
有violation时是否继续检查，默认是"true"
否
failureProperty
The name of a property to set in the event of a violation.
否
maxErrors
停止build前允许出现的"Error"的最大数目。默认是"0"
否
maxWarnings
停止build前允许出现的"Warning"的最大数目。默认是"2147483647"，也就是Integer.MAX_VALUE.
否
classpath
类路径，默认是当前使用的classpath。
否
classpathref
类路径的引用。
否
5.5. 可以嵌套的ant元素
checkstyle任务中可以前台以下元素: <filese>, <classpath>, <formatter> 以及<property>
formatter元素的属性如 表 5.2 “formatter元素的属性” 所示。
表 5.2. formatter元素的属性
名字 描述 是否必须
type
结果的输出方式，可用的值是：
plain :使用了 DefaultLogger
xml : 使用了XMLLogger
默认是 plain.
否
toFile
输出到的文件。默认是标准输出（控制台）
否
useFile
是否把结果输出到文件中。 true或false. 默认是"true"
否
第 6 章 在Eclipse中使用Checkstyle
目录
6.1. 下载和安装
6.2. 配置方法
6.3. 使用
6.4. 常见问题
6.1. 下载和安装
下载在Checkstyle的 Checkstyle主页 ，有一个插件列表。 截止到2008-02-26，Eclipse插件的可用的地址是：EclipseCS 和 Checkclipse
本节讲解的是后者，也就是Checkclipse。
Checkclipse安装的方法同其他的Eclipse插件一样。不清楚的朋友可以看这篇文章：Eclipse基础－－使用links方式安装Eclipse插件 。links方式 适用于Eclipse3.0, 3.1, 3.2 和 Europa
6.2. 配置方法
当Checkclipse成功安装后，在"window->Preferences"中可以看到checkclipse的选项， 如 图 6.1 “成功安装Checkclipse后的Preferences窗口” 所示。
成功安装Checkclipse后的Preferences窗口
图 6.1. 成功安装Checkclipse后的Preferences窗口
Checkclipse有两个渠道可以进行配置，一个是全局的，一个是单个项目(Project)的。全局的可以在整个Eclipse的workbench中生效， 而单个项目的配置可以在指定的项目中生效，它优先于全局的配置。
对于单个项目：右键点某个项目，然后选择"Properties"就可以看到Checkclipse的窗口。在"Configuration"标签中，"Enable Checkstyle"一行前面打勾， 然后在"Checkstyle Configuration File:" 一行中选择你的Checkstyle配置文件就可以了。
如 图 6.2 “配置单个项目的Checkclipse” 所示。
配置单个项目的Checkclipse
图 6.2. 配置单个项目的Checkclipse
对于全局的设置："window->preferences"就可以看到。设置方法跟单个项目的设置是一样的。
经过上面的设置，Checkclipse就可以使用了。如果你想设置需要被检查的文件名，那么就在"File Filter"标签中修改被包含的文件。可以使用"Add","Remove","Change"等按钮进行编辑。 Included Resources 中显示了被检查的文件清单。
如 图 6.3 “设置单个项目的Checkclipse的文件过滤器(file filter)” 所示。
设置单个项目的Checkclipse的文件过滤器(file filter)
图 6.3. 设置单个项目的Checkclipse的文件过滤器(file filter)
[小心] 注意
除非很有必要，否则不要改FileFilter。使用默认的就满足95%的情况。
官方帮助可以在Eclipse的"Help-> HelpeContents" 中的"Checkclipse - Checkstyle Plugin" 中找到。内容还是很详尽的。
6.3. 使用
Checkclipse的使用非常简单，它的每次检查是跟随Eclipse的"Build Project"一起进行的。如果有错误，会显示在"Problems"子窗口中。 另外，对于默认的检查，错误是Warning级的，对于设置了配置文件后的检查，错误都是Error级的。 看一下