- 浏览: 853492 次
- 性别:
- 来自: 北京
-
文章分类
最新评论
-
贝塔ZQ:
读取excel文件,插件pageoffice也可以实现。
POI读写Excel文件(转)- - -
springmvc-freemarker:
java开源项目源码实例下载
java开源项目源代码 -
xuning2516:
第一种方法是个死循环啊。。。
Java NIO 拷贝文件(使用compact) -
u012046856:
...
SessionFactory.getCurrentSession与openSession的区别 -
Season_Wang:
赞一个呀,挺实用的
java swing 中的FileDialog
写道
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级的。 看一下
发表评论
-
Maven 2和Checkstyle
2008-07-23 10:38 4454Maven 2和Checkstyle 200 ... -
checkstyle 模板文件
2008-07-09 10:32 3360<?xml version="1.0" ... -
Jalopy在Eclipse下的使用
2008-07-08 13:37 1061http://sg552.iteye.com/blog/170 ... -
Checkstyle
2008-07-08 13:31 1462eclipse plugin download: http: ... -
checkstyle
2008-07-03 20:13 1153http://checkstyle.sourceforge.n ...
相关推荐
这个"Checkstyle_4.3_中文手册 pdf"是Checkstyle 4.3版本的中文指南,对于理解并使用Checkstyle进行代码质量管理非常有帮助。 在Checkstyle 4.3版本中,主要包含以下知识点: 1. **Checkstyle基础**:Checkstyle...
"Checkstyle 4.3 中文手册"是Checkstyle的一个较旧版本的手册,但它仍然提供了大量有价值的信息。手册中会包含每个检查项的详细描述、配置选项以及如何解决违规的建议。比如,它可能会介绍`TreeWalker`检查器,这是...
压缩包中的`Checkstyle_4.3_-K.pdf`可能是一个CheckStyle的用户手册或指南,详细阐述了4.3版本的特性和使用方法,包括配置规则、运行检查、集成到IDE等。用户可以通过这份文档深入理解CheckStyle的各项功能,并学习...
19考试真题最近的t44.txt
清华大学第三弹:普通人如何抓住DeepSeek红利
Python环境下的滚动轴承故障诊断优化算法:基于改进WDCNN的一维卷积神经网络与LSTM融合的时序信号处理研究,Python环境中基于改进WDCNN与LSTM融合的滚动轴承故障诊断方法研究——优化卷积核大小,提升诊断准确率并加速收敛速度的应用,Python环境下一种基于WDCNN的滚动轴承故障诊断方法 算法采用pytorch深度学习模块,对WDCNN进行改进,搭建了卷积核大小逐层递减的一维卷积神经网络,并减少了卷积层数量,达到了98%以上的诊断准确率,同时有着较快的收敛速度。 另外,针对时序信号的特点,将长短时记忆网络(LSTM)与搭建的一维卷积神经网络结合,提高分类准确率至99%以上,但收敛速度较单一的卷积神经网络较慢。 算法可迁移至金融时间序列,地震信号,语音信号,声信号,生理信号(ECG,EEG,EMG)等一维时间序列信号。 ,基于WDCNN的故障诊断方法; 卷积神经网络; 算法改进; 高诊断准确率; 收敛速度快; LSTM结合; 一维时间序列信号; 金融、地震、语音、生理信号诊断,Python下改进WDCNN的滚动轴承故障诊断法:深度学习提升诊断准确率与收敛速度
基于遗传算法优化的机器学习模型分类预测与回归分析技术概览:SVM、LSTM等算法应用,遗传算法优化机器学习模型在分类、回归与时序预测中的应用(支持SVM、RF等)matlab代码实践,遗传算法优化用于分类 回归 时序预测 遗传算法优化支持向量机SVM,最小二乘支持向量机LSSVM,随机森林RF,极限学习机ELM,核极限学习机KELM,深度极限学习机DELM,BP神经网络,长短时记忆网络 LSTM,Bilstm,GRU,深度置信网络 DBN,概率神经网络PNN,广义神经网络GRNN..... 以上有分类预测回归预测时序预测 matlab代码,可直接替数据使用,简单操作易上手。 ,遗传算法优化; 分类预测; 回归预测; 时序预测; 支持向量机SVM; 最小二乘支持向量机LSSVM; 随机森林RF; 极限学习机ELM; 深度极限学习机DELM; 神经网络操作; Matlab代码,遗传算法优化多种机器学习模型在分类、回归与时序预测中的应用
《多元系列污水处理及石油化工设备三维模型库:可编辑装配体与零部件模型集》,优质专业设备模型集萃:90套管道设备、石油化工与污水处理设备三维模型,可编辑修改尺寸,装配体模型与零部件一应俱全,共90套左右各类污水处理设备三维模型,管道设备三维模型,石油化工设备三维模型。 sw打开,大部分是可以编辑修改尺寸的。 有装配体模型,有零部件模型。 ,污水处理设备模型; 管道设备模型; 石油化工设备模型; 可编辑修改尺寸; 装配体模型; 零部件模型。,90套污水处理与石油化工设备三维模型库:可编辑装配体与零部件模型大全
2023-04-06-项目笔记-第四百一十八阶段-课前小分享_小分享1.坚持提交gitee 小分享2.作业中提交代码 小分享3.写代码注意代码风格 4.3.1变量的使用 4.4变量的作用域与生命周期 4.4.1局部变量的作用域 4.4.2全局变量的作用域 4.4.2.1全局变量的作用域_1 4.4.2.416局变量的作用域_416- 2025-02-23
**基于主从博弈算法的电热综合能源系统动态定价与能量管理:深度创新与高效求解的MATLAB代码实现**,MATLAB代码:基于主从博弈算法的电热综合能源系统智能动态定价与高效能量管理策略研究,MATLAB代码:基于主从博弈的电热综合能源系统动态定价与能量管理 关键词:主从博弈 电热综合能源 动态定价 能量管理 参考文档:自编文档,完全复现 仿真平台:MATLAB 平台 优势:代码具有一定的深度和创新性,注释清晰,非烂大街的代码,非常精品 主要内容:代码主要做的是电热综合能源系统的动态定价问题,采用是主从博弈方法,上领导者问题上,以综合能源系统整体的收益作为目标函数,考虑电价以及热价等相关约束,在下层跟随者模型上,以用户用能满意度最高为目标函数,构建了领导者-跟随者Stackelberg博弈模型,同时还考虑了系统的功率平衡条件以及热能平衡条件等约束,模型的上层求解采用粒子群算法,下层求解采用CPLEX求解器,考虑该代码具有一定的创新性,适合新手学习以及在此基础上进行拓展,代码质量非常高 ,主从博弈; 电热综合能源; 动态定价; 能量管理; Stackelberg博弈模型; 粒子群算
修复 "保存'/opt/rr'的修改" 后 主菜单锁死问题. 修复 trivial 插件的语法错误. 修复 open-vm-tools 套件 缺失的 SOCKETS 驱动. 添加 vmtools 插件, 包含 qemu-ga & open-vm-tools. 4.1. 该插件会自动判断环境并启用对应的功能, 物理机也不用刻意删除该插件. 4.2. 新安装用户会默认选中, 升级用户如需要请手动添加该插件. 4.3. 如启用该插件, 请不要再在系统中安装套件. 修复 wireless 插件. 5.1. 修复 RR 下无线网络 IP 显示和刷新问题. 5.2. 修复 RR 下设置 SSID&PSK 后 DSM 下不驱动的问题. 5.3. 同步 RR 下的 SSID&PSK 到 DSM 下. 5.4. 修复 junior 模式下无线网络的支持, 已支持 无线网卡的 DSM 系统安装. (暂时不支持 intel 无线网卡) 5.5. wpa_supplicant.conf 文件位于引导盘第一个分区根目录, 纯无线环境可手动放置该文件后其启动引导.
培训课件 -我是如何教创新创业及职涯设计课.pptx
流量专网售前5G解决方案模板.docx
Simulink仿真模型下的混合储能控制器设计:实现功率分配、SOC均衡与高精度电流控制及母线电压补偿策略,Simulink仿真模型下的混合储能控制器设计:实现功率分配、SOC均衡与高精度电流控制及母线电压补偿,储能控制器,simulink仿真模型。 采用下垂控制实现蓄电池超级电容构成的混合储能功率分配、SOC均衡控制、考虑线路阻抗情况下提高电流分配精度控制、母线电压补控制。 ,核心关键词: 1. 储能控制器 2. 下垂控制 3. 混合储能功率分配 4. SOC均衡控制 5. 线路阻抗 6. 电流分配精度控制 7. 母线电压补控制 用分号分隔的关键词结果为: 储能控制器;下垂控制;混合储能功率分配;SOC均衡控制;线路阻抗;电流分配精度控制;母线电压补控制,基于Simulink仿真的混合储能系统:下垂控制与SOC均衡策略研究
19考试真题最近的t38.txt
基于V2G技术的电动汽车实时调度策略:降低充电与网损成本,IEEE配电网验证,基于V2G技术的电动汽车实时调度策略:降低充电成本与网损的调度模型及算法实现,MATLAB代码:基于V2G技术的电动汽车实时调度策略 关键词:电动汽车 实时调度 V2G 网损 仿真平台:MATLAB YALMIP+CVX 主要内容:代码主要做的是基于V2G技术的电动汽车实时调度策略,请注意是实时调度策略而非日前调度策略,首先以降低充电成本和网损成本为目标,建立电动汽车调度模型。 然后通过构建网损灵敏度指标分析电网节点性能,基于电网负荷制定分时电价,通过潮流计算和凸优化算法实时求解得到电动汽车充放电策略。 最后以 IEEE 33 节点配电网为例验证了所提策略可以有效降低充电成本与网损成本。 基本实现文档中的算法,复现效果良好可靠 ,V2G技术; 实时调度策略; 网损; 充电成本; 优化算法; 潮流计算; 凸优化算法; IEEE 33节点配电网。,基于V2G技术的实时电动汽车调度策略:降低充电成本与网损的MATLAB仿真研究
三菱PLC焊接机智能控制参考方案:含触摸屏程序、PLC程序、伺服定位与通信控制等全套解决方案,专为精准内外径圆环物料处理设计。,三菱PLC焊接机智能控制参考方案:集成触摸屏程序、PLC编程、伺服控制与通讯技术,实现精准焊接与数据闭环管理。,三菱PLC焊接机控制参考程序。 包含触摸屏程序,PLC程序,IO表,伺服参数,通讯协议参数。 该设备由24个伺服电机、1套焊接机、2套CCD、4套扫码枪、6套位移传感器组成,plc程序有注释里面fb块也没加密,电气控制采用三菱Q系列Q06UDV型CPU,内置以太网通过TCP IP形式与上位机CCD及扫码枪通讯,两套QD77MS16定位模块控制伺服,外加QJ71C24N用于与位移传感器通过ModBus RTU协议进行串口通讯获取数据,另外运用三菱MX Conpnonet软件与上位机通讯完成与客户MES系统闭环控制,OEE数据采集并上传至客户工厂云服务器系统。 该设备组装物料小件尺寸小,为内外径相差0.79mm(圆环宽度)的小圆环,料盘为8X10的矩阵料盘,吸取较难,因此PLC自写了一套算法,采用三点设定自动运算出80个点的XY坐标,吸取成功率达99%以
一个使用node、MySql、react、reactNative、antDesign完成的一套大型订票系统,其中服务端、数据库,网页订票端、手机订票端和网页管理台.zip项目工程资源经过严格测试运行并且功能上ok,可实现复现复刻,拿到资料包后可实现复现出一样的项目,本人系统开发经验充足(全栈全领域),有任何使用问题欢迎随时与我联系,我会抽时间努力为您解惑,提供帮助 【资源内容】:包含源码+工程文件+说明等。答辩评审平均分达到96分,放心下载使用!可实现复现;设计报告也可借鉴此项目;该资源内项目代码都经过测试运行,功能ok 【项目价值】:可用在相关项目设计中,皆可应用在项目、毕业设计、课程设计、期末/期中/大作业、工程实训、大创等学科竞赛比赛、初期项目立项、学习/练手等方面,可借鉴此优质项目实现复刻,设计报告也可借鉴此项目,也可基于此项目来扩展开发出更多功能 【提供帮助】:有任何使用上的问题欢迎随时与我联系,抽时间努力解答解惑,提供帮助 【附带帮助】:若还需要相关开发工具、学习资料等,我会提供帮助,提供资料,鼓励学习进步 下载后请首先打开说明文件(如有);整理时不同项目所包含资源内容不同;项目工程可实现复现复刻,如果基础还行,也可在此程序基础上进行修改,以实现其它功能。供开源学习/技术交流/学习参考,勿用于商业用途。质量优质,放心下载使用,资源为网络商品(电子资料类)基于网络商品和电子资料商品的性质和特征不支持退款
RexVision 1.6.1机器视觉框架源码发布:基于C#与Halcon混合编程,适用于视觉检测与机械手定位等应用,插件式开发省时高效,RexVision 1.6.1机器视觉框架源码发布:基于C#与Halcon混合编程,支持多种视觉应用与手眼标定,VS2019可直接编译使用,RexVision 1.6.1,C#+Halcon机器视觉框架源码, 到手vs2019可以直接编译、 视觉检测、AOI视觉检测、机械手定位、点胶机、插件机、激光切割机、视觉螺丝机、视觉贴合机、激光焊接机、视觉裁板机……, C#联合Halcon混合编程源码,插件式开发 ,带手眼标定,相机静止和运动,支持C#脚本…能让你站在巨人的肩膀上,节省重复造轮子的时间。 ,关键词:RexVision 1.6.1; Halcon机器视觉框架; C#联合Halcon混合编程; 视觉检测; AOI视觉检测; 机械手定位; 点胶机; 插件机; 激光切割机; 视觉螺丝机; 视觉贴合机; 激光焊接机; 视觉裁板机; 手眼标定; 相机静止和运动支持; C#脚本。,基于Halcon的C#机器视觉源码,插件式开发助力自动化设备升级