Bad PMD Rules

Originally published 9 Mar 2007

PMD is an excellent tool for finding potential bugs and improving code quality, but it can generate a lot of false positives. Here's my list of the top 10 rules I turn off immediately, in alphabetical order, with a short comment explaining why. Descriptions for the rules can be found here.

1. AtLeastOneConstructor: Why? Code is smaller without an empty, no-args contructor.
2. AvoidInstantiatingObjectsInLoops: This one just seems to generate too many false positives. In addition, for short-lived objects, garbage collection is essentially free.
3. CallSuperInConstructor: super() is called implicitly and requiring it just adds more lines of code.
4. JUnitAssertionsShouldIncludeMessage: Most of the methods in Assert already generate good messages. I do include a message for those that don't (assertTrue(), assertFalse(), fail()).
5. LocalVariableCouldBeFinal: final for variables is usually overkill and it adds line length.
6. LongVariable: Clarity rules!
7. MethodArgumentCouldBeFinal: Same as LocalVariableCouldBeFinal.
8. OnlyOneReturn: I think it's clearer to exit early. It reduces the amount of things to think about below the exit.
9. PositionLiteralsFirstInComparisons: This really isn't that bad, but myString.equals("x") just reads better than "x".equals(myString).
10. ShortVariable: There are just too many cases where it's acceptable to have short variables in small methods.

 These two just missed the cut:

• ShortMethodName: I try to make my names expressive. I've never seen this rule fire.
• SignatureDeclareThrowsException: This is an okay rule, but for JUnit tests, who cares?