主要内容
以及流行检查Code Conventions工具
同时对于目前应用最为广泛CheckStyle应用给出详细介绍也列举了很多使用CheckStyle最佳实战
、Code Review & Code Conventions质量是衡量
个软件Software是否成功关键要素而对于商业软件Software系统尤其是企业应用软件Software系统来说除了软件Software运行质量、文档质量以外代码质量也是非常重要软件Software开发进行到编码阶段时候最大风险就在于如何保证代码易读性和致性从而使得软件Software维护代价不会很高在软件Software开发
过程中以下几种情形随处可见:1) 软件Software维护时间长
而且维护人员积极性不高:做过软件Software维护
开发人员尤其是在接手不是自己开发产品源码时候即使有良好文档介绍说明仍然会对代码中冗长、没有注释段落“叹为观止”理解尚且如此困难何况要修改或者增加新功能因此很多开发人员不愿意进行软件Software维护工作2)新
开发人员融入团队(Team)时间比较长:除了没有良好
培训、文档等有效机制以外每个人套编码风格也容易造成新成员对于已有代码理解不够甚至出现偏差编码规范标准
作为解决以上问题方案已经得到了很长时间应用而在产品或者项目实际开发过程中仅有Code Conventions是不能解决Code问题它往往和Code Review配合作为代码质量保证手段1.1. Code Review
层次和内容Code Review就是审查代码
质量根据形式分为两种种是交叉代码审查就是自己代码由他人来检查就象检查作业样；另种是代码会审就是以会议形式大家共同审核代码质量Code Review
目有:·在项目早期就能够发现代码中
BUG；·帮助初级开发人员学习高级开发人员
经验达到知识共享；·避免开发人员犯
些很常见很普通
；·保证项目组人员
良好沟通；·项目或产品
代码更容易维护；般情况下Code Review内容和层次如下:·编码风格和代码规范标准
致性:检查代码是否符合编码规范标准确保所有人写代码基本致；·代码满足基本
功能要求:检查代码逻辑实现以及单元测试编写策略确认实现功能性需求；·代码满足性能等非功能性需求:非功能性需求
般不便于测试需要借助定工具和Review人员素质针对编码中对于性能影响瓶颈给出解决方案；·去除冗余
提高代码可读性:适当使用 Refactorying技术去除代码中Bad Smell；如果有需要可以Refactorying to Pattern1.2. Code Conventions
尴尬境地从Code Review
层次分析中我们可以看到Code Conventions是其基础而实际情况是在软件Software开发中两者都沦为“宣传口号”而非切实执行实战造成这种情形
原因有 2:1. Code Conventions是开发过程
“道德”而非“法律”:很多时候由于没有有效工具或者辅助手段支持是否遵守编码规范标准是依靠开发人员“道德素养”－自觉遵守而非实际考核指标；2. Code Review
基石不牢:在第种原因影响下Code Review执行过程中如果花费了大量时间在代码规范标准检查上那么对于更为重要
执行逻辑、性能、易读性等评审投入精力就有限；而这种情况反过来也使得对于编码规范标准检查通常都是走过场最后还是每个人套规范标准只要最终交付产品完成指定功能就可以啦2、CheckStyle
面对以上描述
Code Conventions尴尬境地陆续有开发人员提出了自己解决方案目前对于JAVA代码规范标准检查已经有很多成熟工具例如CheckStyle、PMD以及Jalopy等[3]其中CheckStyle应用非常广泛众多开源项目都使用它作为检查代码规范标准工具尤其是 Jakarta 很多项目例如Maven、 Torque等2.1. CheckStyle是什么？
CheckStyle是SourceForge下
个项目提供了个帮助JAVA开发人员遵守某些编码规范标准工具它能够自动化代码规范标准检查过程从而使得开发人员从这项重要但是枯燥任务中解脱出来[1]2.2. CheckStyle检验
主要内容CheckStyle默认提供
下主要检查内容:·Javadoc注释
·命名约定
·标题
·Import语句
·体积大小
·空白
·修饰符
·块
·代码问题
·类设计
·混合检查(包活
些有用比如非必须
.out和pr
stackTrace)从上面可以看出
CheckStyle提供了大部分功能都是对于代码规范标准检查而没有提供象PMD和Jalopy那么多增强代码质量和修改代码功能但是对于团队(Team)开发尤其是强调代码规范标准公司来说它功能已经足够强大2.3. CheckStyle
主要运行方式目前
CheckStyle版本是3.0和以前版本区别它配置文件是基于XML而非Properties文件它
3.0版本提供了两种运行方式:·命令行工具
·ANT任务
同时
CheckStyle目前有很多针对流行IDE插件例如Eclipse、IntelliJ IDEA、JBuilder等但是大部分都是基于2.4版本新版本特性不支持同时配置也较为复杂
般情况下如果和开发过程和环境集成起来编码规范标准检查会更加有效因此作为ANT任务运行方式使用更加普遍在ANT
build.xml文件中添加CheckStyle任务步骤如下:1. 将checkstyle-all-3.1.jar拷贝到项目
LIB目录；2. 建立配置文件；
3. 声明CheckStyle任务:
＜taskdef resource="checkstyletask.properties" 
path="${lib}/checkstyle-all-3.1.jar"/＞4. 建立CheckStyle任务:
＜target name="checkstyle"＞
＜checkstyle config="${config}/sun_checks.xml"＞
＜file
dir="${src}" 
s=" **/*.java" /＞
＜/checkstyle＞
＜/target＞2.4. 定制CheckStyle
CheckStyle
执行基于XML配置文件它主要组成部分是:·Module:整个配置文件就是
棵Module树根节点是Checker Module·Properties:它来决定
个Module如何进行检查每个Module都有个默认值如果不满足开发需求可以设定其它值下面是
个举例:＜module name="MethodLength"＞
＜property name="max" value="60"/＞
＜/module＞它表示
如果思路方法或者构造
长度超过60行CheckStyle就会报错而默认值是150行以下是
段CheckStyle对于Maven项目源文件检查报告:Method 'createExpression' is not designed for extension - needs to be abstract, final or empty. 91
Unable to get information for JellyException. 91
Line has trailing spaces. 93
Line has trailing spaces. 104
Method 'evaluate' is not designed for extension - needs to be abstract, final or empty. 113
Parameter context should be final. 113
Line has trailing spaces. 130
Method 'getExpressionText' is not designed for extension - needs to be abstract, final or empty. 131
Line has trailing spaces. 134
Line has trailing spaces. 135
Method 'toString' is not designed for extension - needs to be abstract, final or empty. 137
Method 'isSupportAntVariables' is not designed for extension - needs to be abstract, final or empty. 156
Method 'SupportAntVariables' is not designed for extension - needs to be abstract, final or empty. 168
Parameter supportAntVariables should be final. 168
'supportAntVariables' hides a field. 168
Method 'isValidAntVariableName' is not designed for extension - needs to be abstract, final or empty. 183
Parameter text should be final. 183 般情况下和IDE集成在起使用时候点击出错条目可以跳转到相应代码3、CheckStyle
最佳实战3.1. Sun’s Code Conventions
修改在CheckStyle
最新发布版本中有个对于SunJava编码规范标准配置文件信息但是其中有很多条目并不定符合项目开发需要就算是对于很多优秀开源项目按照这个规范标准来进行检查也会出现成千上万下面提出
些修改意见是从实际项目执行过程中整理总结出来可以作为大家参考我们以CheckStyle3.0配置文件顺序来介绍:1. 去除对于每个包都有
个package.html文件限制；＜!--＜module name="PackageHtml"/＞--＞ 2. 修改对于JavaDoc Comments
限定:对于很多使用Code Generator项目来说需要将手写代码和生成代码、单元测试代码检查分开进行；3. 修改对于体积大小
限制:目前很多显示器都是17寸而且打印方面限制也比以前有所改善同时由于代码中Factory等模式运用以及有意义思路方法名称等约定默认每行代码长度(80)是远远不能满足要求；对于思路方法长度等等也应该根据项目情况自行决定:＜module name="FileLength"/＞
＜module name="LineLength"＞
＜property name="max" value="120"/＞
＜/module＞
＜module name="MethodLength"＞
＜property name="max" value="300"/＞
＜/module＞
＜module name="ParameterNumber"/＞4. 修改对于Throws
限制:允许Throws Unchecked Exception以及Throws Sub Of Another Declared Exception＜module name="RedundantThrows"＞
＜property name="allowUnchecked" value="true"/＞
＜property name="allowSubes" value="true"/＞
＜/module＞5. 修改成员变量
可视性:般情况下应该允许Protected Members以及Package Visible Members＜module name="VisibilityMod
ier"＞
＜property name="protectedAllowed" value="true"/＞
＜property name="packageAllowed" value="true"/＞
＜/module＞3.2. CheckStyle应用
最佳实战采用CheckStyle以后
编码规范标准检查就变得及其简单可以作为项切实可行实战加以执行般情况下在项目小组中引入CheckStyle可以按照下面步骤进行:1． 强调Code Review和Code Conventions
重要作用；2． 介绍CheckStyle；
3． 初步应用CheckStyle:参照CheckStyle附带
配置文件酌情加以剪裁在项目Ant配置文件中添加CheckStyle任务可以单独执行；4． 修改、定型CheckStyle
配置文件:按照基本配置文件执行段时间(2～3周)听取开发人员反馈意见修改配置信息；5． 作为开发过程
日常实战强制执行CheckStyle:稳定CheckStyle配置信息同时将CheckStyle任务作为Build依赖任务或者配置源码控制系统(目前CheckStyle可以和CVS有效集成)使得代码在加入系统的前必须通过检查同时需要指出
是CheckStyle有效执行需要依赖两个条件:·Ant
广泛应用:CheckStyle基于Ant执行方式比较容易而且可以在项目内容形成致执行环境同时也比较容易和其它任务例如Build等发生关联·IDE Format Code
强大功能:由于CheckStyle本身并没有提供很强大Code Format等功能因此需要借助IDE帮助从而使得在发生时候可以很容易进行修复目前主流Java IDE都提供了这方面功能IDEA在这方面尤其突出它提供统、可定义Code Format Template(项目小组内部可以使用统模板)以及方便快捷键功能(Ctrl+Alt+T:Format Code, Ctrl+Alt+O:Optimize Import等)4、结论
利用CheckStyle可以方便
对于编码Code Conventions进行检查同时也有效地减少了Code Review工作使得Reviw人员精力更多集中到逻辑和性能检查
最新评论