Checkstyle vs. PMD

Question

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 li

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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).

Answer 5

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:

• run one tool with default rules on a project which has a lot of code
• adapt the rules to this project, comment out useless rules with some notes
• focus on the low hanging fruits rules (NPE, logger checks, unclosed resource checks, ...)
• perform some fixes for rules you find worthwhile (one at a time !)
• do this for each tool but not all at once !
• repeat this process

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.

Answer 6

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."