Checkstyle与PMD

Joh*_*fer 83 java static-analysis findbugs checkstyle pmd

我们将静态分析工具引入到我们的Java产品的构建系统中.我们正在使用Maven2,因此CheckstylePMD集成是免费的.然而,就强制执行基本样式规则而言,这两个工具之间的功能似乎存在很大的重叠.

利用这两者有益处吗?我不想维护2个工具,如果一个工作.如果我们选择一个,我们应该使用哪一个?为什么?

我们还计划使用FindBugs.我们应该看看其他静态分析工具吗?

更新:共识似乎是PMD比CheckStyle更受欢迎.我没有看到使用两者的充分理由,我不想维护2套规则文件,因此我们可能会专门针对PMD.我们还将引入FindBugs,也许最终,Macker将实施架构规则.

Chr*_*est 67

你绝对应该使用FindBugs.根据我的经验,误报率非常低,即使是最不重要的警告,也值得在一定程度上解决.

至于Checkstyle与PMD,我不会使用Checkstyle,因为它几乎只关注风格.根据我的经验,Checkstyle将报告大量完全不相关的事情.另一方面,PMD也能够指出可疑的编码实践,其输出通常更具相关性和实用性.

  • +1用于添加FindBugs的推荐.但是,我强烈不同意你对Checkstyle的看法,除非你是一个有自己独特风格的孤狼开发者.对于团队,同意一个共同的合理规则子集,然后使用像Checkstyle这样的自动化工具自动强制执行这些规则会产生所有人都可读的代码. (45认同)

小智 37

这两种软件都很有用.Checkstyle将帮助您在编程期间检查您的编码风格,即括号,命名等.简单的事情,但非常多!

PMD将帮助您检查更复杂的规则,例如在类的设计过程中,或者更正常的问题,如正确实现克隆功能.简单地说,PMD将检查您的编程风格

但是,这两个软件都有类似的规则,有时候解释不好.如果配置错误,您可能会检查两次或两次相反的事情,即"删除无用的构造函数"和"总是一个构造函数".

  • 究竟.恕我直言,他们是两个旨在做不同事情的工具,所以我不确定它们是否具有可比性.如果要在开发团队中强制执行标准编码样式,请使用Checkstyle.如果要分析设计问题或编码实践错误的代码,请使用PMD. (9认同)

Luc*_*cas 23

如果我们选择一个,我们应该使用哪一个?为什么?

这些工具不是竞争对手,而是互补的,应该同时使用.

常规类型(Checkstyle)是一种粘合剂,它使人们能够一起工作并释放他们的创造力,而不是花时间和精力来理解不一致的代码.

Checkstyle示例:

  • 公共方法上有javadoc吗?
  • 该项目是否遵循Sun命名约定?
  • 代码是否以一致的格式编写?

而PMD提醒你不好的做法:

  • 在不做任何事情的情况下捕获异常
  • 有死代码
  • 太多复杂的方法
  • 直接使用实现而不是接口
  • 在没有not equals(Object object)方法的情况下实现hashcode()方法

来源:http: //www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/

  • 我同意Checkstyle,更注重代码格式并迫使开发人员遵循“代码标准”,但它也可以检测到很多不好的做法,看看[这里](http://sevntu-checkstyle.github.com/ sevntu.checkstyle/),Checkstyle 的扩展更容易开发,但我同意它有局限性,永远无法克服 PMD 和 FindBug。 (2认同)

Ily*_*tov 14

我们使用两者:

  • Checkstyle确保团队中的每个人都以类似的方式编写代码
  • PMD找到有问题的代码区域和下一个重构目标


小智 7

如果您的主要使用地点是在eclipse中进行开发,那么实例化中的CodePro将是最佳选择.早些时候它是一个商业工具,但现在谷歌收购了Instantiations,因此CodePro analytix现在免费.

查看 http://code.google.com/javadevtools/download-codepro.html


Tom*_*vic 7

如果您查看了Checkstyle,PMD和Findbugs规则列表,您已经看到所有三个都提供了有价值的输出,并且所有三个都在一定程度上重叠,并且还为表格提供了自己独特的规则.这就是Sonar等工具使用这三种工具的原因.

也就是说,Findbugs有最具体或最小的规则(例如"Dubious catch of IllegalMonitorStateException" - 你经常遇到什么?)因此它很少或没有配置可用,并且应该认真对待它的警告.使用Checkstyle和PMD,规则更通用且与样式相关,因此它们只应与自定义配置文件一起使用,以免团队遭受大量无关反馈("第5行的Tab char","第6行的Tab char", "第7行的Tab char"......你得到了图片).它们还提供了强大的工具来编写自己的高级规则,例如Checkstyle DescendentToken规则.

当使用所有三个(特别是像Sonar这样的工具)时,所有这些都应该单独配置(至少需要几天时间来覆盖所有规则),同时注意防止重复(所有三个工具都检测到hashCode()已经例如,覆盖和等于()不.

总之,如果您认为静态代码分析很有价值,拒绝三个提供的任何值都没有意义,但要使用这三个,您必须花时间配置它们以便为您提供有用的反馈.


Dav*_*Far 6

Sonar(http://www.sonarsource.org/)是一个非常有用的开放平台,用于管理代码质量,包括Checkstyle,PMD,Findbugs等等.

这也表明所有3种工具都有权存在......


Gre*_*tes 5

两种工具都是可配置的,并且可以做几乎相同的事情。就是说,如果我们谈论的是开箱即​​用的东西,会有很多重叠,但是也有不同的规则/检查。例如,Checkstyle对检查Javadoc和查找幻数有更强的支持,仅举几例。此外,Checkstyle具有“导入控制”功能,该功能看上去与Macker的功能类似(我没有使用Macker)。

如果有些重要的事情让Checkstyle开箱即用,而PMD却没有,那么您可以考虑仅使用那些检查的最小Checkstyle配置。然后制定一个Checkstyle配置无法增长的策略,只需在使用自定义PMD规则实现类似功能时删除检查即可。

还要考虑一下,如果您确定Checkstyle的“导入控制”功能涵盖了Macker想要的功能,则可以实现PMD / Checkstyle而不是PMD / Macker。无论哪种方式,它都是两个工具,但是使用Checkstyle时,您将获得PMD不会“免费”开箱即用的功能。


小智 5

Checkstyle和PMD都擅长检查编码标准并且易于扩展.但PMD还有其他规则来检查圈复杂度,Npath复杂性等,这样可以编写健康的代码.

使用PMD的另一个优点是CPD(复制/粘贴检测器).它发现跨项目的代码重复,并且不限于JAVA.它也适用于JSP.Neal Ford对Metrics Driven Agile Development进行了很好的演示,该演讲讨论了许多有助于Java/Java EE开发的工具

  • 对于任何阅读此内容的人... checkstyle现在有这些http://checkstyle.sourceforge.net/config_metrics.html http://checkstyle.sourceforge.net/config_duplicates.html (4认同)