The No.1 i-Technology Magazine in the World !
   
 
Clint Shank's Blog

Bad PMD Rules

posted 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?

 

 

tags:  

links: digg this    del.icio.us    technorati    reddit




1. Christopher E left...
13 Mar 2007 7:11 am

Good points. 100% agree...especially with the spirit of communication and clarity in code trumps many PMD rules.

Now what about the most valuable PMD rules?? My vote is for those that find "suspicious" code like misnamed equals and hashCode() methods.


2. Mike Haller left...
16 Mar 2007 11:03 pm :: http://www.java-community.de/

PositionLiteralsFirstInComparisons: you get free null check if you use the literal first