代码质量概述：
•编码标准：这个想必都很清楚，每个公司几乎都有一份编码规范，类命名、包命名、代码风格之类的东
西都属于其中。
• 代码重复：顾名思义就是重复的代码，如果你的代码中有大量的重复代码，你就要考虑是否将重复的代
码提取出来，封装成一个公共的方法或者组件。
• 代码覆盖率：测试代码能运行到的代码比率，你的代码经过了单元测试了吗？是不是每个方法都进行了
测试，代码覆盖率是多少？这关系到你的代码的功能性和稳定性。
• 依赖项分析：你的代码依赖关系怎么样？耦合关系怎么样？是否有循环依赖？是否符合高内聚低耦合的
原则？通过依赖项分析可以辨别一二。
• 复杂度分析：以前有人写的程序嵌套了10层 if else你信吗？圈复杂度之高，让人难以阅读。通过复杂度
分析可以揪出这些代码，要相信越优秀的代码，越容易读懂。
• 编码标准：CheckStyle 插件
• 代码重复：PMD的CPD 插件
• 代码覆盖率：Eclemma 插件
• 依赖项分析：JDepend 插件
• 复杂度分析：Eclipse Metric 插件
<1>、对第一点总结：
常见的CheckStyle错误有这些：
引用
1.Type is missing a javadoc commentClass
缺少类型说明
2.“{” should be on the previous line
“{” 应该位于前一行
3.Methods is missing a javadoc comment
方法前面缺少javadoc注释
4.Expected @throws tag for “Exception”
在注释中希望有@throws的说明
5.“.” Is preceeded with whitespace “.”
前面不能有空格
6.“.” Is followed by whitespace“.”
后面不能有空格
7.“=” is not preceeded with whitespace
“=” 前面缺少空格
8.“=” is not followed with whitespace
“=” 后面缺少空格
9.“}” should be on the same line
“}” 应该与下条语句位于同一行
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来检查也会检查出不少问题，这不能不说这些开源不优
http://www.iteye.com/news 4.13 怎样编写高质量的Java代码
第 156 / 295 页
秀，而是每个公司组织有自己的编写规范度，这个度既可以减少程序员的工作量又可以让代码的可读性合格，
但这个度不一样符合CheckStyle的完整标准。所以我们一般使用CheckStyle都不会用他的默认标准，而是通过
配置，制定适合自己的编码规则。
<2>、PMD的CPD工具就是为检查重复代码而生的。右键项目--->PMD---->Find Suspect Cut and Paste,执行重复
代码检查：
<3>、使用Junit编写好测试用例之后，右键Coverage As--->Junit Test，运行测试用例，Eclemma会统计出相关的
代码覆盖率：
<4>、右键包--->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：循环依赖的数量。
有个这个报告我们就可以有针对性的对代码进行设计和重构
<5>、Metrics插件可以帮你做到这点。
首先在Java透视图下右键一个项目---->Properties，选择Metrics，勾选Enble Metrics。
然后Window--->Show View---->Other---->Metrics View
打开Metrics视图，点击右上角运行图标，即可得到复杂度分析的结果：
<6>、来源于：ITeye新闻月刊 - 2014年03月 - 总第73期.pdf