Checkstyle 与 PMD
我们正在将静态分析工具引入到 Java 产品的构建系统中。 我们使用的是 Maven2，因此 Checkstyle 和 PMD 集成免费。 然而，在执行基本样式规则方面，这两个工具之间的功能似乎有很大的重叠。
使用这两者有好处吗？ 如果其中一种工具有效的话，我不想维护两种工具。 如果我们选择其中一种，我们应该使用哪一种，为什么？
我们还计划使用 FindBugs。 我们还应该考虑其他静态分析工具吗？
更新： 共识似乎是 PMD 优于 CheckStyle。 我没有看到使用两者的充分理由，而且我不想维护 2 组规则文件，因此我们可能会专门针对 PMD。 我们还将引入 FindBugs，也许最终还会引入 Macker 来执行架构规则。
We are introducing static analysis tools into the build system for our Java product. We are using Maven2 so Checkstyle and PMD integration come for free. However it looks like there is a large overlap in functionality between these two tools, in terms of enforcing basic style rules.
Is there a benefit from utilizing both of these? I don't want to maintain 2 tools if one will work. If we choose one, which one should we use and why?
We are also planning on using FindBugs. Are there other static analysis tools we should look at?
Update: Consensus seems to be that PMD is preferred over CheckStyle. I don't see a solid reason to use both, and I don't want to maintain 2 sets of rule files, so we will probably aim for PMD exclusively. We'll also be bringing in FindBugs, and perhaps, eventually, Macker to enforce architectural rules.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（17）
您绝对应该使用 FindBugs。 根据我的经验，误报率非常低，即使是它报告的最不重要的警告在某种程度上也值得解决。
至于 Checkstyle 与 PMD，我不会使用 Checkstyle，因为它几乎只关心样式。 根据我的经验，Checkstyle 会报告大量完全不相关的事情。 另一方面，PMD 还能够指出有问题的编码实践，并且其输出通常更相关和有用。
You should definitely use FindBugs. In my experience, the false-positive rate is very low, and even the least-critical warnings it reports are worth addressing to some extent.
As for Checkstyle vs. PMD, I would not use Checkstyle since it is pretty much only concerned with style. In my experience, Checkstyle will report on a ton of things that are completely irrelevant. PMD on the other hand is also able to point out questionable coding practices and its output is generally more relevant and useful.
两个软件都很有用。 Checkstyle 将在编程过程中帮助您检查您的编码风格，即大括号、命名等。事情很简单，但数量却非常多！
PMD 将帮助您检查更复杂的规则（例如在类设计期间），或者检查更特殊的问题（例如正确实现克隆功能）。 简单来说，PMD 会检查您的编程风格。
但是，这两种软件都存在类似的规则，有时很难解释。 如果配置不好，您可能会检查两次或两次相反的事情，即“删除无用的构造函数”和“始终一个构造函数”。
Both softwares are useful. Checkstyle will help you during your programming by checking your coding style i.e braces, naming etc. Simple things but very numerous!
PMD will help you by checking more complicate rules like during the design of your classes, or for more special problems like implementing correctly the clone function. Simply, PMD will check your programming style
However, both softwares suffers from similar rules sometimes bad explained. With a bad configuration, you may check things twice or two opposite things i.e "Remove useless constructors" and "Always one constructor".
这些工具并不相互竞争，而是互补的，应该同时使用。
约定类型（Checkstyle）是使人们能够一起工作并释放创造力的粘合剂，而不是花费时间和精力去理解不一致的代码。
Checkstyle 示例：
PMD 提醒您不好的做法：
源：
http://www.sonarsource.org/what-makes-checkstyle-pmd -findbugs-and-macker-complementary/
These tools are not competing but are complementary and should be used simultaneously.
The convention type (Checkstyle) is the glue that enables people to work together and to free up their creativity instead of spending time and energy at understanding inconsistent code.
Checkstyle examples:
while PMD reminds you bad practices:
source:
http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/
我们同时使用：
We use both:
如果您的主要使用地点是在 Eclipse 中进行开发，那么来自 Instantiations 的 CodePro 将是最好的。 早些时候它是一个商业工具，但现在 Google 购买了 Instantiations，因此 CodePro analytix 现在是免费的。
请查看 http://code.google.com/javadevtools/download-codepro.html
If your primary place of use is while developing in eclipse, then CodePro from Instantiations will be best. Earlier it was a commercial tool, but now Google bought Instantiations so CodePro analytix is free now.
Check out http://code.google.com/javadevtools/download-codepro.html
如果您查看了 Checkstyle、PMD 和 Findbugs 规则列表，您会发现这三者都提供了有价值的输出，并且这三者在一定程度上有重叠，并且还带来了自己独特的规则。 这就是像 Sonar 这样的工具使用这三种工具的原因。
也就是说，Findbugs 具有最具体或利基的规则（例如“可疑的 IllegalMonitorStateException 捕获” - 您可能会多久遇到一次？），因此它可以在很少或没有配置的情况下使用，并且应该认真对待它的警告。 对于 Checkstyle 和 PMD，规则更加通用并且与样式相关，因此它们应该仅与自定义配置文件一起使用，以使团队免受大量不相关反馈的影响（“第 5 行的制表符”、“第 6 行的制表符”、 “第 7 行的 Tab 字符”...你明白了）。 它们还提供了强大的工具来编写您自己的高级规则，例如 Checkstyle DescendentToken 规则。
当使用这三个工具时（特别是使用像 Sonar 这样的工具），它们都应该单独配置（至少需要几天时间来覆盖所有规则），同时注意防止重复（所有三个工具都检测到 hashCode() 已被配置）。例如，被覆盖并且 equals() 不被覆盖）。
总之，如果您认为静态代码分析有价值，那么拒绝这三者中任何一个提供的价值都是没有意义的，但是要使用这三者，您必须投入时间来配置它们，以便为您提供可用的反馈。
If you reviewed Checkstyle, PMD and Findbugs rule lists, you have seen that all three provide valuable output and all three overlap to a degree and also bring their own, unique rules to the table. This is why tools like Sonar use all three.
That said, Findbugs has the most specific or niche rules (e.g. "Dubious catching of IllegalMonitorStateException" - how often are you likely to run into that?) so it is usable with little or no configuration and its warnings should be taken seriously. With Checkstyle and PMD the rules are more general and style-related so they should only be used with custom configuration files to spare the team from an avalanche of irrelevant feedback ("Tab char on line 5", "Tab char on line 6", "Tab char on line 7"... you get the picture). They also provide powerful tools to write your own advanced rules, e.g. the Checkstyle DescendentToken rule.
When using all three (especially with a tool like Sonar), all of them should be configured separately (takes at least a few days to cover all the rules) while paying attention to prevent duplication (all three tools detect that hashCode() has been overridden and equals() not, for example).
In summary, if you consider static code analysis valuable, rejecting the value any of the three provides makes no sense, but to use all three, you have to invest time to configure them to give you usable feedback.
Sonar (http://www.sonarsource.org/) 是一个非常有用的开放平台，用于管理代码质量，包括 Checkstyle、PMD、Findbugs 等。
这也表明这三种工具都有其存在的权利......
Sonar (http://www.sonarsource.org/) is a very useful open platform to manage code quality, and includes Checkstyle, PMD, Findbugs and much more.
This also indicates that all 3 tools have their right to exist...
这两种工具都是可配置的，并且可以做几乎相同的事情。 也就是说，如果我们谈论的是开箱即用的东西，就会有很多重叠，但也有不同的规则/检查。 例如，Checkstyle 对检查 Javadoc 和查找幻数等提供了更强的支持。 此外，Checkstyle还有一个“导入控制”功能，看起来与Macker的功能类似（我没有使用过Macker）。
如果某些对您来说很重要的事情是 Checkstyle 开箱即用而 PMD 没有，您可能会考虑仅包含这些检查的最小 Checkstyle 配置。 然后制定一个策略，使 Checkstyle 配置无法增长，只需在使用自定义 PMD 规则实现类似功能时删除检查即可。
另请考虑，如果您确定 Checkstyle“导入控制”功能涵盖了您想要从 Macker 获得的功能，那么您可以实现 PMD/Checkstyle 而不是 PMD/Macker。 无论哪种方式，它都是两个工具，但使用 Checkstyle，您将获得 PMD 无法“免费”开箱即用的功能。
Both tools are configurable and can do just about the same things. That said, if we're talking about out-of-the-box stuff, there is a great deal of overlap, but there are distinct rules/checks as well. For example, Checkstyle has stronger support for checking Javadoc and finding magic numbers, to name a couple. Additionally, Checkstyle has an "import control" feature that looks similar to the functionality of Macker (I've not used Macker).
If there are things that are important to you that Checkstyle does out-of-the-box that PMD doesn't, you might consider a minimal Checkstyle configuration with only those checks. Then institute a policy that the Checkstyle configuration cannot grow, simply remove checks as you implement similar functionality with, say, custom PMD rules.
Also consider that if you decide that the Checkstyle "import control" feature covers what you wanted from Macker, then you could implement PMD/Checkstyle instead of PMD/Macker. Either way it's two tools, but with Checkstyle, you'd get the stuff that PMD doesn't do out-of-the-box "for free."
Checkstyle和PMD都擅长检查编码标准并且易于扩展。
但是 PMD 有额外的规则来检查圈复杂度、Npath 复杂度等，这允许您编写健康的代码。
使用 PMD 的另一个优点是 CPD（复制/粘贴检测器）。它可以找出项目之间的代码重复，并且不受 JAVA 的限制。它也适用于 JSP。
Neal Ford 对指标驱动的敏捷开发做了很好的演示，其中讨论了许多有助于 Java/Java EE 开发的工具
Checkstyle and PMD both are good at checking coding standards and are easy to extend.
But PMD has additional rules to check for cyclomatic complexity,Npath complexity,etc which allows you write healthy code.
Another advantage of using PMD is CPD (Copy/Paste Detector).It finds out code duplication across projects and is not constrained to JAVA.It works for JSP too.
Neal Ford has a good presentation on Metrics Driven Agile Development, which talks about many tools that are helpful for Java/Java EE Development
而10年后...
2018 年我全部使用了 Checkstyle、PMD 和 FindBugs。
从FindBugs开始。 也许稍后会添加 PMD 和 Checkstyle。
永远不要盲目执行默认规则！
步骤：
理想情况下，每个项目都可以有单独的规则。
我喜欢通过构建（通过 Maven 插件）运行规则，一旦我知道项目通过了我定义的所有规则，就会因规则错误而失败。
这迫使开发人员采取行动，因为报告还不够。
从那时起，您的项目几乎是防弹的，您甚至可以稍后添加更多规则和/或编写自定义规则。
And 10 years later ...
In 2018 I use all of them Checkstyle, PMD and FindBugs.
Start with FindBugs. Maybe add PMD and Checkstyle later.
Never blindly enforce the default rules !
Steps:
Ideally each project can have separate rules.
I like running the rules via the build (via maven plugins) and fail on rule errors once I know a project passes all the rules I defined.
This forces developers to take action, because reporting is not enough.
From that point on your project is pretty much bullet proof and you could even add more rules later on and/or write custom rules.
我发现 Checkstyle 和 PMD 最适合解决样式问题和简单明显的编码错误。 尽管我发现我喜欢使用 Eclipse，而且它提供的所有警告更适合此目的。 我们通过使用共享首选项并将其标记为实际错误来强制执行某些内容。 这样，他们一开始就不会被签入。
我强烈推荐的是使用 FindBugs。 因为它在字节码级别工作，所以它可以检查在源级别不可能的事情。 虽然它吐出了相当多的垃圾，但它在我们的代码中发现了许多实际且重要的错误。
I find Checkstyle and PMD are best for enforcing style issues and simple obvious coding bugs. Although I've found that I like using Eclipse and all the warnings it provides better for that purpose. We enforce stuff by using shared preferences and marking them as actual errors. That way, they never get checked in in the first place.
What I would strongly and enthusiastically recommend is using FindBugs. Because it works at the bytecode level it can check things that are impossible at the source level. While it spits out its fair share of junks, it has found many actual and important bugs in our code.
到目前为止我还没有看到的一点是，IDE 插件可以在代码上强制执行 CheckStyle 规则集，而 PMD 插件只会报告违规情况。 例如，在多个编程团队的多站点项目中，积极执行标准而不仅仅是报告标准非常重要。
这两个工具都有可用于 IntelliJ、NetBeans 和 Eclipse 的插件（在我看来，这涵盖了大多数用法）。 我对 NetBeans 不太熟悉，所以只能评论一下 IntelliJ 和 Eclipse。
不管怎样，IntelliJ 和 Eclipse 的 PMD 插件将根据项目代码库中的 PMD 违规生成按需报告。
另一方面，CheckStyle 插件将动态突出显示违规行为，并且可以（至少对于 IntelliJ，我对 Eclipse 的经验较少）配置为自动转换一些问题（例如，对于“OneStatementPerLine”，将放置 CR-LF在语句之间，对于“NeedBraces”，将在缺少的地方添加大括号，等等）。 显然，只有更简单的违规行为可以自动修复，但它仍然对遗留项目或位于多个位置的项目有帮助。
PMD 的“按需”意味着开发人员必须有意识地决定运行该报告。 而 Checkstyle 违规行为会在开发过程中自动报告给他们。 虽然 PMD 确实包含更广泛的规则集，但在我看来，IDE 中自动执行/报告违规行为值得维护 2 组规则。
因此，对于我从事的任何项目，我们都会使用这两种工具：在 IDE 中强制执行的 Checkstyle、在 IDE 中报告的 PMD，以及在构建中报告和测量的工具（通过 Jenkins）。
One point I have not seen so far is that there are plugins for IDEs that will enforce CheckStyle rulesets on your code, whereas PMD plugins will only report on violations. For example, in a multi-site project over several programming teams, it's important to actively enforce standards, rather than just to report on them.
Both tools have plugins available for IntelliJ, NetBeans, and Eclipse (in my view this covers most usage). I'm not as familiar with NetBeans, so can only comment on IntelliJ and Eclipse.
Anyway, the PMD plugins for IntelliJ, and Eclipse, will generate reports on demand on PMD violations within the project codebase.
The CheckStyle plugins, on the other hand, will highlight violations on the fly, and can (at least for IntelliJ, I have less experience with Eclipse) be configured to automatically convert some issues (e.g. for 'OneStatementPerLine', will place CR-LF between statements, for 'NeedBraces', will add braces where they are missing, etc.). Obviously, only the simpler violations can be automatically fixed, but it's still a help on legacy projects, or projects located over several locations.
'On demand' for PMD means that the developer must consciously decide to run the report. Whereas Checkstyle violations are automatically reported to them as they develop. While PMD does contain a more extensive ruleset, in my mind the automatic enforecement/reporting of violations in IDEs is worth the hassle of maintaining 2 sets of rules.
So for any projects I work on, we use both tools, Checkstyle enforced in the IDE, PMD reported in the IDE, and both reported and measured in builds (through Jenkins).
看看qulice-maven-plugin，它结合了 Checkstyle、PMD、FindBugs 和其他一些插件静态分析器，并预先配置它们。 这种组合的优点在于您不需要在每个项目中单独配置它们：
Take a look at qulice-maven-plugin that combines together Checkstyle, PMD, FindBugs and a few other static analyzers, and pre-configures them. The beauty of this combination is that you don't need to configure them individually in every project:
我同意这样的评论：PMD 是 Java 样式/约定检查的最新产品。 对于 FindBugs，许多商业开发团队都在使用 Coverity。
I would echo the comment that PMD is the more current product for Java style/convention checking. With respect to FindBugs, many commercial development groups are using Coverity.
我发现更多人提到PMD。 Checkstyle 是人们 4 年前提到的，但我相信 PMD 得到了更持续的维护，并且其他 IDE/插件选择使用它。
PMD is what I find more people referring to. Checkstyle was what people were referring to 4 years ago but I believe PMD is maintained more continuously and what other IDEs/plugins choose to work with.
我刚刚开始使用 Checkstyle 和 PMD。 对我来说，PMD更容易创建自定义规则，比如是否存在System.gc()、Runtime.gc()，只要你会写XPath Query，这也不难。 但是，PMD 并没有向我展示它具有显示列号的功能。 因此，对于诸如检查列限制之类的事情。 您可能想使用 Checkstyle。
I have just started to use Checkstyle and PMD. To me, PMD is more easier to create customized rules for things such that whether there exists System.gc(), Runtime.gc(), as long as you can write the XPath Query which is also not difficult at all. However, PMD has not shown me that it has the feature to show column number. So for things like check column limits. You might would like to use Checkstyle.
与 checkstyle 相比，PMD 是最好的工具。 Checkstyles 可能没有分析代码的能力，而 PMD 提供了许多功能来做到这一点！ Offcourse PMD 尚未发布 javadoc、注释、缩进等规则。顺便说一句，我计划实施这些规则.......谢谢
PMD is the finest tool when compare with checkstyles. Checkstyles may not have the capability to analyse the code while PMD offering many features to do so! Offcourse PMD has not released rules for javadoc, comments, indentations and etc. And by the way i am planning to implement these rules.......thanx