我们正在将静态分析工具引入Java产品的构建系统中。我们正在使用Maven2，因此Checkstyle和PMD集成是免费提供的。但是，就执行基本样式规则而言，这两个工具之间似乎在功能上有很大的重叠。
同时使用这两种方法有好处吗？如果一个工具可以工作，我不想维护两个工具。如果选择一种，应该使用哪一种，为什么？
我们还计划使用FindBugs。还有其他静态分析工具值得我们关注吗？
更新：共识似乎是PMD优于CheckStyle。我看不到有理由同时使用这两种文件，也不想维护2套规则文件，因此我们可能只针对PMD。我们还将引入FindBugs，也许最终引入Macker来实施体系结构规则。
Answers:
您绝对应该使用FindBugs。以我的经验，假阳性率很低，即使它报告的最不重要的警告在某种程度上也值得解决。
至于Checkstyle vs. PMD，我不会使用Checkstyle，因为它几乎只涉及样式。以我的经验，Checkstyle将报告大量完全不相关的事情。另一方面，PMD还能指出可疑的编码实践，并且其输出通常更相关和有用。
两种软件都很有用。Checkstyle将通过检查编码风格（例如花括号，命名等）为您提供帮助。
PMD将通过检查更复杂的规则（例如在类设计期间）或解决更特殊的问题（例如正确实现克隆功能）来帮助您。简而言之，PMD将检查您的编程风格
但是，这两种软件都有类似的规则，有时解释不好。如果配置不正确，您可能会检查两次或两次相反的检查，即“删除无用的构造函数”和“总是一个构造函数”。
如果选择一种，应该使用哪一种，为什么？
这些工具不是相互竞争的，而是互补的，应同时使用。
约定类型（Checkstyle）是使人们能够一起工作并释放创造力的胶水，而无需花费时间和精力来理解不一致的代码。
Checkstyle示例：
当PMD提醒您不良做法时：
来源：http : //www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/
我们同时使用：
如果您的主要使用地点是在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（）则不是）。
总而言之，如果您认为静态代码分析很有价值，那么拒绝提供这三个值中的任何一个都是没有道理的，但是要同时使用这三个值，您必须花时间配置它们以提供有用的反馈。
两种工具都是可配置的，并且可以完成几乎相同的操作。就是说，如果我们谈论的是开箱即用的东西，会有很多重叠，但是也有不同的规则/检查。例如，Checkstyle对检查Javadoc和查找幻数有更强的支持，仅举几例。此外，Checkstyle具有“导入控件”功能，该功能看上去与Macker的功能类似（我没有使用Macker）。
如果有些重要的事情让Checkstyle开箱即用，而PMD却没有，您可以考虑仅使用那些检查的最小Checkstyle配置。然后制定一个Checkstyle配置无法增长的策略，只需在使用自定义PMD规则实现类似功能时删除检查即可。
还要考虑一下，如果您确定Checkstyle的“导入控制”功能涵盖了Macker想要的功能，则可以实现PMD / Checkstyle而不是PMD / Macker。无论哪种方式，它都是两个工具，但是使用Checkstyle时，您将获得PMD不会“免费”开箱即用的功能。
Checkstyle和PMD都擅长检查编码标准，并且易于扩展。但是PMD还有其他规则可以检查循环复杂度，Npath复杂度等，从而可以编写健康的代码。
使用PMD的另一个优势是CPD（复制/粘贴检测器），它可以发现跨项目的代码重复并且不受Java的限制，它也适用于JSP。尼尔·福特（Neal Ford）在“度量驱动的敏捷开发”上做了精彩的演讲，其中谈到了许多对Java / Java EE开发有用的工具。
十年后...在2018年，我将全部使用Checkstyle，PMD和FindBugs。
从FindBugs开始。也许以后再添加PMD和Checkstyle。
切勿盲目执行默认规则！
脚步：
理想情况下，每个项目可以有单独的规则。我喜欢通过构建（通过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中自动执行违规行为/报告违规行为值得维护两套规则。
所以对于我，我们使用这两种工具的工作的任何项目，Checkstyle的在IDE中执行，PMD报道IDE和两个报告和建立（通过詹金斯）测量。
看一下结合了Checkstyle，PMD，FindBugs和其他一些静态分析器的qulice-maven-plugin，并对其进行了预配置。这种组合的好处在于，您不需要在每个项目中都单独配置它们：
<plugin>
<groupId>com.qulice</groupId>
<artifactId>qulice-maven-plugin</artifactId>
<version>0.15</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
settings.jar帮助。