November 22, 2010

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?

No comments:

Post a Comment