题

我们正在将静态分析工具引入到 Java 产品的构建系统中。我们使用的是 Maven2 所以 格子风格 和 PMD 集成免费。然而，在执行基本样式规则方面，这两个工具之间的功能似乎有很大的重叠。

使用这两者有好处吗？如果其中一种工具有效的话，我不想维护两种工具。如果我们选择其中一种，我们应该使用哪一种，为什么？

我们还计划使用 FindBugs。我们还应该考虑其他静态分析工具吗？

更新： 共识似乎是 PMD 优于 CheckStyle。我没有看到使用两者的充分理由，而且我不想维护 2 组规则文件，因此我们可能会专门针对 PMD。我们还将引入 FindBugs，也许最终还会引入 Macker 来执行架构规则。

有帮助吗？

解决方案

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

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

其他提示

这两种软件都很有用。 Checkstyle将在您的编程过程中通过检查您的编码风格，即大括号，命名等帮助您。简单的事情，但非常多！

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

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

如果我们选择其中一种，我们应该使用哪一种，为什么？

这些工具并不相互竞争，而是互补的，应该同时使用。

约定类型（Checkstyle）是使人们能够一起工作并释放创造力的粘合剂，而不是花费时间和精力去理解不一致的代码。

检查样式示例：

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

PMD 提醒您不良做法：

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

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

我们同时使用：

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

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

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

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

那就是说，Findbugs有最具体或最小的规则（例如“Dubious catch of IllegalMonitorStateException” - 你多久会碰到一次？）因此它可以在很少或没有配置的情况下使用，并且应该采取警告认真。使用Checkstyle和PMD，规则更通用且与样式相关，因此它们只应与自定义配置文件一起使用，以避免团队遭受大量无关反馈（“第5行上的Tab char”，“第6行上的Tab char”） ;，“第7行的Tab char”......你得到了图片）。它们还提供了强大的工具来编写您自己的高级规则，例如： Checkstyle DescendentToken 规则。

当使用全部三个（特别是像Sonar这样的工具）时，所有这些都应该单独配置（至少需要几天时间来覆盖所有规则），同时注意防止重复（所有三个工具都检测到hashCode（ ）已被覆盖并且equals（）不是，例如）。

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

Sonar（http://www.sonarsource.org/）是一个非常有用的开放平台，可以管理代码质量，包括Checkstyle，PMD，Findbugs等等。

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

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

使用PMD的另一个优点是CPD（复制/粘贴检测器）。它发现跨项目的代码重复，并且不限于JAVA。它也适用于JSP。 Neal Ford在 Metrics Driven Agile Development 上有很好的演示，其中讨论了许多有助于Java / Java EE开发的工具

我发现Checkstyle和PMD最适合执行样式问题和简单明显的编码错误。虽然我发现我喜欢使用Eclipse以及它为此目的提供的所有警告。我们通过使用共享首选项并将其标记为实际错误来强制执行内容。这样，他们从未首先登记入住。

我强烈和热情地推荐使用FindBugs。因为它在字节码级别工作，所以它可以检查源级别不可能的事情。虽然它会泄露其公平份额的垃圾，但它在我们的代码中发现了许多实际和重要的错误。

这两种工具都是可配置的，可以做同样的事情。也就是说，如果我们谈论开箱即用的东西，会有很多重叠，但也有不同的规则/检查。例如，Checkstyle更强大地支持检查Javadoc和查找幻数，以命名一对。另外，Checkstyle有一个“导入控件”。看起来类似于Macker功能的功能（我没有使用过Macker）。

如果有些事情对你来说很重要，那么Checkstyle不会开箱即用PMD，你可能会考虑只使用那些检查的最小Checkstyle配置。然后建立一个Checkstyle配置无法增长的策略，只需在执行类似功能时删除检查，例如自定义PMD规则。

另外考虑一下，如果您决定使用Checkstyle“导入控件”，功能涵盖了你想要的Macker，然后你可以实现PMD / Checkstyle而不是PMD / Macker。无论哪种方式，它都是两个工具，但是使用Checkstyle，你可以得到PMD没有开箱即用的东西。“

到目前为止我还没有看到的一点是，IDE的插件会对代码强制执行CheckStyle规则集，而PMD插件只会报告违规行为。例如，在多个编程团队的多站点项目中，积极执行标准非常重要，而不仅仅是报告它们。

这两个工具都有可用于IntelliJ，NetBeans和Eclipse的插件（在我看来，这涵盖了大多数用法）。我对NetBeans不熟悉，所以只能评论IntelliJ和Eclipse。

无论如何，IntelliJ和Eclipse的PMD插件将在项目代码库中生成有关PMD违规的按需报告。

另一方面，CheckStyle插件会突显显示违规行为，并且可以（至少对于IntelliJ，我对Eclipse的经验较少）配置为自动转换某些问题（例如，对于'OneStatementPerLine'，将放置语句之间的CR-LF，对于'NeedBraces'，将添加缺少的括号等。）。显然，只有更简单的违规才能自动修复，但它仍然可以帮助遗留项目或位于多个地点的项目。

对PMD的“按需”意味着开发者必须有意识地决定运行报告。而Checkstyle违规会在他们发展时自动报告给他们。虽然PMD 包含更广泛的规则集，但在我看来，IDE中违规的自动加入/报告值得维护两套规则的麻烦。

因此，对于我工作的任何项目，我们使用两种工具，在IDE中强制执行Checkstyle，在IDE中报告PMD，以及两者在构建中报告和测量（通过Jenkins）。

而10年后...2018 年我全部使用了 Checkstyle、PMD 和 FindBugs。

从...开始 查找错误. 。也许稍后会添加 PMD 和 Checkstyle。

永远不要盲目执行默认规则 !

脚步：

  • 在具有大量代码的项目上运行一个具有默认规则的工具
  • 使规则适应这个项目，用一些注释注释掉无用的规则
  • 关注容易实现的规则（NPE、记录器检查、未封闭资源检查……）
  • 对您认为有价值的规则进行一些修复（一次一个！）
  • 对每个工具都执行此操作，但不是一次全部执行！
  • 重复这个过程

理想情况下，每个项目都可以有单独的规则。我喜欢通过构建（通过 Maven 插件）运行规则，一旦我知道项目通过了我定义的所有规则，就会因规则错误而失败。这迫使开发商采取行动，因为 报告还不够。从那时起，您的项目几乎是防弹的，您甚至可以稍后添加更多规则和/或编写自定义规则。

查看 qulice-maven-plugin ，它将Checkstyle，PMD，FindBugs和一些其他静态分析仪，并预先配置它们。这种组合的优点在于您无需在每个项目中单独配置它们：

<plugin>
  <groupId>com.qulice</groupId>
  <artifactId>qulice-maven-plugin</artifactId>
  <version>0.15</version>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

我赞同PMD是Java风格/约定检查的最新产品的评论。关于FindBugs，许多商业开发团队正在使用Coverity。

我刚刚开始使用Checkstyle和PMD。对我来说，PMD更容易为事物创建自定义规则，例如是否存在System.gc（），Runtime.gc（），只要您可以编写XPath查询，这也是一点都不困难。但是，PMD没有告诉我它具有显示列号的功能。对于像检查列限制这样的事情。您可能想使用Checkstyle。

PMD是我发现更多人所指的东西。 Checkstyle是4年前人们所指的，但我相信PMD的维护更持续，其他IDE /插件选择使用它。

与checkstyles相比，PMD是最好的工具。 Checktyles可能无法分析代码，而PMD提供了许多功能！ Offcourse PMD尚未发布javadoc，评论，缩进等规则。顺便说一句，我计划实施这些规则....... thanx

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top