自动代码规范CheckStyleWord格式.docx
《自动代码规范CheckStyleWord格式.docx》由会员分享，可在线阅读，更多相关《自动代码规范CheckStyleWord格式.docx（6页珍藏版）》请在冰豆网上搜索。
命令行工具 ·
ANT任务 同时，CheckStyle目前有很多针对流行IDE的插件，例如Eclipse、IntelliJIDEA、JBuilder等。
但是，大部分都是基于2.4的版本，新版本的特性不支持，同时配置也较为复杂。
因为一般情况下，如果与开发过程与环境集成起来，编码规范的检查会更加有效，因此，作为ANT任务的运行方式使用的更加普遍。
在ANT的build.xml文件中添加CheckStyle任务的步骤如下：
1.将checkstyle-all-3.1.jar拷贝到项目的LIB目录；
2.建立配置文件；
3.声明CheckStyle任务：
＜taskdefresource="
checkstyletask.properties"
classpath="
${lib}/checkstyle-all-3.1.jar"
/＞ 4.建立CheckStyle任务：
＜targetname="
checkstyle"
＞
＜checkstylec＞
＜filesetdir="
${src}"
includes="
**/*.java"
/＞
＜/checkstyle＞
＜/target＞ 2.4.定制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集成在一起使用的时候，点击出错的条目，可以跳转到相应的代码。
本贴来自ZDNetChina中文社区,本贴地址：
三、CheckStyle的最佳实践 3.1.Sun’sCodeConventions的修改 在CheckStyle的最新发布版本中，有一个对于Sun的Java编码规范的配置文件信息。
但是，其中有很多条目并不一定符合项目开发的需要。
就算是对于很多优秀的开源项目，按照这个规范来进行检查，也会出现成千上万的错误。
下面提出的一些修改意见，是从实际项目执行过程中总结出来的，可以作为大家的参考。
我们以CheckStyle3.0配置文件的顺序来介绍：
1.去除对于每个包都有一个package.html文件的限制；
＜!
--＜modulename="
PackageHtml"
/＞--＞
2.修改对于JavaDocComments的限定：
对于很多使用CodeGenerator的项目来说，需要将手写代码与生成代码、单元测试代码的检查分开进行；
3.修改对于体积大小的限制：
目前，很多显示器都是17寸，而且打印方面的限制也比以前有所改善，同时，由于代码中Factory等模式的运用，以及有意义的方法名称等约定，默认每行代码的长度（80）是远远不能满足要求；
对于方法长度等等，也应该根据项目情况自行决定：
FileLength"
LineLength"
120"
＜/module＞
300"
ParameterNumber"
/＞ 4.修改对于Throws的的限制：
允许ThrowsUncheckedException以及ThrowsSubclassOfAnotherDeclaredException。
RedundantThrows"
allowUnchecked"
true"
allowSubclasses"
＜/module＞ 5.修改成员变量的可视性：
一般情况下，应该允许ProtectedMembers以及PackageVisibleMembers。
VisibilityModifier"
protectedAllowed"
packageAllowed"
＜/module＞ 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行长度超过8013Linecontainsatabcharacter行含有”tab”字符14Redundant“Public”modifier冗余的“public”modifier15FinalmodifieroutoforderwiththeJSLsuggestionFinalmodifier的顺序错误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.
publicclassFoo
publicFoo（intbar）的局部变量，被认为是不可改变的，检查需要加上final关键字定义publicFoo（finalintbar）
3.Redundant'
modifier.publicinterfaceCacheHRTreeServiceextendsManager{/**
*OrganizationTree
*
*@paramorgDto
*@return
*@throwsException
*/
publicvoidsetOrganization（OrganizationDTOorgDto）throwsException;
/**
publicOrganizationDTOgetOrganization（）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.
代码写法，习惯不一样。
需要检查，仅仅提示。
升级会员 