Checkstyle 与 PMD

Posted 2023-02-19

【中文标题】Checkstyle 与 PMD

【英文标题】：Checkstyle vs. PMD

【发布时间】：2010-09-16 02:54:39

【问题描述】：

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

同时使用这两种方法有什么好处吗？如果一个可以工作，我不想维护 2 个工具。如果我们选择一种，我们应该使用哪一种，为什么？

我们还计划使用 FindBugs。还有其他我们应该关注的静态分析工具吗？

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

【参考方案1】：

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

对于 Checkstyle 与 PMD，我不会使用 Checkstyle，因为它几乎只与样式有关。根据我的经验，Checkstyle 会报告大量完全不相关的事情。另一方面，PMD 也能够指出有问题的编码实践，其输出通常更相关和有用。

【讨论】：

+1 用于添加您对 FindBugs 的推荐。但是，我强烈不同意你对 Checkstyle 的看法，除非你是一个独行独行的开发者，拥有自己独特的风格。对于团队来说，就一个通用的、合理的规则子集达成一致，然后使用像 Checkstyle 这样的自动化工具来自动执行它们会产生所有人都可读的代码。

虽然不完美，但 FindBugs 是迄今为止最好的。 PMD 和 checkstyle 将您指向彻头彻尾的不良做法。除非您非常清楚哪些警告有效，哪些无效，否则不惜一切代价避免。

奇怪的是，我在 PMD 与 Checkstyle 方面的经历完全相反。如果 checkstyle 或 Findbugs 没有找到，PMD 经常会报告误报。不过，7 年可能很重要。

【参考方案2】：

这两个软件都很有用。 Checkstyle 将通过检查您的编码风格（即大括号、命名等）在您的编程过程中为您提供帮助。简单但数量众多！

PMD 将通过检查更复杂的规则（例如在类设计期间）或更特殊的问题（例如正确实现克隆功能）来帮助您。简单地说，PMD 会检查你的编程风格

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

【讨论】：

没错。恕我直言，它们是两个旨在做不同事情的工具，所以我不确定它们是否具有可比性。如果您想在开发团队中强制执行标准编码风格，请使用 Checkstyle。如果您想针对设计问题或不良编码实践分析代码，请使用 PMD。

【参考方案3】：

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

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

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

检查样式示例：

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

虽然 PMD 提醒您不良做法：

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

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

【讨论】：

我同意Checkstyle，更关注代码格式并强制开发人员遵循“代码标准”，但它也可以检测到很多不良做法，看看here，以及Checkstyle的扩展更容易开发，但我同意它有局限性，永远无法克服 PMD 和 FindBug。

【参考方案4】：

我们两个都用：

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

【参考方案5】：

如果您的主要使用场所是在 Eclipse 中进行开发，那么来自 Instantiations 的 CodePro 将是最好的。早些时候它是一个商业工具，但现在 Google 购买了 Instantiations，因此 CodePro analytix 现在是免费的。

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

【参考方案6】：

如果您查看过 Checkstyle、PMD 和 Findbugs 规则列表，您会发现这三个规则都提供了有价值的输出，并且所有三个都在一定程度上重叠，并且还带来了自己独特的规则。这就是 Sonar 之类的工具同时使用这三种工具的原因。

也就是说，Findbugs 具有最具体或最特殊的规则（例如，“可疑捕获 IllegalMonitorStateException” - 您可能多久遇到一次？）因此它可以在很少或没有配置的情况下使用，并且应该认真对待它的警告.使用 Checkstyle 和 PMD，规则更通用且与样式相关，因此它们只能与自定义配置文件一起使用，以使团队免于大量无关反馈（“第 5 行的 Tab char”、“第 6 行的 Tab char”、 “第 7 行的 Tab char”......你明白了）。它们还提供强大的工具来编写您自己的高级规则，例如Checkstyle DescendentToken 规则。

当同时使用这三个时（尤其是使用像 Sonar 这样的工具），它们都应该单独配置（至少需要几天时间才能涵盖所有规则）同时注意防止重复（所有三个工具都检测到 hashCode( ) 已被覆盖，而 equals() 不是，例如）。

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

【参考方案7】：

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

这也说明这3个工具都有存在的权利……

【参考方案8】：

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

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

还要考虑，如果您决定 Checkstyle“导入控制”功能涵盖了您希望 Macker 提供的功能，那么您可以实施 PMD/Checkstyle 而不是 PMD/Macker。无论哪种方式，它都是两个工具，但使用 Checkstyle，您可以“免费”获得 PMD 不具备的开箱即用功能。

【参考方案9】：

Checkstyle 和 PMD 都擅长检查编码标准，并且易于扩展。 但是 PMD 有额外的规则来检查圈复杂度、Npath 复杂度等，这使您可以编写健康的代码。

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

【讨论】：

对于任何阅读本文的人...checkstyle 现在有这些checkstyle.sourceforge.net/config_metrics.html checkstyle.sourceforge.net/config_duplicates.html

【参考方案10】：

我发现 Checkstyle 和 PMD 最适合解决样式问题和简单明显的编码错误。虽然我发现我喜欢使用 Eclipse 以及它为此目的提供的所有警告。我们通过使用共享偏好并将它们标记为实际错误来强制执行内容。这样一来，他们就永远不会被登记入住。

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

【参考方案11】：

10 年后…… 2018 年我全部使用 Checkstyle、PMD 和 FindBugs。

从 FindBugs 开始。以后可能会添加 PMD 和 Checkstyle。

切勿盲目执行默认规则！

步骤：

在包含大量代码的项目上运行一个具有默认规则的工具 将规则适配到本项目中，注释掉无用的规则并附上一些注释 关注低效规则（NPE、记录器检查、未关闭的资源检查……） 对您认为有价值的规则执行一些修复（一次一个！） 为每个工具执行此操作，但不要一次全部执行！ 重复此过程

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

【讨论】：

仅供参考，SpotBugs is the "spiritual successor of FindBugs" 和 SpotBugs documentation 相当不错。据我所知，FindBugs 已经多年没有更新了。

没听说过 SpotBugs，可能是因为 FindBugs + fbcontrib 已经够用很久了，很高兴知道有一些替代品

这里有一些讨论：news.ycombinator.com/item?id=12885549

另外值得注意的是，工具往往具有可配置的灵敏度。例如，在开始使用 FindBugs/SpotBugs 时，您可能需要选择一个高阈值以仅捕获最严重的错误，然后在修复问题时降低阈值。

@ThrawnCA 是的，但即使有敏感性：在大型项目中，会发现太多错误，无法在合理的时间内修复。所以我要做的是一次添加一条规则，从潜在的 NP 检测等最容易实现的目标开始，然后转向未封闭资源等规则。

【参考方案12】：

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

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

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

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

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

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

【讨论】：

还有一些方法可以将其集成到构建中并使其在违规时失败（例如使用 maven）。我已经为 Checkstyle、PMD 和 FindBugs 做了这个。正如你所说，报告是不够的。

【参考方案13】：

看看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>

【讨论】：

如何配置它以获取报告（以某种可用格式）？现在即使我配置了 log4j，它也只会将它吐到控制台。我看到有一个 bug report 可能是相关的，但我不确定。

我们的想法是一样的，但为了解决它，我需要在我的代码或类似的东西中突出显示它。至少你的settings.jar 有帮助。

【参考方案14】：

我会附和这样的评论，即 PMD 是 Java 样式/约定检查的最新产品。对于 FindBugs，许多商业开发团体都在使用 Coverity。

【参考方案15】：

PMD 是我发现更多人所指的。 Checkstyle 是 4 年前人们所指的，但我相信 PMD 得到了更持续的维护，以及其他 IDE/插件选择使用的内容。

【讨论】：

2008 年确实如此，但今天 Checkstyle 已经加快了很多速度。

【参考方案16】：

我刚刚开始使用 Checkstyle 和 PMD。对我来说，PMD更容易为诸如是否存在System.gc()、Runtime.gc()之类的东西创建自定义规则，只要你会编写XPath Query，这也一点也不难。但是，PMD 并没有向我展示它具有显示列号的功能。因此，对于检查列限制之类的事情。您可能想使用 Checkstyle。

【参考方案17】：

与检查样式相比，PMD 是最好的工具。 Checkstyles 可能不具备分析代码的能力，而 PMD 提供了许多功能来分析代码！ Offcourse PMD 尚未发布 javadoc、cmets、缩进等规则。顺便说一句，我计划实施这些规则.......thanx

【讨论】：

checkstyle 的一个好处是它允许一些灵活的规则，例如 RegexpSingleline...