配置管理工具之五checkstyleWord文档格式.docx
《配置管理工具之五checkstyleWord文档格式.docx》由会员分享，可在线阅读，更多相关《配置管理工具之五checkstyleWord文档格式.docx（24页珍藏版）》请在冰豆网上搜索。
＜/checkstyle＞
＜/target＞
6、定制CheckStyle
CheckStyle的执行基于XML配置文件，它的主要组成部分是：
Module：
整个配置文件就是一棵Module树。
根节点是CheckerModule。
Properties：
它来决定一个Module如何进行检查。
每个Module都有一个默认值，如果不满足开发需求，可以设定其它的值。
下面是一个示例：
＜modulename="
MethodLength"
＜propertyname="
max"
value="
60"
＜/module＞
它表示，如果方法或者构造函数的长度超过60行，CheckStyle就会报错。
而默认值是150行。
以下是一段CheckStyle对于Maven项目源文件的检查报告：
Method'
createExpression'
isnotdesignedforextension-needstobeabstract,finalorempty.91
UnabletogetclassinformationforJellyException.91
Linehastrailingspaces.93
Linehastrailingspaces.104
evaluate'
isnotdesignedforextension-needstobeabstract,finalorempty.113
Parametercontextshouldbefinal.113
Linehastrailingspaces.130
getExpressionText'
isnotdesignedforextension-needstobeabstract,finalorempty.131
Linehastrailingspaces.134
Linehastrailingspaces.135
toString'
isnotdesignedforextension-needstobeabstract,finalorempty.137
isSupportAntVariables'
isnotdesignedforextension-needstobeabstract,finalorempty.156
setSupportAntVariables'
isnotdesignedforextension-needstobeabstract,finalorempty.168
ParametersupportAntVariablesshouldbefinal.168
'
supportAntVariables'
hidesafield.168
isValidAntVariableName'
isnotdesignedforextension-needstobeabstract,finalorempty.183
Parametertextshouldbefinal.183
一般情况下，与IDE集成在一起使用的时候，点击出错的条目，可以跳转到相应的代码。
7、CheckStyle的最佳实践
3.1.Sun’sCodeConventions的修改
在CheckStyle的最新发布版本中，有一个对于Sun的Java编码规范的配置文件信息。
但是，其中有很多条目并不一定符合项目开发的需要。
就算是对于很多优秀的开源项目，按照这个规范来进行检查，也会出现成千上万的错误。
下面提出的一些修改意见，是从实际项目执行过程中总结出来的，可以作为大家的参考。
我们以CheckStyle3.0配置文件的顺序来介绍：
1.去除对于每个包都有一个package.html文件的限制；
＜!
--＜modulename="
PackageHtml"
/＞--＞
2.修改对于JavaDocComments的限定：
对于很多使用CodeGenerator的项目来说，需要将手写代码与生成代码、单元测试代码的检查分开进行；
3.修改对于体积大小的限制：
目前，很多显示器都是17寸，而且打印方面的限制也比以前有所改善，同时，由于代码中Factory等模式的运用，以及有意义的方法名称等约定，默认每行代码的长度（80）是远远不能满足要求；
对于方法长度等等，也应该根据项目情况自行决定：
FileLength"
LineLength"
＜propertyname="
120"
＜/module＞
300"
ParameterNumber"
4.修改对于Throws的的限制：
允许ThrowsUncheckedException以及ThrowsSubclassOfAnotherDeclaredException。
RedundantThrows"
allowUnchecked"
true"
allowSubclasses"
5.修改成员变量的可视性：
一般情况下，应该允许ProtectedMembers以及PackageVisibleMembers。
VisibilityModifier"
protectedAllowed"
packageAllowed"
3.2.CheckStyle应用的最佳实践
采用CheckStyle以后，编码规范的检查就变得及其简单，可以作为一项切实可行的实践加以执行。
一般情况下，在项目小组中引入CheckStyle可以按照下面的步骤进行：
1．强调CodeReview与CodeConventions的重要作用；
2．介绍CheckStyle；
3．初步应用CheckStyle：
参照CheckStyle附带的配置文件，酌情加以剪裁，在项目的Ant配置文件中，添加CheckStyle任务，可以单独执行；
4．修改、定型CheckStyle的配置文件：
按照基本配置文件执行一段时间（2～3周），听取开发人员的反馈意见，修改配置信息；
5．作为开发过程的日常实践，强制执行CheckStyle：
稳定CheckStyle的配置信息，同时将CheckStyle任务作为Build的依赖任务或者配置源码控制系统（目前，CheckStyle可以与CVS有效集成），使得代码在加入系统之前必须通过检查。
同时需要指出的是，CheckStyle的有效执行需要依赖两个条件：
·
Ant的广泛应用：
CheckStyle基于Ant执行的方式比较容易，而且可以在项目内容形成一致的执行环境。
同时，也比较容易与其它任务，例如Build等发生关联。
IDEFormatCode的强大功能：
由于CheckStyle本身并没有提供很强大的CodeFormat等功能，因此，需要借助IDE的帮助，从而使得在发生错误的时候，可以很容易的进行修复。
目前，主流的JavaIDE都提供了这方面的功能，IDEA在这方面尤其突出。
它提供的统一、可定义的CodeFormatTemplate（项目小组内部可以使用统一模板）以及方便的快捷键功能（Ctrl+Alt+T：
FormatCode,Ctrl+Alt+O：
OptimizeImport等）。
四、结论
利用CheckStyle可以方便的对于编码的CodeConventions进行检查，同时，也有效地减少了CodeReview的工作，使得Reviw人员的精力更多的集中到逻辑和性能检查。
Checkstyle的结果输出
序号输出内容意义
1TypeismissingajavadoccommentClass缺少类型说明
2“{”shouldbeonthepreviousline“{”应该位于前一行
3Methosismissingajavadoccomment方法前面缺少javadoc注释
4Expected@throwstagfor“Exception”在注释中希望有@throws的说明
5“.”Ispreceededwithwhitespace“.”前面不能有空格
6“.”Isfollowedbywhitespace“.”后面不能有空格
7“=”isnotpreceededwithwhitespace“=”前面缺少空格
8“=”isnotfollowedwithwhitespace“=”后面缺少空格
9“}”shouldbeonthesameline“}”应该与下条语句位于同一行
10Unused@paramtagfor“unused”没有参数“unused”，不需注释
11Variable“CA”missingjavadoc变量“CA”缺少javadoc注释
12Linelongerthan80characters行长度超过80
13Linecontainsatabcharacter行含有”tab”字符
14Redundant“Public”modifier冗余的“public”modifier
15FinalmodifieroutoforderwiththeJSLsuggestionFinalmodifier的顺序错误
16Avoidusingthe“.*”formofimportImport格式避免使用“.*”
17Redundantimportfromthesamepackage从同一个包中Import内容
18Unusedimport-java.util.listImport进来的java.util.list没有被使用
19Duplicateimporttoline13重复Import同一个内容
20Importfromillegalpackage从非法包中Import内容
21“while”constructmustuse“{}”“while”语句缺少“{}”
22Variable“sTest1”mustbeprivateandhaveaccessormethod变量“sTest1”应该是private的，并且有调用它的方法
23Variable“ABC”mustmatchpattern“^[a-z][a-zA-Z0-9]*$”变量“ABC”不符合命名规则“^[a-z][a-zA-Z0-9]*$”
24“（”isfollowedbywhitespace“（”后面不能有空格25“）”isproceededbywhitespace“）”前面不能有空格
不太明白的错误解答
1.'
X'
hidesafield.
publicclassFoo
{
privateintbar;
publicFoo（intbar）
this.bar=bar;
}
publicfinalintgetBar（）
returnbar;
解释：
全局privateintbar;
和局部publicFoo（intbar）的bar变量名字重复。
此错误，可以忽略不检查。
2.ParameterXshouldbefinal.
publicFoo（intbar）的局部变量，被认为是不可改变的，检查需要加上final关键字定义publicFoo（finalintbar）
3.Redundant'
modifier.
publicinterfaceCacheHRTreeServiceextendsManager{
/**
*OrganizationTree
*
*@paramorgDto
*@return
*@throwsException
*/
publicvoidsetOrganization（OrganizationDTOorgDto）throwsException;
publicOrganizationDTOgetOrganization（）throwsException;
......
多余的字段。
此时public为多余的字段，因为interface定义的时候，就是public的。
需要检查。
4.-ClassXshouldbedeclaredasfinal.
对于单例设计模式，要求返回唯一的类对象。
但是HRFactory和ContextFactory为优化的两个类，不需求检查。
其他的单例类，依然需要进行检查。
5.Utilityclassesshouldnothaveapublicordefaultconstructor.
工具类不必提供默认的构造方法。
需要检查，仅仅为提示。
6.Filedoesnotendwithanewline.
虽然JAVA程序不要求结尾要用新行，但是习惯上应该要空一行。
7.-Method'
addChildrenId'
isnotdesignedforextension-needstobe
abstract,finalorempty.
通过父类继承的，此类有点特殊
可以忽略此类。
8.Variable'
id'
mustbeprivateandhaveaccessormethods.
BaseHRDTO类，为父类，属性给子类继承，比较特殊。
但是其他的类，声名需要加上范围'
private'
关键字
9.-Arraybracketsatillegalposition.
代码写法，习惯
Eclipse插件安装和使用
步骤一：
勾选SetProjectDirasCheckjstyleBasedir
步骤二：
右键选中你要进行checkstyle的项目文件，选择“properties”。
如下图：
勾选EnableCheckstyle和SetProjectClassLoader.
然后再CheckstyleConfiguraionFile中选择项目中checkstyle的配置文件。
这里我把配置文件时放置在项目根目录下，所以点击右侧“Browse”按钮，在项目根目录下选择该文件。
按“OK”按钮。
这样整个项目的代码将根据配置文件中设置的原则进行出错提示.结果如下图：
由图可知对不符合代码规范的代码会有错误提示，并且有提示信息。
Maven插件安装和使用
首先，修改要检查代码库top级的pom.xml文件，在build部分配置CheckStyle的Maven插件，以便于下载安装对应版本的插件（Maven会自动从其镜像库中下载），方法如下：
Java代码
1.<
project>
2....
3.<
build>
4.<
plugins>
5.<
plugin>
6.<
groupId>
org.apache.maven.plugins<
/groupId>
7.<
artifactId>
maven-checkstyle-plugin<
/artifactId>
8.<
version>
2.3<
/version>
9.<
/plugin>
10.<
/plugins>
11.<
/build>
12....
13.<
/project>
maven-checkstyle-plugin的最新版本为2.5，其对应的CheckStyle核心版本为5.0；
maven-checkstyle-plugin2.3对应的CheckStyle核心版本为4.4。
查看插件的pom文件，可看到如下内容，其中的版本号就为对应的CheckStyle的版本号。
dependency>
2.<
checkstyle<
4.4<
/dependency>
接下来，将自定义的规则配置文件拷贝到top级目录，在reporting部分的CheckStyle插件配置中引用配置。
reporting>
configuration>
configLocation>
my_checks.xml<
/configLocation>
/configuration>
/reporting>
也可以将配置文件放在子文件夹下，配置中带上相对路径即可。
build-tools/src/main/resources/xx/my_checks.xml<
如果使用插件自带的规则文件，可以作如下配置。
maven-checkstyle-plugin插件自带的规则有sun_checks.xml、maven_checks.xml等，可查看插件包。
config/maven_checks.xml<
12.<
在reporting部分增加jxr插件，生成代码报告，这样在CheckStyle报告中点击问题对应的链接就可以直接看到出错的
升级会员 