PMD Plugin preferences rule set Avoid idempotent operations - they are silly. 3 Avoid equality comparisons with Double.NaN - these are likely to be logic errors. 3 A high ratio of statements to labels in a switch statement implies that the switch statement is doing too much work. Consider moving the statements either into new methods, or creating subclasses based on the switch variable. 3 Fields in interfaces are automatically public static final, and methods are public abstract. Classes or interfaces nested in an interface are automatically public and static (all nested interfaces are automatically static). For historical reasons, modifiers which are implied by the context are accepted by the compiler, but are superfluous. 3 The method clone() should throw a CloneNotSupportedException 3 Deeply nested if..then statements are hard to read. y) { if (y>z) { if (z==x) { // this is officially out of control now } } } } } ]]> 3 Classes that have too many fields could be redesigned to have less fields and some nested object grouping some of the information collected on the many fields. 3 If you override finalize(), make it protected. Otherwise, subclasses may not called your implementation of finalize. 3 Avoid passing parameters to methods and then not using those parameters. 3 Detects when a field, formal or local variable is declared with a long name. 3 17] ]]> Avoid throwing certain exception types. Rather than throw a raw RuntimeException, Throwable, Exception, or Error, use a subclassed exception or error instead. 1 In an "if" expression with an "else" clause, avoid negation in the test. For example, rephrase: if (x != y) diff(); else same(); as: if (x == y) same(); else diff(); Most "if (x != y)" cases without an "else" are often return cases, so consistent use of this rule makes the code easier to read. Also, this resolves trivial ordering problems, such as "does the error case go first?" or "does the common case go first?". 3 The abstract class does not contain any abstract methods. An abstract class suggests an incomplete implementation, which is to be completed by subclasses implementing the abstract methods. If the class is intended to be used as a base class only (not to be instantiated direcly) a protected constructor can be provided prevent direct instantiation. 3 Sometimes return statement expressions are wrapped in unnecessary parentheses, making them look like a function call. 3 No need to check for null before an instanceof; the instanceof keyword returns false when given a null argument. 3 An explicit call was made to a finalize method. Finalize methods are meant to be executed at most once (by the garbage collector). Calling it explicitly could result in the method being executed twice for that object (once by you, once by the garbage collector). 3 Detects when a local variable is declared and/or assigned, but not used. 3 A local variable assigned only once can be declared final. 3 A variable naming conventions rule - customize this to your liking Final variables should be all caps Non-final variables should not include underscores 1 Avoid instantiating String objects; this is usually unnecessary. 2 A method should have only one exit point, and that should be the last statement in the method. 0) { return "hey"; // oops, multiple exit points! } return "hi"; } } ]]> 3 Avoid empty switch statements. 3 This rule detects JUnit assertions in object references equality. These assertions should be made by more specific methods, like assertSame, assertNotSame. 3 Avoid unnecessary comparisons in boolean expressions - this makes simple code seem complicated. 3 Excessive Method Length usually means that the method is doing too much. There is usually quite a bit of Cut and Paste there as well. Try to reduce the method size by creating helper methods, and r