我们正在将静态分析工具引入Java产品的构建系统中。 我们正在使用Maven2，因此Checkstyle和PMD集成是免费提供的。 但是，就执行基本样式规则而言，这两个工具之间似乎在功能上有很大的重叠。

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

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

更新：共识似乎是PMD优于CheckStyle。 我看不出有理由同时使用这两种文件，也不想维护2套规则文件，因此我们可能只针对PMD。 我们还将引入FindBugs，也许最终引入Macker来实施体系结构规则。

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

至于Checkstyle vs. PMD，我不会使用Checkstyle，因为它几乎只涉及样式。以我的经验，Checkstyle将报告大量完全不相关的事情。另一方面，PMD也可以指出可疑的编码实践，并且其输出通常更相关和有用。

两种软件都很有用。 Checkstyle将通过检查编码风格(即花括号，命名等)来帮助您编程，这很简单，但是数量众多！

PMD将通过检查更复杂的规则(例如在类设计期间)或解决更特殊的问题(例如正确实现克隆功能)来帮助您。简而言之，PMD将检查您的编程风格

但是，这两种软件都有类似的规则，有时很难解释。如果配置不正确，您可能会检查两次或两项相反的事情，即"删除无用的构造函数"和"总是一个构造函数"。

If we choose one, which one should we use and why?

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

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

Checkstyle示例：

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

当PMD提醒您不良做法时：

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

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

我们同时使用：

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

如果您的主要使用地点是在Eclipse中进行开发，那么Instantiations中的CodePro将是最佳选择。以前它是一种商业工具，但现在Google购买了Instantiations，因此CodePro analytix现在免费。

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

如果查看Checkstyle，PMD和Findbugs规则列表，您会发现所有这三个都提供了有价值的输出，并且所有三个都在一定程度上有重叠，并且也将它们自己的唯一规则带到了表中。这就是为什么像Sonar这样的工具同时使用这三个工具的原因。

就是说，Findbugs具有最具体或特定的规则(例如，" IllegalMonitorStateException的可疑捕获" –您可能经常遇到这种情况？)，因此几乎没有配置就可以使用它，并且应该认真对待其警告。使用Checkstyle和PMD时，规则更加通用且与样式相关，因此它们仅应与自定义配置文件一起使用，以使团队免受大量无关反馈("第5行的Tab字符"，"第6行的Tab字符"，"第7行上的Tab字符" ...您得到图片。它们还提供了强大的工具来编写您自己的高级规则，例如Checkstyle DescendentToken规则。

当使用全部三个(特别是使用Sonar之类的工具)时，应将它们全部单独配置(至少花几天时间才能涵盖所有规则)，同时注意防止重复(所有三个工具都检测到hashCode()已被例如，覆盖且不等于equals())。

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

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

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

Checkstyle和PMD都擅长检查编码标准，并且易于扩展。
但是PMD还有其他规则可以检查循环复杂度，Npath复杂度等，从而可以编写健康的代码。

使用PMD的另一个优势是CPD(复制/粘贴检测器)，它可以发现跨项目的代码重复，并且不限于JAVA，它也适用于JSP。
尼尔·福特(Neal Ford)在"度量驱动的敏捷开发"上做了很好的演讲，其中谈到了许多对Java / Java EE开发有用的工具。

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

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

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

我发现Checkstyle和PMD最适合执行样式问题和简单的明显的编码错误。尽管我发现我喜欢使用Eclipse及其所有警告，但为此目的它提供了更好的选择。我们通过使用共享首选项并将其标记为实际错误来强制执行操作。这样一来，他们永远不会被检入。

我强烈建议您使用FindBugs。因为它在字节码级别上起作用，所以它可以检查在源代码级别上不可能的事情。尽管它浪费了大量的垃圾，但它在我们的代码中发现了许多实际和重要的错误。

十年后...
在2018年，我将全部使用Checkstyle，PMD和FindBugs。

从FindBugs开始。也许以后再添加PMD和Checkstyle。

切勿盲目执行默认规则！

脚步：

• 在具有大量代码的项目上运行具有默认规则的工具
• 调整规则以适应该项目，注释掉无用的规则并附带一些注释
• 专注于低落的成果规则(NPE，记录器检查，未封闭资源检查...)
• 对您认为有价值的规则进行一些修复(一次！)
• 为每个工具执行此操作，但不能一次完成所有操作！
• 重复这个过程

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

到目前为止，我还没有看到的一点是，有一些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)。

看一下结合了Checkstyle，PMD，FindBugs和其他一些静态分析器的qulice-maven-plugin，并对其进行了预配置。这种组合的优点在于，您不需要在每个项目中都单独配置它们：

我想回应一下PMD是Java样式/约定检查的最新产品。关于FindBugs，许多商业开发小组正在使用Coverity。

我刚刚开始使用Checkstyle和PMD。对我来说，只要您可以编写XPath查询，那么PMD为诸如是否存在System.gc()，Runtime.gc()之类的事物创建自定义规则会更加容易。但是，PMD尚未向我显示它具有显示列号的功能。因此，对于诸如检查列限制之类的事情。您可能想使用Checkstyle。

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

与checkstyles相比，PMD是最好的工具。当PMD提供许多功能时，Checkstyle可能无法分析代码！ Offcourse PMD尚未发布Javadoc，注释，缩进等规则。通过这种方式，我计划实现这些规则。