Android中界面实现全屏显示的两种方式

代码质量概述

怎样辨别一个项目代码写得好还是坏？优秀的代码和腐化的代码区别在哪里？怎么让自己写的代码既漂亮又有生命力？接下来将对代码质量的问题进行一些粗略的介绍。也请有过代码质量相关经验的朋友提出宝贵的意见。

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

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

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

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

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

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

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

代码覆盖率（Eclemma的使用）

一份质量合格的代码，不仅包含功能程序本身也包含了对应的测试代码，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。