java优秀代码-java优秀书籍

10.Unused @param tag for “unused”

没有参数“unused”，不需注释

11.Variable “CA” missing javadoc

变量“CA”缺少javadoc注释

12.Line longer than 80characters

行长度超过80

13.Line contains a tab character

行含有”tab” 字符

14.Redundant “Public” modifier

冗余的“public” modifier

15.Final modifier out of order with the JSL

suggestionFinal modifier的顺序错误

16.Avoid using the “.*” form of import

Import格式避免使用“.*”

17.Redundant import from the same package

从同一个包中Import内容

18.Unused import-java.util.list

Import进来的java.util.list没有被使用

19.Duplicate import to line 13

重复Import同一个内容

20.Import from illegal package

从非法包中 Import内容

21.“while” construct must use “{}”

“while” 语句缺少“{}”

22.Variable “sTest1” must be private and have accessor method

变量“sTest1”应该是private的，并且有调用它的方法

23.Variable “ABC” must match pattern “^[a-z][a-zA-Z0-9]*$”

变量“ABC”不符合命名规则“^[a-z][a-zA-Z0-9]*$”

24.“(” is followed by whitespace

“(” 后面不能有空格

25.“)” is proceeded by whitespace

“)” 前面不能有空格

可以看出CheckStyle检查出来的问题，大多是编码规则以及风格上的问题，这是编写高质量代码最基本的。值得注意的是，我们将一些优秀的开源代码用CheckStyle来检查也会检查出不少问题，这不能不说这些开源不优秀，而是每个公司组织有自己的编写规范度，这个度既可以减少程序员的工作量又可以让代码的可读性合格，但这个度不一样符合CheckStyle的完整标准。所以我们一般使用CheckStyle都不会用他的默认标准，而是通过配置，制定适合自己的编码规则。

自定义CheckStyle规则：

打开CheckStyle配置，新建一个配置，选择外部配置文件。在这之前最好导出一个eclipse自带的checkstyle配置文件（sun_checks.xml），然后重命名作为一个外部的配置导进去，这么做的目的是导入之后可以修改相应的配置，达到自定义配置的目的（因为eclipse自带的配置是加锁的java优秀代码，不能修改）。导入之后，点击右边的“Configure”进行编辑。

先去掉缺少package-info.java文件的提示

再将第一句注释要以“.”结尾这个规则去掉，双击“Style javadoc”，将窗口内“checkFirstSentence”勾选去掉。

对于实体类，属性有了注释，get set方法也不需要注释了，双击“Method javadoc”将allowMissingPropertyJavadoc勾选中。

“getId不是继承的方法，必须指定abstract,final或空”，如果你懒得在方法上加“final”，这条规则也可以去掉。

如果你不想每一个参数都加“final”，还需要把参数的final规则去掉：

另外还有一个错误“’id’ hides a field.”，原因是方法的参数和类里面定义的域重名了，但使用eclipse生成的get set方法都会这样，所以可以忽略此项。

至此我们再使用checkstyle检查一篇，发现仅剩下属性缺少注释这个警告。

对每个属性加上java doc注释，所有问题都清除了。以此类推，解决checkstyle问题的方法就是：1、按规则解决代码问题；2、如果觉得这个问题对你的项目质量影响不大，则可以忽略它。

代码重复（PMD的CPD的使用）

对于多人开发的项目，难以避免出现重复代码的问题，尽管我们尽量对共用的代码进行了封装，但随着需求的增加、人员技术水平差异、沟通不足等原因，重复代码会越来越多。这不仅严重影响代码质量，也无形中增加了代码量。

注：精简的程序和高复用度的代码是我们一直追求的目标。

PMD的CPD工具就是为检查重复代码而生的。右键项目—>PMD—->Find Suspect Cut and Paste,执行重复代码检查：

检查出来的重复代码，可以双击查看。然后根据业务逻辑以及代码特征，决定要不要做封装、怎么封装。

代码覆盖率（Eclemma的使用）

一份质量合格的代码java优秀代码，不仅包含功能程序本身也包含了对应的测试代码，Eclemma插件可以用来统计测试代码覆盖整体代码中的比率，以此来评估代码的功能性和稳定性。

使用Junit编写好测试用例之后，右键Coverage As—>Junit Test，运行测试用例，Eclemma会统计出相关的代码覆盖率：

根据这个结果，你可以看出自己编写的测试用例覆盖到了那些代码，而没有覆盖到的代码，则有可能成为代码质量的盲区。

依赖项分析（JDepend的使用）

随着程序业务逻辑的增加，代码的依赖关系也变的越来越复杂，JDepend插件可以统计包和类的依赖关系，分析出程序的稳定性、抽象性和是否存在循环依赖的问题。右键包—>Run JDepend Analysis：

看一下这几项指标：

CC（Number of Classes)

被分析package的具体和抽象类（和接口）的数量，用于衡量package的可扩展性。如果一个类中实现了其他类，如实现了监听类，则监听类的数目也记录在此。

AC（Abstract classes）

抽象类和接口的数量。

Ca（Afferent Couplings)

依赖于被分析package的其他package的数量，用于衡量pacakge的职责。即有多少包调用了它。

Ce（Efferent Couplings)

被分析package的类所依赖的其他package的数量，用于衡量package的独立性。即它调用了多少其他包。

A（Abstractness)

被分析package中的抽象类和接口与所在package所有类数量的比例，取值范围为0－1。

I（Instability)

I＝Ce/（Ce＋Ca），用于衡量package的不稳定性，取值范围为0－1。I＝0表示最稳定，I＝1表示最不稳定。即如果这个类不调用任何其他包，则它是最稳定的。

D（Distance)

被分析package和理想曲线A＋I＝1的垂直距离，用于衡量package在稳定性和抽象性之间的平衡。理想的package要么完全是抽象类和稳定（x＝0，y＝1），要么完全是具体类和不稳定（x＝1，y＝0）。取值范围为0－1，D＝0表示完全符合理想标准，D＝1表示package最大程度地偏离了理想标准。即你的包要么全是接口，不调用任何其他包（完全是抽象类和稳定），要么是具体类，不被任何其他包调用。

Cycle

循环依赖的数量。

有个这个报告我们就可以有针对性的对代码进行设计和重构。

复杂度分析（Metrics的使用）

对于阅读代码的人来说，越简单的代码越好理解和维护，如果你的代码阅读起来很费劲或者你自己过段时间后再来看都看不懂，你就得想办法解决下代码的复杂度问题了。Metrics插件可以帮你做到这点。

首先在Java透视图下右键一个项目—->Properties，选择Metrics，勾选Enble Metrics。

然后Window—>Show View—->Other—->Metrics View

打开Metrics视图，点击右上角运行图标，即可得到复杂度分析的结果：

可以根据复杂度指标，对自己的程序进行优化。

小结

本文介绍了和java代码质量相关的5个方面问题，并介绍对应eclipse插件的用法和作用。在我们实际开发中，尽量根据自己公司和团队的情况来制定一些检查规则，来提高代码质量。并且在大多数情况下，会有两个检查环节，即本地检查和持续集成环境的检查，我们常用的Hudson就可以集成很多插件。

参考资料：