怎样辨别一个项目代码写得好还是坏？优秀的代码和腐化的代码区别在哪里？怎么让自己写的代码既漂亮又有生命力？接下来将对代码质量的问题进行一些简略的介绍。也请有过代码质量相关经验的朋友提出宝贵的意见。
代码质量所涉及的5个方面，编码标准、代码重复、代码覆盖率、依赖项分析、复杂度分析。这5方面很大程序上决定了一份代码的质量高低。
编码标准：这个想必都很清楚，每个公司几乎都有一份编码规范，类命名、包命名、代码风格之类的东西都属于其中。
代码重复：顾名思义就是重复的代码，如果你的代码中有大量的重复代码，你就要考虑是否将重复的代码提取出来，封装成一个公共的方法或者组件。
代码覆盖率：测试代码能运行到的代码比率，你的代码经过了单元测试了吗？是不是每个方法都进行了测试，代码覆盖率是多少？这关系到你的代码的功能性和稳定性。
依赖项分析：你的代码依赖关系怎么样？耦合关系怎么样？是否有循环依赖？是否符合高内聚低耦合的原则？通过依赖项分析可以辨别一二。
复杂度分析：以前有人写的程序嵌套了10层 if else你信吗？圈复杂度之高，让人难以阅读。通过复杂度分析可以揪出这些代码，要相信越优秀的代码，越容易读懂。
解释了代码质量相关的5个方面，在实际开发中，已经有很多工具为我们解决以上5个方面的问题，下列5个eclipse插件分别对这5个问题有很好的支持：
在eclipse上安装好了CheckStyle插件后，我们来建一个类用它跑一下。这个类很简单，一个常见的用户实体，包含了id，用户名、密码、邮件等属性，并包含get set方法，一个标准的POJO。运行CheckStyle检查一下：
一个我们平时再普通不过的一个类，被checkstyle弄出这么多问题，情何以堪，我们来看看究竟是什么情况？
这个类基本就这四类毛病，缺少package-info.java文件，这个文件是做什么的呢？他是用来描述包注释的类，有一定的特殊性，要想详细了解请百度。如果对你的项目没有太大的影响，可以忽略它。配置CheckStyle的方法我们等会再说。第一句注释要以“.”结尾，这看你的习惯，你确定需要这个，你就保留，不需要就忽略。缺少java doc，对于java类的属性来说，注释是必要的，所以这个要保留。不是继承的方法，需要加上final关键字，如果你有这个习惯，就保留，反之忽略。
我们这里只是建立了一个最简单的类用CheckStyle来检查，随着你的类代码越来越多，逻辑越来越复杂，CheckStyle能检查出来的毛病也越来越多。常见的CheckStyle错误有这些：
可以看出CheckStyle检查出来的问题，大多是编码规则以及风格上的问题，这是编写高质量代码最基本的。值得注意的是，我们将一些优秀的开源代码用CheckStyle来检查也会检查出不少问题，这不能不说这些开源不优秀，而是每个公司组织有自己的编写规范度，这个度既可以减少程序员的工作量又可以让代码的可读性合格，但这个度不一样符合CheckStyle的完整标准。所以我们一般使用CheckStyle都不会用他的默认标准，而是通过配置，制定适合自己的编码规则。
打开CheckStyle配置，新建一个配置，选择外部配置文件。在这之前最好导出一个eclipse自带的checkstyle配置文件（sun_checks.xml），然后重命名作为一个外部的配置导进去，这么做的目的是导入之后可以修改相应的配置，达到自定义配置的目的（因为eclipse自带的配置是加锁的，不能修改）。导入之后，点击右边的“Configure”进行编辑。
再将第一句注释要以“.”结尾这个规则去掉，双击“Style javadoc”，将窗口内“checkFirstSentence”勾选去掉。
“getId不是继承的方法，必须指定abstract,final或空”，如果你懒得在方法上加“final”，这条规则也可以去掉。
另外还有一个错误“’id’ hides a field.”，原因是方法的参数和类里面定义的域重名了，但使用eclipse生成的get set方法都会这样，所以可以忽略此项。
对每个属性加上java doc注释，所有问题都清除了。以此类推，解决checkstyle问题的方法就是：1、按规则解决代码问题；2、如果觉得这个问题对你的项目质量影响不大，则可以忽略它。
对于多人开发的项目，难以避免出现重复代码的问题，尽管我们尽量对共用的代码进行了封装，但随着需求的增加、人员技术水平差异、沟通不足等原因，重复代码会越来越多。这不仅严重影响代码质量，也无形中增加了代码量。
检查出来的重复代码，可以双击查看。然后根据业务逻辑以及代码特征，决定要不要做封装、怎么封装。
一份质量合格的代码，不仅包含功能程序本身也包含了对应的测试代码，Eclemma插件可以用来统计测试代码覆盖整体代码中的比率，以此来评估代码的功能性和稳定性。
使用Junit编写好测试用例之后，右键Coverage As—>
Junit Test，运行测试用例，Eclemma会统计出相关的代码覆盖率：
根据这个结果，你可以看出自己编写的测试用例覆盖到了那些代码，而没有覆盖到的代码，则有可能成为代码质量的盲区。
随着程序业务逻辑的增加，代码的依赖关系也变的越来越复杂，JDepend插件可以统计包和类的依赖关系，分析出程序的稳定性、抽象性和是否存在循环依赖的问题。右键包—>
Run JDepend Analysis：
被分析package的具体和抽象类（和接口）的数量，用于衡量package的可扩展性。如果一个类中实现了其他类，如实现了类，则类的数目也记录在此。
依赖于被分析package的其他package的数量，用于衡量pacakge的职责。即有多少包调用了它。
被分析package的类所依赖的其他package的数量，用于衡量package的性。即它调用了多少其他包。
被分析package中的抽象类和接口与所在package所有类数量的比例，取值范围为0－1。
I＝Ce/（Ce＋Ca），用于衡量package的不稳定性，取值范围为0－1。I＝0表示最稳定，I＝1表示最不稳定。即如果这个类不调用任何其他包，则它是最稳定的。
被分析package和理想曲线的垂直距离，用于衡量package在稳定性和抽象性之间的平衡。理想的package要么完全是抽象类和稳定（x＝0，y＝1），要么完全是具体类和不稳定（x＝1，y＝0）。取值范围为0－1，D＝0表示完全符合理想标准，D＝1表示package最大程度地偏离了理想标准。即你的包要么全是接口，不调用任何其他包（完全是抽象类和稳定），要么是具体类，不被任何其他包调用。
对于阅读代码的人来说，越简单的代码越好理解和，如果你的代码阅读起来很费劲或者你自己过段时间后再来看都看不懂，你就得想办决下代码的复杂度问题了。Metrics插件可以帮你做到这点。
本文介绍了和java代码质量相关的5个方面问题，并介绍对应eclipse插件的用法和作用。在我们实际开发中，尽量根据自己公司和团队的情况来制定一些检查规则，来提高代码质量。并且在大多数情况下，会有两个检查环节，即本地检查和持续集成的检查，我们常用的Hudson就可以集成很多插件。
本文来源于ipfs
网友评论 ()条 查看