Rules which enforce a specific coding style.
Abstract classes should be named 'AbstractXXX'.
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
by {% rule java/codestyle/ClassNamingConventions %}.
3
3
Avoid using dollar signs in variable/method/class/interface names.
3
Avoid using final local variables, turn them into fields.
3
Prefixing parameters by 'in' or 'out' pollutes the name of the parameters and reduces code readability.
To indicate whether or not a parameter will be modify in a method, its better to document method
behavior with Javadoc.
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
by the more general rule {% rule java/codestyle/FormalParameterNamingConventions %}.
4
Do not use protected fields in final classes since they cannot be subclassed.
Clarify your intent by using private or package access modifiers instead.
3
Do not use protected methods in most final classes since they cannot be subclassed. This should
only be allowed in final classes that extend other classes with protected methods (whose
visibility cannot be reduced). Clarify your intent by using private or package access modifiers instead.
3
Unnecessary reliance on Java Native Interface (JNI) calls directly reduces application portability
and increases the maintenance burden.
2
//Name[starts-with(@Image,'System.loadLibrary')]
Methods that return boolean results should be named as predicate statements to denote this.
I.e, 'isReady()', 'hasValues()', 'canCommit()', 'willFail()', etc. Avoid the use of the 'get'
prefix for these methods.
4
It is a good practice to call super() in a constructor. If super() is not called but
another constructor (such as an overloaded constructor) is called, this rule will not report it.
3
0 ]
/ClassOrInterfaceBody
/ClassOrInterfaceBodyDeclaration
/ConstructorDeclaration[ count (.//ExplicitConstructorInvocation)=0 ]
]]>
Configurable naming conventions for type declarations. This rule reports
type declarations which do not match the regex that applies to their
specific kind (e.g. enum or interface). Each regex can be configured through
properties.
By default this rule uses the standard Java naming convention (Pascal case),
and reports utility class names not ending with 'Util'.
1
Avoid negation within an "if" expression with an "else" clause. 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
Enforce a policy for braces on control statements. It is recommended to use braces on 'if ... else'
statements and loop statements, even if they are optional. This usually makes the code clearer, and
helps prepare the future when you need to add another statement. That said, this rule lets you control
which statements are required to have braces via properties.
From 6.2.0 on, this rule supersedes WhileLoopMustUseBraces, ForLoopMustUseBraces, IfStmtMustUseBraces,
and IfElseStmtMustUseBraces.
3
1
or (some $stmt (: in only the block statements until the next label :)
in following-sibling::BlockStatement except following-sibling::SwitchLabel[1]/following-sibling::BlockStatement
satisfies not($stmt/Statement/Block))]
]]>
Use explicit scoping instead of accidental usage of default package private level.
The rule allows methods and fields annotated with Guava's @VisibleForTesting.
3
Avoid importing anything from the package 'java.lang'. These classes are automatically imported (JLS 7.5.3).
4
Duplicate or overlapping import statements should be avoided.
4
Empty or auto-generated methods in an abstract class should be tagged as abstract. This helps to remove their inapproprate
usage by developers who should be implementing their own versions in the concrete subclasses.
1
No need to explicitly extend Object.
4
Fields should be declared at the top of the class, before any method declarations, constructors, initializers or inner classes.
3
Configurable naming conventions for field declarations. This rule reports variable declarations
which do not match the regex that applies to their specific kind ---e.g. constants (static final),
enum constant, final field. Each regex can be configured through properties.
By default this rule uses the standard Java naming convention (Camel case), and uses the ALL_UPPER
convention for constants and enum constants.
1
Some for loops can be simplified to while loops, this makes them more concise.
3
Avoid using 'for' statements without using curly braces. If the code formatting or
indentation is lost then it becomes difficult to separate the code being controlled
from the rest.
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
by the rule {% rule java/codestyle/ControlStatementBraces %}.
3
//ForStatement[not(Statement/Block)]
Configurable naming conventions for formal parameters of methods and lambdas.
This rule reports formal parameters which do not match the regex that applies to their
specific kind (e.g. lambda parameter, or final formal parameter). Each regex can be
configured through properties.
By default this rule uses the standard Java naming convention (Camel case).
1
lambda1 = s_str -> { };
// lambda parameters with an explicit type can be configured separately
Consumer lambda1 = (String str) -> { };
}
}
]]>
Names for references to generic values should be limited to a single uppercase letter.
4
1
or
string:upper-case(@Image) != @Image
]
]]>
extends BaseDao {
// This is ok...
}
public interface GenericDao {
// Also this
}
public interface GenericDao {
// 'e' should be an 'E'
}
public interface GenericDao {
// 'EF' is not ok.
}
]]>
Identical `catch` branches use up vertical space and increase the complexity of code without
adding functionality. It's better style to collapse identical branches into a single multi-catch
branch.
3
Avoid using if..else statements without using surrounding braces. If the code formatting
or indentation is lost then it becomes difficult to separate the code being controlled
from the rest.
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
by the rule {% rule java/codestyle/ControlStatementBraces %}.
3
Avoid using if statements without using braces to surround the code block. If the code
formatting or indentation is lost then it becomes difficult to separate the code being
controlled from the rest.
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
by the rule {% rule java/codestyle/ControlStatementBraces %}.
3
This rule finds Linguistic Naming Antipatterns. It checks for fields, that are named, as if they should
be boolean but have a different type. It also checks for methods, that according to their name, should
return a boolean, but don't. Further, it checks, that getters return something and setters won't.
Finally, it checks that methods, that start with "to" - so called transform methods - actually return
something, since according to their name, they should convert or transform one object into another.
There is additionally an option, to check for methods that contain "To" in their name - which are
also transform methods. However, this is disabled by default, since this detection is prone to
false positives.
For more information, see [Linguistic Antipatterns - What They Are and How
Developers Perceive Them](https://doi.org/10.1007/s10664-014-9350-8).
3
The Local Home interface of a Session EJB should be suffixed by 'LocalHome'.
4
The Local Interface of a Session EJB should be suffixed by 'Local'.
4
A local variable assigned only once can be declared final.
3
Configurable naming conventions for local variable declarations and other locally-scoped
variables. This rule reports variable declarations which do not match the regex that applies to their
specific kind (e.g. final variable, or catch-clause parameter). Each regex can be configured through
properties.
By default this rule uses the standard Java naming convention (Camel case).
1
Fields, formal arguments, or local variable names that are too long can make the code difficult to follow.
3
$minimum]
]]>
The EJB Specification states that any MessageDrivenBean or SessionBean should be suffixed by 'Bean'.
4
A method argument that is never re-assigned within the method can be declared final.
3
Configurable naming conventions for method declarations. This rule reports
method declarations which do not match the regex that applies to their
specific kind (e.g. JUnit test or native method). Each regex can be
configured through properties.
By default this rule uses the standard Java naming convention (Camel case).
1
Detects when a non-field has a name starting with 'm_'. This usually denotes a field and could be confusing.
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
by the more general rule
{% rule java/codestyle/LocalVariableNamingConventions %}.
3
Detects when a class or interface does not have a package definition.
3
//ClassOrInterfaceDeclaration[count(preceding::PackageDeclaration) = 0]
Since Java 1.7, numeric literals can use underscores to separate digits. This rule enforces that
numeric literals above a certain length use these underscores to increase readability.
The rule only supports decimal (base 10) literals for now. The acceptable length under which literals
are not required to have underscores is configurable via a property. Even under that length, underscores
that are misplaced (not making groups of 3 digits) are reported.
3
A method should have only one exit point, and that should be the last statement in the method.
3
0) {
return "hey"; // first exit
}
return "hi"; // second exit
}
}
]]>
Detects when a package definition contains uppercase characters.
3
//PackageDeclaration/Name[lower-case(@Image)!=@Image]
Checks for variables that are defined before they might be used. A reference is deemed to be premature if it is created right before a block of code that doesn't use it that also has the ability to return or throw an exception.
3
Remote Interface of a Session EJB should not have a suffix.
4
A Remote Home interface type of a Session EJB should be suffixed by 'Home'.
4
Short Classnames with fewer than e.g. five characters are not recommended.
4
Method names that are very short are not helpful to the reader.
3
Fields, local variables, or parameter names that are very short are not helpful to the reader.
3
Field names using all uppercase characters - Sun's Java naming conventions indicating constants - should
be declared as final.
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
by the more general rule {% rule java/codestyle/FieldNamingConventions %}.
3
If you overuse the static import feature, it can make your program unreadable and
unmaintainable, polluting its namespace with all the static members you import.
Readers of your code (including you, a few months after you wrote it) will not know
which class a static member comes from (Sun 1.5 Language Guide).
3
$maximumStaticImports]
]]>
Avoid the use of value in annotations when it's the only element.
3
This rule detects when a constructor is not necessary; i.e., when there is only one constructor and the
constructor is identical to the default constructor. The default constructor should has same access
modifier as the declaring class. In an enum type, the default constructor is implicitly private.
3
Import statements allow the use of non-fully qualified names. The use of a fully qualified name
which is covered by an import statement is redundant. Consider using the non-fully qualified name.
4
Avoid the creation of unnecessary local variables
3
Fields in interfaces and annotations are automatically `public static final`, and methods are `public abstract`.
Classes, interfaces or annotations nested in an interface or annotation are automatically `public static`
(all nested interfaces and annotations are automatically static).
Nested enums are automatically `static`.
For historical reasons, modifiers which are implied by the context are accepted by the compiler, but are superfluous.
3
Avoid the use of unnecessary return statements.
3
Use the diamond operator to let the type be inferred automatically. With the Diamond operator it is possible
to avoid duplication of the type parameters.
Instead, the compiler is now able to infer the parameter types for constructor calls,
which makes the code also more readable.
3
strings = new ArrayList(); // unnecessary duplication of type parameters
List stringsWithDiamond = new ArrayList<>(); // using the diamond operator is more concise
]]>
Useless parentheses should be removed.
4
1]
/PrimaryPrefix/Expression
[not(./CastExpression)]
[not(./ConditionalExpression)]
[not(./AdditiveExpression)]
[not(./AssignmentOperator)]
|
//Expression[not(parent::PrimaryPrefix)]/PrimaryExpression[count(*)=1]
/PrimaryPrefix/Expression
|
//Expression/ConditionalAndExpression/PrimaryExpression/PrimaryPrefix/Expression[
count(*)=1 and
count(./CastExpression)=0 and
count(./EqualityExpression/MultiplicativeExpression)=0 and
count(./ConditionalExpression)=0 and
count(./ConditionalOrExpression)=0]
|
//Expression/ConditionalOrExpression/PrimaryExpression/PrimaryPrefix/Expression[
count(*)=1 and
not(./CastExpression) and
not(./ConditionalExpression) and
not(./EqualityExpression/MultiplicativeExpression)]
|
//Expression/ConditionalExpression/PrimaryExpression/PrimaryPrefix/Expression[
count(*)=1 and
not(./CastExpression) and
not(./EqualityExpression)]
|
//Expression/AdditiveExpression[not(./PrimaryExpression/PrimaryPrefix/Literal[@StringLiteral='true'])]
/PrimaryExpression[1]/PrimaryPrefix/Expression[
count(*)=1 and
not(./CastExpression) and
not(./AdditiveExpression[@Image = '-']) and
not(./ShiftExpression) and
not(./RelationalExpression) and
not(./InstanceOfExpression) and
not(./EqualityExpression) and
not(./AndExpression) and
not(./ExclusiveOrExpression) and
not(./InclusiveOrExpression) and
not(./ConditionalAndExpression) and
not(./ConditionalOrExpression) and
not(./ConditionalExpression)]
|
//Expression/EqualityExpression/PrimaryExpression/PrimaryPrefix/Expression[
count(*)=1 and
not(./CastExpression) and
not(./AndExpression) and
not(./InclusiveOrExpression) and
not(./ExclusiveOrExpression) and
not(./ConditionalExpression) and
not(./ConditionalAndExpression) and
not(./ConditionalOrExpression) and
not(./EqualityExpression)]
]]>
Reports qualified this usages in the same class.
3
A variable naming conventions rule - customize this to your liking. Currently, it
checks for final variables that should be fully capitalized and non-final variables
that should not include underscores.
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
by the more general rules {% rule java/codestyle/FieldNamingConventions %},
{% rule java/codestyle/FormalParameterNamingConventions %}, and
{% rule java/codestyle/LocalVariableNamingConventions %}.
1
Avoid using 'while' statements without using braces to surround the code block. If the code
formatting or indentation is lost then it becomes difficult to separate the code being
controlled from the rest.
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
by the rule {% rule java/codestyle/ControlStatementBraces %}.
3
//WhileStatement[not(Statement/Block)]