The Controversial Ruleset contains rules that, for whatever reason, are considered controversial. They are separated out here to allow people to include as they see fit via custom rulesets. This ruleset was initially created in response to discussions over UnnecessaryConstructorRule which Tom likes but most people really dislike :-)
Unnecessary constructor detects when a constructor is not necessary; i.e., when there's only one constructor, it's public, has an empty body, and takes no arguments.
This rule is defined by the following XPath expression:
//ClassOrInterfaceDeclaration
/ClassOrInterfaceBody[count(ClassOrInterfaceBodyDeclaration/ConstructorDeclaration)=1]
/ClassOrInterfaceBodyDeclaration/ConstructorDeclaration
[@Public='true']
[not(FormalParameters/*)]
[not(BlockStatement)]
[not(NameList)]
[count(ExplicitConstructorInvocation/Arguments/ArgumentList/Expression)=0]
Here's an example of code that would trigger this rule:
public class Foo {
public Foo() {}
}
Assigning a "null" to a variable (outside of its declaration) is usually in bad form. Some times, the assignment is an indication that the programmer doesn't completely understand what is going on in the code. NOTE: This sort of assignment may in rare cases be useful to encourage garbage collection. If that's what you're using it for, by all means, disregard this rule :-)
This rule is defined by the following Java class: net.sourceforge.pmd.rules.design.NullAssignmentRule
Here's an example of code that would trigger this rule:
public class Foo {
public void bar() {
Object x = null; // This is OK.
x = new Object();
// Big, complex piece of code here.
x = null; // This is BAD.
// Big, complex piece of code here.
}
}
A method should have only one exit point, and that should be the last statement in the method.
This rule is defined by the following Java class: net.sourceforge.pmd.rules.design.OnlyOneReturnRule
Here's an example of code that would trigger this rule:
public class OneReturnOnly1 {
public void foo(int x) {
if (x > 0) {
return "hey"; // oops, multiple exit points!
}
return "hi";
}
}
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.
This rule is defined by the following Java class: net.sourceforge.pmd.rules.UnusedModifier
Here's an example of code that would trigger this rule:
public interface Foo {
public abstract void bar(); // both abstract and public are ignored by the compiler
public static final int X = 0; // public, static, and final all ignored
public static class Bar {} // public, static ignored
public static interface Baz {} // ditto
}
public class Bar {
public static interface Baz {} // static ignored
}
Avoid assigments in operands; this can make code more complicated and harder to read.
This rule is defined by the following XPath expression:
//*[name()='WhileStatement' or name()='IfStatement'][Expression//AssignmentOperator]
Here's an example of code that would trigger this rule:
public class Foo {
public void bar() {
int x = 2;
if ((x = getX()) == 3) {
System.out.println("3!");
}
}
private int getX() {
return 3;
}
}
Each class should declare at least one constructor.
This rule is defined by the following XPath expression:
//ClassOrInterfaceDeclaration
[not(ClassOrInterfaceBody/ClassOrInterfaceBodyDeclaration/ConstructorDeclaration)]
[@Interface='false']
Here's an example of code that would trigger this rule:
public class Foo {
// no constructor! not good!
}
Avoid importing anything from the 'sun.*' packages. These packages are not portable and are likely to change.
This rule is defined by the following XPath expression:
//ImportDeclaration
[starts-with(Name/@Image, 'sun.')]
[not(starts-with(Name/@Image, 'sun.misc.Signal'))]
Here's an example of code that would trigger this rule:
import sun.misc.foo;
public class Foo {}
A suspicious octal escape sequence was found inside a String literal. The Java language specification (section 3.10.6) says an octal escape sequence inside a literal String shall consist of a backslash followed by: OctalDigit | OctalDigit OctalDigit | ZeroToThree OctalDigit OctalDigit Any octal escape sequence followed by non-octal digits can be confusing, e.g. "\038" is interpreted as the octal escape sequence "\03" followed by the literal character "8".
This rule is defined by the following Java class: net.sourceforge.pmd.rules.SuspiciousOctalEscape
Here's an example of code that would trigger this rule:
public class Foo {
public void foo() {
// interpreted as octal 12, followed by character '8'
System.out.println("suspicious: \128");
}
}
It is a good practice to call super() in a constructor. If super() is not called but another constructor, such as an overloaded constructor, of the class is called, this rule will not report it.
This rule is defined by the following XPath expression:
//ConstructorDeclaration[
count(.//ExplicitConstructorInvocation)=0
]
Here's an example of code that would trigger this rule:
public class Foo extends Bar{
public Foo() {
// call the constructor of Bar
super();
}
public Foo(int code) {
// do something with code
this();
// no problem with this
}
}
Sometimes return statement expressions are wrapped in unnecessary parentheses, making them look like a function call.
This rule is defined by the following XPath expression:
//ReturnStatement
/Expression
/PrimaryExpression
/PrimaryPrefix
/Expression[count(*)=1]
/PrimaryExpression
/PrimaryPrefix
Here's an example of code that would trigger this rule:
public class Foo {
boolean bar() {
return (true);
}
}
A field that's only used by one method could perhaps be replaced by a local variable
This rule is defined by the following Java class: net.sourceforge.pmd.rules.SingularField
Here's an example of code that would trigger this rule:
public class Foo {
private int x;
public void foo(int y) {
x = y + 5;
return x;
}
}