com.github.sebhoss.common.annotation

Class PMDWarnings

java.lang.Object

com.github.sebhoss.common.annotation.PMDWarnings

public final class PMDWarnings
extends Object

List of PMD warnings which can be suppressed by the SuppressWarnings annotation.

See Also:

http://pmd.sourceforge.net/pmd-5.0.5/suppressing.html

Field Summary

Fields

Modifier and Type	Field and Description
static String	ABSTRACT_CLASS_WITH_ABSTRACT_METHOD The abstract class does not contain any abstract methods.
static String	ABSTRACT_CLASS_WITHOUT_ANY_METHOD If an abstract class does not provides any methods, it may be acting as a simple data container that is not meant to be instantiated.
static String	ABSTRACT_NAMING Abstract classes should be named 'AbstractXXX'.
static String	ACCESSOR_CLASS_GENERATION Instantiation by way of private constructors from outside of the constructor's class often causes the generation of an accessor.
static String	ADD_EMPTY_STRING The conversion of literals to strings by concatenating them with empty strings is inefficient.
static String	APPEND_CHARACTER_WITH_CHAR Avoid concatenating characters as strings in StringBuffer/StringBuilder.append methods.
static String	ARRAY_IS_STORED_DIRECTLY Constructors and methods receiving arrays should clone objects and store the copy.
static String	ASSIGNMENT_IN_OPERAND Avoid assignments in operands; this can make code more complicated and harder to read.
static String	ASSIGNMENT_TO_NON_FINAL_STATIC Identifies a possible unsafe usage of a static field.
static String	AT_LEAST_ONE_CONSTRUCTOR Each class should declare at least one constructor.
static String	AVOID_ACCESSIBILITY_ALTERATION Methods such as getDeclaredConstructors(), getDeclaredConstructor(Class[]) and setAccessible(), as the interface PrivilegedAction, allows for the runtime alteration of variable, class, or method visibility, even if they are private.
static String	AVOID_ARRAY_LOOPS Instead of manually copying data between two arrays, use the efficient System.arraycopy method instead.
static String	AVOID_ASSERT_AS_IDENTIFIER Use of the term 'assert' will conflict with newer versions of Java since it is a reserved word.
static String	AVOID_BRANCHING_STATEMENT_AS_LAST_IN_LOOP Using a branching statement as the last part of a loop may be a bug, and/or is confusing.
static String	AVOID_CALLING_FINALIZE The method Object.finalize() is called by the garbage collector on an object when garbage collection determines that there are no more references to the object.
static String	AVOID_CATCHING_GENERIC_EXCEPTION Avoid catching generic exceptions such as NullPointerException, RuntimeException, Exception in try-catch block.
static String	AVOID_CATCHING_NPE Code should never throw NullPointerExceptions under normal circumstances.
static String	AVOID_CATCHING_THROWABLE Catching Throwable errors is not recommended since its scope is very broad.
static String	AVOID_CONSTANTS_INTERFACE An interface should be used only to characterize the external behaviour of an implementing class: using an interface as a container of constants is a poor usage pattern and not recommended.
static String	AVOID_DECIMAL_LITERALS_IN_BIG_DECIMAL_CONSTRUCTOR One might assume that the result of "new BigDecimal(0.1)" is exactly equal to 0.1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625.
static String	AVOID_DEEPLY_NESTED_IF_STATEMENTS Avoid creating deeply nested if-then statements since they are harder to read and error-prone to maintain.
static String	AVOID_DOLLAR_SIGNS Avoid using dollar signs in variable/method/class/interface names.
static String	AVOID_DUPLICATE_LITERALS Code containing duplicate String literals can usually be improved by declaring the String as a constant field.
static String	AVOID_ENUM_AS_IDENTIFIER Use of the term 'enum' will conflict with newer versions of Java since it is a reserved word.
static String	AVOID_FIELD_NAME_MATCHING_METHOD_NAME It can be confusing to have a field name with the same name as a method.
static String	AVOID_FIELD_NAME_MATCHING_TYPE_NAME It is somewhat confusing to have a field name matching the declaring class name.
static String	AVOID_FINAL_LOCAL_VARIABLE Avoid using final local variables, turn them into fields.
static String	AVOID_INSTANCEOF_CHECKS_IN_CATCH_CLAUSE Each caught exception type should be handled in its own catch clause.
static String	AVOID_INSTANTIATING_OBJECTS_IN_LOOPS New objects created within loops should be checked to see if they can created outside them and reused.
static String	AVOID_LITERALS_IN_IF_CONDITION Avoid using hard-coded literals in conditional statements.
static String	AVOID_LOSING_EXCEPTION_INFORMATION Statements in a catch block that invoke accessors on the exception without using the information only add to code size.
static String	AVOID_MULTIPLE_UNARY_OPERATORS The use of multiple unary operators may be problematic, and/or confusing.
static String	AVOID_PREFIXING_METHOD_PARAMETERS Prefixing parameters by 'in' or 'out' pollutes the name of the parameters and reduces code readability.
static String	AVOID_PRINT_STACK_TRACE Avoid printStackTrace(); use a logger call instead.
static String	AVOID_PROTECTED_FIELD_IN_FINAL_CLASS Do not use protected fields in final classes since they cannot be subclassed.
static String	AVOID_REASSIGNING_PARAMETERS Reassigning values to incoming parameters is not recommended.
static String	AVOID_RETHROWING_EXCEPTION Catch blocks that merely rethrow a caught exception only add to code size and runtime complexity.
static String	AVOID_STRING_BUFFER_FIELD StringBuffers/StringBuilders can grow considerably, and so may become a source of memory leaks if held within objects with long lifetimes.
static String	AVOID_SYNCHRONIZED_AT_METHOD_LEVEL Method-level synchronization can cause problems when new code is added to the method.
static String	AVOID_THREAD_GROUP Avoid using java.lang.ThreadGroup; although it is intended to be used in a threaded environment it contains methods that are not thread-safe.
static String	AVOID_THROWING_NEW_INSTANCE_OF_SAME_EXCEPTION Catch blocks that merely rethrow a caught exception wrapped inside a new instance of the same type only add to code size and runtime complexity.
static String	AVOID_THROWING_NULL_POINTER_EXCEPTION Avoid throwing NullPointerExceptions.
static String	AVOID_THROWING_RAW_EXCEPTION_TYPES Avoid throwing certain exception types.
static String	AVOID_USING_HARD_CODED_IP Application with hard-coded IP addresses can become impossible to deploy in some cases.
static String	AVOID_USING_NATIVE_CODE Unnecessary reliance on Java Native Interface (JNI) calls directly reduces application portability and increases the maintenance burden.
static String	AVOID_USING_OCTAL_VALUES Integer literals should not start with zero since this denotes that the rest of literal will be interpreted as an octal value.
static String	AVOID_USING_SHORT_TYPE Java uses the 'short' type to reduce memory usage, not to optimize calculation.
static String	AVOID_USING_VOLATILE Use of the keyword 'volatile' is generally used to fine tune a Java application, and therefore, requires a good expertise of the Java Memory Model.
static String	BAD_COMPARISON Avoid equality comparisons with Double.NaN.
static String	BEAN_MEMBERS_SHOULD_SERIALIZE If a class is a bean, or is referenced by a bean directly or indirectly it needs to be serializable.
static String	BIG_INTEGER_INSTANTIATION Don't create instances of already existing BigInteger (BigInteger.ZERO, BigInteger.ONE) and for Java 1.5 onwards, BigInteger.TEN and BigDecimal (BigDecimal.ZERO, BigDecimal.ONE, BigDecimal.TEN)
static String	BOOLEAN_GET_METHOD_NAME Methods that return boolean results should be named as predicate statements to denote this.
static String	BOOLEAN_INSTANTIATION Avoid instantiating Boolean objects; you can reference Boolean.TRUE, Boolean.FALSE, or call Boolean.valueOf() instead.
static String	BOOLEAN_INVERSION Use bitwise inversion to invert boolean values - it's the fastest way to do this.
static String	BROKEN_NULL_CHECK The null check is broken since it will throw a NullPointerException itself.
static String	BYTE_INSTANTIATION Calling new Byte() causes memory allocation that can be avoided by the static Byte.valueOf().
static String	CALL_SUPER_IN_CONSTRUCTOR It is a good practice to call super() in a constructor.
static String	CHECK_RESULT_SET Always check the return values of navigation methods (next, previous, first, last) of a ResultSet.
static String	CHECK_SKIP_RESULT The skip() method may skip a smaller number of bytes than requested.
static String	CLASS_CAST_EXCEPTION_WITH_TO_ARRAY When deriving an array of a specific class from your Collection, one should provide an array of the same class as the parameter of the toArray() method.
static String	CLASS_NAMING_CONVENTIONS Class names should always begin with an upper case character.
static String	CLASS_WITH_ONLY_PRIVATE_CONSTRUCTOR_SHOULD_BE_FINAL A class with only private constructors should be final, unless the private constructor is invoked by a inner class.
static String	CLONE_METHOD_MUST_IMPLEMENT_CLONEABLE The method clone() should only be implemented if the class implements the Cloneable interface with the exception of a final method that only throws CloneNotSupportedException.
static String	CLONE_THROWS_CLONE_NOT_SUPPORTED_EXCEPTION The method clone() should throw a CloneNotSupportedException.
static String	CLOSE_RESOURCE Ensure that resources (like Connection, Statement, and ResultSet objects) are always closed after use.
static String	COLLAPSIBLE_IF_STATEMENTS Sometimes two consecutive 'if' statements can be consolidated by separating their conditions with a boolean short-circuit operator.
static String	COMMENT_CONTENT A rule for the politically correct...
static String	COMMENT_REQUIRED Denotes whether comments are required (or unwanted) for specific language elements.
static String	COMMENT_SIZE Determines whether the dimensions of non-header comments found are within the specified limits.
static String	COMPARE_OBJECTS_WITH_EQUALS Use equals() to compare object references; avoid comparing them with ==.
static String	CONFUSING_TERNARY Avoid negation within an "if" expression with an "else" clause.
static String	CONSECUTIVE_LITERAL_APPENDS Consecutively calling StringBuffer/StringBuilder.append with String literals
static String	CONSTRUCTOR_CALLS_OVERRIDABLE_METHOD Calling overridable methods during construction poses a risk of invoking methods on an incompletely constructed object and can be difficult to debug.
static String	COUPLING_BETWEEN_OBJECTS This rule counts the number of unique attributes, local variables, and return types within an object.
static String	CYCLOMATIC_COMPLEXITY Complexity directly affects maintenance costs is determined by the number of decision points in a method plus one for the method entry.
static String	DATAFLOW_ANOMALY_ANALYSIS The dataflow analysis tracks local definitions, undefinitions and references to variables on different paths on the data flow.
static String	DEFAULT_LABEL_NOT_LAST_IN_SWITCH_STATEMENT By convention, the default label should be the last label in a switch statement.
static String	DEFAULT_PACKAGE Use explicit scoping instead of the default package private level.
static String	DO_NOT_CALL_GARBAGE_COLLECTION_EXPLICITLY Calls to System.gc(), Runtime.getRuntime().gc(), and System.runFinalization() are not advised.
static String	DO_NOT_CALL_SYSTEM_EXIT Web applications should not call System.exit(), since only the web container or the application server should stop the JVM.
static String	DO_NOT_EXTEND_JAVA_LANG_ERROR Errors are system exceptions.
static String	DO_NOT_THROW_EXCEPTION_IN_FINALLY Throwing exceptions within a 'finally' block is confusing since they may mask other exceptions or code defects.
static String	DO_NOT_USE_THREADS The J2EE specification explicitly forbids the use of threads.
static String	DONT_CALL_THREAD_RUN Explicitly calling Thread.run() method will execute in the caller's thread of control.
static String	DONT_IMPORT_JAVA_LANG Avoid importing anything from the package 'java.lang'.
static String	DONT_IMPORT_SUN Avoid importing anything from the 'sun.*' packages.
static String	DONT_USE_FLOAT_TYPE_FOR_LOOP_INDICES Don't use floating point for loop indices.
static String	DOUBLE_CHECKED_LOCKING Partially created objects can be returned by the Double Checked Locking pattern when used in Java.
static String	DUPLICATE_IMPORTS Duplicate or overlapping import statements should be avoided.
static String	EMPTY_CATCH_BLOCK Empty Catch Block finds instances where an exception is caught, but nothing is done.
static String	EMPTY_FINALLY_BLOCK Empty finally blocks serve no purpose and should be removed.
static String	EMPTY_FINANLIZER Empty finalize methods serve no purpose and should be removed.
static String	EMPTY_IF_STATEMENT Empty If Statement finds instances where a condition is checked but nothing is done about it.
static String	EMPTY_INITIALIZER Empty initializers serve no purpose and should be removed.
static String	EMPTY_METHOD_IN_ABSTRACT_CLASS_SHOULD_BE_ABSTRACT Empty methods in an abstract class should be tagged as abstract.
static String	EMPTY_STATEMENT_BLOCK Empty block statements serve no purpose and should be removed.
static String	EMPTY_STATEMENT_NOT_IN_LOOP An empty statement (or a semicolon by itself) that is not used as the sole body of a 'for' or 'while' loop is probably a bug.
static String	EMPTY_STATIC_INITIALIZER An empty static initializer serve no purpose and should be removed.
static String	EMPTY_SWITCH_STATEMENTS Empty switch statements serve no purpose and should be removed.
static String	EMPTY_SYNCHRONIZED_BLOCK Empty synchronized blocks serve no purpose and should be removed.
static String	EMPTY_TRY_BLOCK Avoid empty try blocks - what's the point?
static String	EMPTY_WHILE_STATEMENT Empty While Statement finds all instances where a while statement does nothing.
static String	EQUALS_NULL Tests for null should not use the equals() method.
static String	EXCEPTION_AS_FLOW_CONTROL Using Exceptions as form of flow control is not recommended as they obscure true exceptions when debugging.
static String	EXCESSIVE_CLASS_LENGTH Excessive class file lengths are usually indications that the class may be burdened with excessive responsibilities that could be provided by external classes or functions.
static String	EXCESSIVE_IMPORTS A high number of imports can indicate a high degree of coupling within an object.
static String	EXCESSIVE_METHOD_LENGTH When methods are excessively long this usually indicates that the method is doing more than its name/signature might suggest.
static String	EXCESSIVE_PARAMETER_LIST Methods with numerous parameters are a challenge to maintain, especially if most of them share the same datatype.
static String	EXCESSIVE_PUBLIC_COUNT Classes with large numbers of public methods and attributes require disproportionate testing efforts since combinational side effects grow rapidly and increase risk.
static String	EXTENDS_OBJECT No need to explicitly extend Object.
static String	FIELD_DECLARATIONS_SHOULD_BE_AT_START_OF_CLASS Fields should be declared at the top of the class, before any method declarations, constructors, initializers or inner classes.
static String	FINAL_FIELD_COULD_BE_STATIC If a final field is assigned to a compile-time constant, it could be made static, thus saving overhead in each object at runtime.
static String	FINALIZE_DOES_NOT_CALL_SUPER_FINALIZE If the finalize() is implemented, its last action should be to call super.finalize.
static String	FINALIZE_ONLY_CALLS_SUPER_FINALIZE If the finalize() is implemented, it should do something besides just calling super.finalize().
static String	FINALIZE_OVERLOADED Methods named finalize() should not have parameters.
static String	FINALIZE_SHOULD_BE_PROTECTED When overriding the finalize(), the new method should be set as protected.
static String	FOR_LOOP_SHOULD_BE_WHILE_LOOP Some for loops can be simplified to while loops, this makes them more concise.
static String	FOR_LOOPS_MUST_USE_BRACES Avoid using 'for' statements without using curly braces.
static String	GENERICS_NAMING Names for references to generic values should be limited to a single uppercase letter.
static String	GOD_CLASS The God Class rule detects the God Class design flaw using metrics.
static String	GUARD_DEBUG_LOGGING When log messages are composed by concatenating strings, the whole section should be guarded by a isDebugEnabled() check to avoid performance and memory issues.
static String	IDEMPOTENT_OPERATIONS Avoid idempotent operations - they have no effect.
static String	IF_ELSE_STATEMENTS_MUST_USE_BRACES Avoid using if..else statements without using surrounding braces.
static String	IF_STMTS_MUST_USE_BRACES Avoid using if statements without using braces to surround the code block.
static String	IMMUTABLE_FIELD Identifies private fields whose values never change once they are initialized either in the declaration of the field or by a constructor.
static String	IMPORT_FROM_SAME_PACKAGE There is no need to import a type that lives in the same package.
static String	INEFFICIENT_EMPTY_STRING_CHECK String.trim().length() is an inefficient way to check if a String is really empty, as it creates a new String object just to check its size.
static String	INEFFICIENT_STRING_BUFFERING Avoid concatenating non-literals in a StringBuffer constructor or append() since intermediate buffers will need to be be created and destroyed by the JVM.
static String	INSTANTIATION_TO_GET_CLASS Avoid instantiating an object just to call getClass() on it; use the .class public member instead.
static String	INSUFFICIENT_STRING_BUFFER_DECLARATION Failing to pre-size a StringBuffer or StringBuilder properly could cause it to re-size many times during runtime.
static String	INTEGER_INSTANTIATION Calling new Integer() causes memory allocation that can be avoided by the static Integer.valueOf().
static String	JUMBLED_INCREMENTER Avoid jumbled loop incrementers - its usually a mistake, and is confusing even if intentional.
static String	JUNIT_4_SUITES_SHOULD_USE_SUITE_ANNOTATION In JUnit 3, test suites are indicated by the suite() method.
static String	JUNIT_4_TEST_SHOULD_USE_AFTER_ANNOTATION In JUnit 3, the tearDown method was used to clean up all data entities required in running tests.
static String	JUNIT_4_TEST_SHOULD_USE_BEFORE_ANNOTATION In JUnit 3, the setUp method was used to set up all data entities required in running tests.
static String	JUNIT_4_TEST_SHOULD_USE_TEST_ANNOTATION In JUnit 3, the framework executed all methods which started with the word test as a unit test.
static String	JUNIT_ASSERTIONS_SHOULD_INCLUDE_MESSAGE JUnit assertions should include an informative message - i.e., use the three-argument version of assertEquals(), not the two-argument version.
static String	JUNIT_SPELLING Some JUnit framework methods are easy to misspell.
static String	JUNIT_STATIC_SUITE The suite() method in a JUnit test needs to be both public and static.
static String	JUNIT_TEST_CONTAINS_TOO_MANY_ASSERTS JUnit tests should not contain too many asserts.
static String	JUNIT_TESTS_SHOULD_INCLUDE_ASSERT JUnit tests should include at least one assertion.
static String	JUNIT_USE_EXPECTED In JUnit4, use the @Test(expected) annotation to denote tests that should throw exceptions.
static String	LAW_OF_DEMETER The Law of Demeter is a simple rule, that says "only talk to friends".
static String	LOCAL_HOME_NAMING_CONVENTION The Local Home interface of a Session EJB should be suffixed by 'LocalHome'.
static String	LOCAL_INTERFACE_SESSION_NAMING_CONVENTION The Local Interface of a Session EJB should be suffixed by 'Local'.
static String	LOCAL_VARIABLE_COULD_BE_FINAL A local variable assigned only once can be declared final.
static String	LOGGER_IS_NOT_STATIC_FINAL In most cases, the Logger reference can be declared as static and final.
static String	LOGIC_INVERSION Use opposite operator instead of negating the whole expression with a logic complement operator.
static String	LONG_INSTANTIATION Calling new Long() causes memory allocation that can be avoided by the static Long.valueOf().
static String	LONG_VARIABLE Fields, formal arguments, or local variable names that are too long can make the code difficult to follow.
static String	LOOSE_COUPLING The use of implementation types as object references limits your ability to use alternate implementations in the future as requirements change.
static String	LOOSE_PACKAGE_COUPLING Avoid using classes from the configured package hierarchy outside of the package hierarchy, except when using one of the configured allowed classes.
static String	MDB_AND_SESSION_BEAN_NAMING_CONVENTION The EJB Specification states that any MessageDrivenBean or SessionBean should be suffixed by 'Bean'.
static String	METHOD_ARGUMENT_COULD_BE_FINAL A method argument that is never re-assigned within the method can be declared final.
static String	METHOD_NAMING_CONVENTIONS Method names should always begin with a lower case character, and should not contain underscores.
static String	METHOD_RETURNS_INTERNAL_ARRAY Exposing internal arrays to the caller violates object encapsulation since elements can be removed or replaced outside of the object that owns it.
static String	METHOD_WITH_SAME_NAME_AS_ENCLOSING_CLASS Non-constructor methods should not have the same name as the enclosing class.
static String	MISLEADING_VARIABLE_NAME Detects when a non-field has a name starting with 'm_'.
static String	MISPLACED_NULL_CHECK The null check here is misplaced.
static String	MISSING_BREAK_IN_SWITCH Switch statements without break or return statements for each case option may indicate problematic behaviour.
static String	MISSING_SERIAL_VERSION_UID Serializable classes should provide a serialVersionUID field.
static String	MISSING_STATIC_METHOD_IN_NON_INSTANTIATABLE_CLASS A class that has private constructors and does not have any static methods or fields cannot be used.
static String	MORE_THAN_ONE_LOGGER Normally only one logger is used in each class.
static String	NCSS_CONSTRUCTOR_COUNT This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines of code for a given constructor.
static String	NCSS_METHOD_COUNT This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines of code for a given method.
static String	NCSS_TYPE_COUNT This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines of code for a given type.
static String	NO_PACKAGE Detects when a class or interface does not have a package definition.
static String	NON_CASE_LABEL_IN_SWITCH_STATEMENT A non-case label (e.g.
static String	NON_STATIC_INITIALIZER A non-static initializer block will be called any time a constructor is invoked (just prior to invoking the constructor).
static String	NON_THREAD_SAFE_SINGLETON Non-thread safe singletons can result in bad state changes.
static String	NPATH_COMPLEXITY The NPath complexity of a method is the number of acyclic execution paths through that method.
static String	NULL_ASSIGNMENT Assigning a "null" to a variable (outside of its declaration) is usually bad form.
static String	ONE_DECLARATION_PER_LINE Java allows the use of several variables declaration of the same type on one line.
static String	ONLY_ONE_RETURN A method should have only one exit point, and that should be the last statement in the method.
static String	OPTIMIZABLE_TO_ARRAY_CALL Calls to a collection's toArray() method should specify target arrays sized to match the size of the collection.
static String	OVERRIDE_BOTH_EQUALS_AND_HASHCODE Override both public boolean Object.equals(Object other), and public int Object.hashCode(), or override neither.
static String	PACKAGE_CASE Detects when a package definition contains uppercase characters.
static String	PMD Suppresses all PMD warnings
static String	POSITION_LITERALS_FIRST_IN_COMPARISONS Position literals first in comparisons, if the second argument is null then NullPointerExceptions can be avoided, they will just return false.
static String	PREMATURE_DECLARATION Checks for variables that are defined before they might be used.
static String	PRESERVE_STACK_TRACE Throwing a new exception from a catch block without passing the original exception into the new exception will cause the original stack trace to be lost making it difficult to debug effectively.
static String	PROPER_CLONE_IMPLEMENTATION Object clone() should be implemented with super.clone().
static String	PROPER_LOGGER A logger should normally be defined private static final and be associated with the correct class.
static String	REDUNDANT_FIELD_INITIALIZER Java will initialize fields with known default values so any explicit initialization of those same defaults is redundant and results in a larger class file (approximately three additional bytecode instructions per field).
static String	REMOTE_INTERFACE_NAMING_CONVENTION Remote Interface of a Session EJB should not have a suffix.
static String	REMOTE_SESSION_INTERFACE_NAMING_CONVENTION A Remote Home interface type of a Session EJB should be suffixed by 'Home'.
static String	REPLACE_ENUMERATION_WITH_ITERATOR Consider replacing Enumeration usages with the newer java.util.Iterator
static String	REPLACE_HASHTABLE_WITH_MAP Consider replacing Hashtable usage with the newer java.util.Map if thread safety is not required.
static String	REPLACE_VECTOR_WITH_LIST Consider replacing Vector usages with the newer java.util.ArrayList if expensive thread-safe operations are not required.
static String	RETURN_EMPTY_ARRAY_RATHER_THAN_NULL For any method that returns an array, it is a better to return an empty array rather than a null reference.
static String	RETURN_FROM_FINALLY_BLOCK Avoid returning from a finally block, this can discard exceptions.
static String	SHORT_CLASS_NAME Classnames with fewer than five characters are not recommended.
static String	SHORT_INSTANTIATION Calling new Short() causes memory allocation that can be avoided by the static Short.valueOf().
static String	SHORT_METHOD_NAME Method names that are very short are not helpful to the reader.
static String	SHORT_VARIABLE Fields, local variables, or parameter names that are very short are not helpful to the reader.
static String	SIGNATURE_DECLARE_THROWS_EXCEPTION Methods that declare the generic Exception as a possible throwable are not very helpful since their failure modes are unclear.
static String	SIMPLE_DATE_FORMAT_NEEDS_LOCALE Be sure to specify a Locale when creating SimpleDateFormat instances to ensure that locale-appropriate formatting is used.
static String	SIMPLIFY_BOOLEAN_ASSERTION Avoid negation in an assertTrue or assertFalse test.
static String	SIMPLIFY_BOOLEAN_EXPRESSIONS Avoid unnecessary comparisons in boolean expressions, they serve no purpose and impacts readability.
static String	SIMPLIFY_BOOLEAN_RETURNS Avoid unnecessary if-then-else statements when returning a boolean.
static String	SIMPLIFY_CONDITIONAL No need to check for null before an instanceof; the instanceof keyword returns false when given a null argument.
static String	SIMPLIFY_STARTS_WITH Since it passes in a literal of length 1, calls to (string).startsWith can be rewritten using (string).charAt(0) at the expense of some readability.
static String	SINGULAR_FIELD Fields whose scopes are limited to just single methods do not rely on the containing object to provide them to other methods.
static String	STATIC_EJB_FIELD_SHOULD_BE_FINAL According to the J2EE specification, an EJB should not have any static fields with write access.
static String	STRING_BUFFER_INSTANTIATION_WITH_CHAR Individual character values provided as initialization arguments will be converted into integers.
static String	STRING_INSTANTIATION Avoid instantiating String objects; this is usually unnecessary since they are immutable and can be safely shared.
static String	STRING_TO_STRING Avoid calling toString() on objects already known to be string instances; this is unnecessary.
static String	SUSPICIOUS_CONSTANT_FIELD_NAME Field names using all uppercase characters - Sun's Java naming conventions indicating constants - should be declared as final.
static String	SUSPICIOUS_EQUALS_METHOD_NAME The method name and parameter number are suspiciously close to equals(Object), which can denote an intention to override the equals(Object) method.
static String	SUSPICIOUS_HASHCODE_METHOD_NAME The method name and return type are suspiciously close to hashCode(), which may denote an intention to override the hashCode() method.
static String	SUSPICIOUS_OCTAL_ESCAPE A suspicious octal escape sequence was found inside a String literal.
static String	SWITCH_DENSITY A high ratio of statements to labels in a switch statement implies that the switch statement is overloaded.
static String	SWITCH_STATEMENTS_SHOULD_HAVE_DEFAULT All switch statements should include a default option to catch any unspecified values.
static String	SYSTEM_PRINTLN References to System.(out|err).print are usually intended for debugging purposes and can remain in the codebase even in production code.
static String	TEST_CLASS_WITHOUT_TEST_CASES Test classes end with the suffix Test.
static String	TOO_FEW_BRANCHES_FOR_A_SWITCH_STATEMENT Switch statements are indended to be used to support complex branching behaviour.
static String	TOO_MANY_FIELDS Classes that have too many fields can become unwieldy and could be redesigned to have fewer fields, possibly through grouping related fields in new objects.
static String	TOO_MANY_METHODS A class with too many methods is probably a good suspect for refactoring, in order to reduce its complexity and find a way to have more fine grained objects.
static String	TOO_MANY_STATIC_IMPORTS 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.
static String	UNCOMMENTED_EMPTY_CONSTRUCTOR Uncommented Empty Constructor finds instances where a constructor does not contain statements, but there is no comment.
static String	UNCOMMENTED_EMPTY_METHOD Uncommented Empty Method finds instances where a method does not contain statements, but there is no comment.
static String	UNCONDITIONAL_IF_STATEMENT Do not use "if" statements whose conditionals are always true or always false.
static String	UNNECESSARY_BOOLEAN_ASSERTION A JUnit test assertion with a boolean literal is unnecessary since it always will evaluate to the same thing.
static String	UNNECESSARY_CASE_CHANGE Using equalsIgnoreCase() is faster than using toUpperCase/toLowerCase().equals()
static String	UNNECESSARY_CONSTRUCTOR This rule detects when a constructor is not necessary; i.e., when there is only one constructor, its public, has an empty body, and takes no arguments.
static String	UNNECESSARY_CONVERSION_TEMPORARY Avoid the use temporary objects when converting primitives to Strings.
static String	UNNECESSARY_FINAL_MODIFIER When a class has the final modifier, all the methods are automatically final and do not need to be tagged as such.
static String	UNNECESSARY_FULLY_QUALIFIED_NAME Import statements allow the use of non-fully qualified names.
static String	UNNECESSARY_LOCAL_BEFORE_RETURN Avoid the creation of unnecessary local variables.
static String	UNNECESSARY_PARENTHESES Sometimes expressions are wrapped in unnecessary parentheses, making them look like function calls.
static String	UNNECESSARY_RETURN Avoid the use of unnecessary return statements.
static String	UNNECESSARY_WRAPPER_OBJECT_CREATION Most wrapper classes provide static conversion methods that avoid the need to create intermediate objects just to create the primitive forms.
static String	UNSYCHRONIZED_STATIC_DATE_FORMATTER SimpleDateFormat instances are not synchronized.
static String	UNUSED_FORMAL_PARAMETER Avoid passing parameters to methods or constructors without actually referencing them in the method body.
static String	UNUSED_IMPORTS Avoid the use of unused import statements to prevent unwanted dependencies.
static String	UNUSED_LOCAL_VARIABLE Detects when a local variable is declared and/or assigned, but not used.
static String	UNUSED_MODIFIER Fields in interfaces are automatically public static final, and methods are public abstract.
static String	UNUSED_NULL_CHECK_IN_EQUALS After checking an object reference for null, you should invoke equals() on that object rather than passing it to another object's equals() method.
static String	UNUSED_PRIVATE_FIELD Detects when a private field is declared and/or assigned a value, but not used.
static String	UNUSED_PRIVATE_METHOD Unused Private Method detects when a private method is declared but is unused.
static String	USE_ARRAY_LIST_INSTEAD_OF_VECTOR ArrayList is a much better Collection implementation than Vector if thread-safe operation is not required.
static String	USE_ARRAYS_AS_LIST The java.util.Arrays class has a "asList" method that should be used when you want to create a new List from an array of objects.
static String	USE_ASSERT_EQUALS_INSTEAD_OF_ASSERT_TRUE This rule detects JUnit assertions in object equality.
static String	USE_ASSERT_NULL_INSTEAD_OF_ASSERT_TRUE This rule detects JUnit assertions in object references equality.
static String	USE_ASSERT_SAME_INSTEAD_OF_ASSERT_TRUE This rule detects JUnit assertions in object references equality.
static String	USE_ASSERT_TRUE_INSTEAD_OF_ASSERT_EQUALS When asserting a value is the same as a boolean literal, use assertTrue/assertFalse, instead of assertEquals.
static String	USE_COLLECTION_IS_EMPTY The isEmpty() method on java.util.Collection is provided to determine if a collection has any elements.
static String	USE_CONCURRENT_HASH_MAP Since Java5 brought a new implementation of the Map designed for multi-threaded access, you can perform efficient map reads without blocking other threads.
static String	USE_CORRECT_EXCEPTION_LOGGING To make sure the full stacktrace is printed out, use the logging statement with two arguments: a String and a Throwable.
static String	USE_EQUALS_TO_COMPARE_STRINGS Using '==' or '!=' to compare strings only works if intern version is used on both sides.
static String	USE_INDEX_OF_CHAR Use String.indexOf(char) when checking for the index of a single character; it executes faster.
static String	USE_LOCALE_WITH_CASE_CONVERSIONS When doing String.toLowerCase()/toUpperCase() conversions, use Locales to avoids problems with languages that have unusual conventions, i.e.
static String	USE_NOTIFY_ALL_INSTEAD_OF_NOTIFY Thread.notify() awakens a thread monitoring the object.
static String	USE_OBJECT_FOR_CLEARER_API When you write a public method, you should be thinking in terms of an API.
static String	USE_PROPER_CLASS_LOADER In J2EE, the getClassLoader() method might not work as expected.
static String	USE_SINGLETON For classes that only have static methods, consider making them Singletons.
static String	USE_STRING_BUFFER_FOR_STRING_APPENDS The use of the '+=' operator for appending strings causes the JVM to create and use an internal StringBuffer.
static String	USE_STRING_BUFFER_LENGTH Use StringBuffer.length() to determine StringBuffer length rather than using StringBuffer.toString().equals("") or StringBuffer.toString().length() == ...
static String	USE_VARARGS Java 5 introduced the varargs parameter declaration for methods and constructors.
static String	USELESS_OPERATION_ON_IMMUTABLE An operation on an Immutable object (String, BigDecimal or BigInteger) won't change the object itself since the result of the operation is a new object.
static String	USELESS_OVERRIDING_METHOD The overriding method merely calls the same method defined in a superclass.
static String	USELESS_PARANTHESES Useless parentheses should be removed.
static String	USELESS_STRING_VALUE_OF No need to call String.valueOf to append to a string; just use the valueOf() argument directly.
static String	VARIABLE_NAMING_CONVENTIONS A variable naming conventions rule - customize this to your liking.
static String	WHILE_LOOPS_MUST_USE_BRACES Avoid using 'while' statements without using braces to surround the code block.

Method Summary

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

PMD

public static final String PMD

Suppresses all PMD warnings

See Also:

Constant Field Values

JUMBLED_INCREMENTER

public static final String JUMBLED_INCREMENTER

Avoid jumbled loop incrementers - its usually a mistake, and is confusing even if intentional.

Example

 public class JumbledIncrementerRule {
     public void foo() {
         for (int i = 0; i < 10; i++) { // only references 'i'
             for (int k = 0; k < 20; i++) { // references both 'i' and 'k'
                 System.out.println("Hello");
             }
         }
     }
 }
 

Since:

PMD 1.0

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

FOR_LOOP_SHOULD_BE_WHILE_LOOP

public static final String FOR_LOOP_SHOULD_BE_WHILE_LOOP

Some for loops can be simplified to while loops, this makes them more concise.

Example

 public class Foo {
     void bar() {
         // No Init or Update part, may as well be: while (true)
         for (; true;) {
             // do stuff..
         }
     }
 }
 

Since:

PMD 1.02

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

OVERRIDE_BOTH_EQUALS_AND_HASHCODE

public static final String OVERRIDE_BOTH_EQUALS_AND_HASHCODE

Override both public boolean Object.equals(Object other), and public int Object.hashCode(), or override neither. Even if you are inheriting a hashCode() from a parent class, consider implementing hashCode and explicitly delegating to your superclass.

Example

 public class Bar { // poor, missing a hashcode() method
     public boolean equals(Object o) {
         // do some comparison
     }
 }
 
 public class Baz { // poor, missing an equals() method
     public int hashCode() {
         // return some hash value
     }
 }
 
 public class Foo { // perfect, both methods provided
     public boolean equals(Object other) {
         // do some comparison
     }
 
     public int hashCode() {
         // return some hash value
     }
 }
 

Since:

PMD 0.4

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

DOUBLE_CHECKED_LOCKING

public static final String DOUBLE_CHECKED_LOCKING

Partially created objects can be returned by the Double Checked Locking pattern when used in Java. An optimizing JRE may assign a reference to the baz variable before it creates the object the reference is intended to point to.

Example

 public class Foo {
     Object baz;
 
     Object bar() {
         if (baz == null) { // baz may be non-null yet not fully created
             synchronized (this) {
                 if (baz == null) {
                     baz = new Object();
                 }
             }
         }
         return baz;
     }
 }
 

Since:

PMD 1.04

See Also:

http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html, PMD Basic Rule Set Documentation, Constant Field Values

RETURN_FROM_FINALLY_BLOCK

public static final String RETURN_FROM_FINALLY_BLOCK

Avoid returning from a finally block, this can discard exceptions.

Example

 public class Bar {
     public String foo() {
         try {
             throw new Exception("My Exception");
         } catch (Exception e) {
             throw e;
         } finally {
             return "A. O. K."; // return not recommended here
         }
     }
 }
 

Since:

PMD 1.05

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

UNCONDITIONAL_IF_STATEMENT

public static final String UNCONDITIONAL_IF_STATEMENT

Do not use "if" statements whose conditionals are always true or always false.

Example

 public class Foo {
     public void close() {
         if (true) { // fixed conditional, not recommended
             // ...
         }
     }
 }
 

Since:

PMD 1.5

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

BOOLEAN_INSTANTIATION

public static final String BOOLEAN_INSTANTIATION

Avoid instantiating Boolean objects; you can reference Boolean.TRUE, Boolean.FALSE, or call Boolean.valueOf() instead.

Example

Boolean buz = Boolean.valueOf(false); // ...., just reference Boolean.FALSE

Boolean bar = new Boolean("true"); // unnecessary creation, just reference Boolean.TRUE


Since:

PMD 1.2

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

COLLAPSIBLE_IF_STATEMENTS

public static final String COLLAPSIBLE_IF_STATEMENTS

Sometimes two consecutive 'if' statements can be consolidated by separating their conditions with a boolean short-circuit operator.

Example

 void bar() {
     if (x) { // original implementation
         if (y) {
             // do stuff
         }
     }
 }
 
 void bar() {
     if (x && y) { // optimized implementation
         // do stuff
     }
 }
 

Since:

PMD 3.1

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

CLASS_CAST_EXCEPTION_WITH_TO_ARRAY

public static final String CLASS_CAST_EXCEPTION_WITH_TO_ARRAY

When deriving an array of a specific class from your Collection, one should provide an array of the same class as the parameter of the toArray() method. Doing otherwise you will will result in a ClassCastException.

Example

 Collection c = new ArrayList();
 Integer obj = new Integer(1);
 c.add(obj);
 
 // this would trigger the rule (and throw a ClassCastException if executed)
 Integer[] a = (Integer[]) c.toArray();
 
 // this is fine and will not trigger the rule
 Integer[] b = (Integer[]) c.toArray(new Integer[c.size()]);
 

Since:

PMD 3.4

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

AVOID_DECIMAL_LITERALS_IN_BIG_DECIMAL_CONSTRUCTOR

public static final String AVOID_DECIMAL_LITERALS_IN_BIG_DECIMAL_CONSTRUCTOR

One might assume that the result of "new BigDecimal(0.1)" is exactly equal to 0.1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding. The (String) constructor, on the other hand, is perfectly predictable: 'new BigDecimal("0.1")' is exactly equal to 0.1, as one would expect. Therefore, it is generally recommended that the (String) constructor be used in preference to this one.

Example


BigDecimal bd = new BigDecimal(1.123); // loss of precision, this would trigger the rule
BigDecimal bd = new BigDecimal("1.123");// preferred approach
BigDecimal bd = new BigDecimal(12); // preferred approach, ok for integer values


Since:

PMD 3.4

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

MISPLACED_NULL_CHECK

public static final String MISPLACED_NULL_CHECK

The null check here is misplaced. If the variable is null a NullPointerException will be thrown. Either the check is useless (the variable will never be "null") or it is incorrect.

Example

 public class Foo {
     void bar() {
         if (a.equals(baz) && a != null) {
         }
     }
 }
 
 public class Foo {
     void bar() {
         if (a.equals(baz) || a == null) {
         }
     }
 }
 

Since:

PMD 3.5

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

AVOID_THREAD_GROUP

public static final String AVOID_THREAD_GROUP

Avoid using java.lang.ThreadGroup; although it is intended to be used in a threaded environment it contains methods that are not thread-safe.

Example

 public class Bar {
     void buz() {
         ThreadGroup tg = new ThreadGroup("My threadgroup");
         tg = new ThreadGroup(tg, "my thread group");
         tg = Thread.currentThread().getThreadGroup();
         tg = System.getSecurityManager().getThreadGroup();
     }
 }
 

Since:

PMD 3.6

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

BROKEN_NULL_CHECK

public static final String BROKEN_NULL_CHECK

The null check is broken since it will throw a NullPointerException itself. It is likely that you used || instead of && or vice versa.

Example

 public String bar(String string) {
     // should be &&
     if (string != null || !string.equals(""))
         return string;
     // should be ||
     if (string == null && string.equals(""))
         return string;
 }
 

Since:

PMD 3.8

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

BIG_INTEGER_INSTANTIATION

public static final String BIG_INTEGER_INSTANTIATION

Don't create instances of already existing BigInteger (BigInteger.ZERO, BigInteger.ONE) and for Java 1.5 onwards, BigInteger.TEN and BigDecimal (BigDecimal.ZERO, BigDecimal.ONE, BigDecimal.TEN)

Example


BigInteger bi = new BigInteger(1); // reference BigInteger.ONE instead
BigInteger bi2 = new BigInteger("0"); // reference BigInteger.ZERO instead
BigInteger bi3 = new BigInteger(0.0); // reference BigInteger.ZERO instead
BigInteger bi4;
bi4 = new BigInteger(0); // reference BigInteger.ZERO instead


Since:

PMD 3.9

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

AVOID_USING_OCTAL_VALUES

public static final String AVOID_USING_OCTAL_VALUES

Integer literals should not start with zero since this denotes that the rest of literal will be interpreted as an octal value.

Example


int i = 012; // set i with 10 not 12
int j = 010; // set j with 8 not 10
k = i * j; // set k with 80 not 120


Since:

PMD 3.9

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

AVOID_USING_HARD_CODED_IP

public static final String AVOID_USING_HARD_CODED_IP

Application with hard-coded IP addresses can become impossible to deploy in some cases. Externalizing IP adresses is preferable.

Example

 public class Foo {
     private String ip = "127.0.0.1"; // not recommended
 }
 

Since:

4.1

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

CHECK_RESULT_SET

public static final String CHECK_RESULT_SET

Always check the return values of navigation methods (next, previous, first, last) of a ResultSet. If the value return is 'false', it should be handled properly.

Example


Statement stat = conn.createStatement();
ResultSet rst = stat.executeQuery("SELECT name FROM person");
rst.next(); // what if it returns false? bad form
String firstName = rst.getString(1);

Statement stat = conn.createStatement();
ResultSet rst = stat.executeQuery("SELECT name FROM person");
if (rst.next()) { // result is properly examined and used
String firstName = rst.getString(1);
} else {
// handle missing data
}


Since:

PMD 4.1

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

AVOID_MULTIPLE_UNARY_OPERATORS

public static final String AVOID_MULTIPLE_UNARY_OPERATORS

The use of multiple unary operators may be problematic, and/or confusing. Ensure that the intended usage is not a bug, or consider simplifying the expression.

Example


// These are typo bugs, or at best needlessly complex and confusing:
int i = - -1;
int j = + - +1;
int z = ~~2;
boolean b = !!true;
boolean c = !!!true;

// These are better:
int i = 1;
int j = -1;
int z = 2;
boolean b = true;
boolean c = false;

// And these just make your brain hurt:
int i = ~-2;
int j = -~7;


Since:

PMD 4.2

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

EXTENDS_OBJECT

public static final String EXTENDS_OBJECT

No need to explicitly extend Object.

Example

 public class Foo extends Object { // not required
 }
 

Since:

PMD 5.0

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

CHECK_SKIP_RESULT

public static final String CHECK_SKIP_RESULT

The skip() method may skip a smaller number of bytes than requested. Check the returned value to find out if it was the case or not.

Example

 public class Foo {
 
    private FileInputStream _s = new FileInputStream("file");
 
    public void skip(int n) throws IOException {
       _s.skip(n); // You are not sure that exactly n bytes are skipped
    }
 
    public void skipExactly(int n) throws IOException {
       while (n != 0) {
          long skipped = _s.skip(n);
          if (skipped == 0)
             throw new EOFException();
          n -= skipped;
       }
    }
 

Since:

PMD 5.0

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

AVOID_BRANCHING_STATEMENT_AS_LAST_IN_LOOP

public static final String AVOID_BRANCHING_STATEMENT_AS_LAST_IN_LOOP

Using a branching statement as the last part of a loop may be a bug, and/or is confusing. Ensure that the usage is not a bug, or consider using another approach.

Example

 // unusual use of branching statement in a loop
 for (int i = 0; i < 10; i++) {
     if (i * i <= 25) {
         continue;
     }
     break;
 }
 
 // this makes more sense...
 for (int i = 0; i < 10; i++) {
     if (i * i > 25) {
         break;
     }
 }
 

Since:

PMD 5.0

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

DONT_CALL_THREAD_RUN

public static final String DONT_CALL_THREAD_RUN

Explicitly calling Thread.run() method will execute in the caller's thread of control. Instead, call Thread.start() for the intended behavior.

Example


Thread t = new Thread();
t.run(); // use t.start() instead
new Thread().run(); // same violation


Since:

PMD 4.3

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

DONT_USE_FLOAT_TYPE_FOR_LOOP_INDICES

public static final String DONT_USE_FLOAT_TYPE_FOR_LOOP_INDICES

Don't use floating point for loop indices. If you must use floating point, use double unless you're certain that float provides enough precision and you have a compelling performance need (space or time).

Example

 public class Count {
     public static void main(String[] args) {
         final int START = 2000000000;
         int count = 0;
         for (float f = START; f < START + 50; f++)
             count++;
         // Prints 0 because (float) START == (float) (START + 50).
         System.out.println(count);
         // The termination test misbehaves due to floating point granularity.
     }
 }
 

Since:

PMD 4.3

See Also:

PMD Basic Rule Set Documentation, Constant Field Values

IF_STMTS_MUST_USE_BRACES

public static final String IF_STMTS_MUST_USE_BRACES

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.

Example

 if (foo) // not recommended
     x++;
 
 if (foo) { // preferred approach
     x++;
 }
 

Since:

PMD 1.0

See Also:

PMD Braces Rule Set Documentation, Constant Field Values

WHILE_LOOPS_MUST_USE_BRACES

public static final String WHILE_LOOPS_MUST_USE_BRACES

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.

Example

 while (true)
     // not recommended
     x++;
 
 while (true) { // preferred approach
     x++;
 }
 

Since:

PMD 0.7

See Also:

PMD Braces Rule Set Documentation, Constant Field Values

IF_ELSE_STATEMENTS_MUST_USE_BRACES

public static final String IF_ELSE_STATEMENTS_MUST_USE_BRACES

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.

Example

 // this is OK
 if (foo)
     x++;
 
 // but this is not
 if (foo)
     x = x + 1;
 else
     x = x - 1;
 

Since:

PMD 0.2

See Also:

PMD Braces Rule Set Documentation, Constant Field Values

FOR_LOOPS_MUST_USE_BRACES

public static final String FOR_LOOPS_MUST_USE_BRACES

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.

Example

 for (int i = 0; i < 42; i++)
     foo();
 

Since:

PMD 0.7

See Also:

PMD Braces Rule Set Documentation, Constant Field Values

PROPER_CLONE_IMPLEMENTATION

public static final String PROPER_CLONE_IMPLEMENTATION

Object clone() should be implemented with super.clone().

Example

 class Foo {
     public Object clone() {
         return new Foo(); // This is bad
     }
 }
 

Since:

PMD 1.4

See Also:

PMD Clone Implementation Rule Set Documentation, Constant Field Values

CLONE_THROWS_CLONE_NOT_SUPPORTED_EXCEPTION

public static final String CLONE_THROWS_CLONE_NOT_SUPPORTED_EXCEPTION

The method clone() should throw a CloneNotSupportedException.

Example

 public class MyClass implements Cloneable {
     public Object clone() { // will cause an error
         MyClass clone = (MyClass) super.clone();
         return clone;
     }
 }
 
 

Since:

PMD 1.9

See Also:

PMD Clone Implementation Rule Set Documentation, Constant Field Values

CLONE_METHOD_MUST_IMPLEMENT_CLONEABLE

public static final String CLONE_METHOD_MUST_IMPLEMENT_CLONEABLE

The method clone() should only be implemented if the class implements the Cloneable interface with the exception of a final method that only throws CloneNotSupportedException.

Example

 public class MyClass {
     public Object clone() throws CloneNotSupportedException {
         return foo;
     }
 }
 

Since:

PMD 1.9

See Also:

PMD Clone Implementation Rule Set Documentation, Constant Field Values

NPATH_COMPLEXITY

public static final String NPATH_COMPLEXITY

The NPath complexity of a method is the number of acyclic execution paths through that method. A threshold of 200 is generally considered the point where measures should be taken to reduce complexity and increase readability.

Example

 void bar() { // this is something more complex than it needs to be,
     if (y) {    // it should be broken down into smaller methods or functions
         for (j = 0; j < m; j++) {
             if (j > r) {
                 doSomething();
                 while (f < 5 ) {
                     anotherThing();
                     f -= 27;
                     }
                 } else {
                     tryThis();
                 }
             }
         }
         if ( r - n > 45) {
            while (doMagic()) {
               findRabbits();
            }
         }
         try {
             doSomethingDangerous();
         } catch (Exception ex) {
             makeAmends();
             } finally {
                 dontDoItAgain();
                 }
     }
 }
 

Since:

PMD 3.9

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

EXCESSIVE_METHOD_LENGTH

public static final String EXCESSIVE_METHOD_LENGTH

When methods are excessively long this usually indicates that the method is doing more than its name/signature might suggest. They also become challenging for others to digest since excessive scrolling causes readers to lose focus. Try to reduce the method length by creating helper methods and removing any copy/pasted code.

Example

 public void doSomething() {
     System.out.println("Hello world!");
     System.out.println("Hello world!");
     // 98 copies omitted for brevity.
 }
 

Since:

PMD 0.6

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

EXCESSIVE_PARAMETER_LIST

public static final String EXCESSIVE_PARAMETER_LIST

Methods with numerous parameters are a challenge to maintain, especially if most of them share the same datatype. These situations usually denote the need for new objects to wrap the numerous parameters.

Example

 public void addPerson(       // too many arguments liable to be mixed up
     int birthYear, int birthMonth, int birthDate, int height, int weight, int ssn) {
 
     . . . .
 }
  
 public void addPerson(      // preferred approach
     Date birthdate, BodyMeasurements measurements, int ssn) {
 
     . . . .
 }
 

Since:

PMD 0.9

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

EXCESSIVE_CLASS_LENGTH

public static final String EXCESSIVE_CLASS_LENGTH

Excessive class file lengths are usually indications that the class may be burdened with excessive responsibilities that could be provided by external classes or functions. In breaking these methods apart the code becomes more managable and ripe for reuse.

Example

 public class Foo {
     public void bar1() {
         // 1000 lines of code
     }
 
     public void bar2() {
         // 1000 lines of code
     }
 
     public void bar3() {
         // 1000 lines of code
     }
 
     public void barN() {
         // 1000 lines of code
     }
 }
 

Since:

PMD 0.6

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

CYCLOMATIC_COMPLEXITY

public static final String CYCLOMATIC_COMPLEXITY

Complexity directly affects maintenance costs is determined by the number of decision points in a method plus one for the method entry. The decision points include 'if', 'while', 'for', and 'case labels' calls. Generally, numbers ranging from 1-4 denote low complexity, 5-7 denote moderate complexity, 8-10 denote high complexity, and 11+ is very high complexity.

Example

 public class Foo {       // This has a Cyclomatic Complexity = 12
 1   public void example()  {
 2       if (a == b)  {
 3           if (a1 == b1) {
                 fiddle();
 4           } else if a2 == b2) {
                 fiddle();
             }  else {
                 fiddle();
             }
 5       } else if (c == d) {
 6           while (c == d) {
                 fiddle();
             }
 7        } else if (e == f) {
 8           for (int n = 0; n < h; n++) {
                 fiddle();
             }
         } else{
             switch (z) {
 9               case 1:
                     fiddle();
                     break;
 10              case 2:
                     fiddle();
                     break;
 11              case 3:
                     fiddle();
                     break;
 12              default:
                     fiddle();
                     break;
             }
         }
     }
 }
 

Since:

PMD 1.03

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

EXCESSIVE_PUBLIC_COUNT

public static final String EXCESSIVE_PUBLIC_COUNT

Classes with large numbers of public methods and attributes require disproportionate testing efforts since combinational side effects grow rapidly and increase risk. Refactoring these classes into smaller ones not only increases testability and reliability but also allows new variations to be developed easily.

Example

 public class Foo {
     public String   value;
     public Bar      something;
     public Variable var;
 
     // [... more more public attributes ...]
 
     public void doWork() {
     }
 
     public void doMoreWork() {
     }
 
     public void doWorkAgain() {
     }
     // [... more more public methods ...]
 }
 

Since:

PMD 1.04

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

TOO_MANY_FIELDS

public static final String TOO_MANY_FIELDS

Classes that have too many fields can become unwieldy and could be redesigned to have fewer fields, possibly through grouping related fields in new objects. For example, a class with individual city/state/zip fields could park them within a single Address field.

Example

 public class Person { // too many separate fields
     int   birthYear;
     int   birthMonth;
     int   birthDate;
     float height;
     float weight;
 }
 
 public class Person { // this is more manageable
     Date             birthDate;
     BodyMeasurements measurements;
 }
 

Since:

PMD 3.0

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

NCSS_METHOD_COUNT

public static final String NCSS_METHOD_COUNT

This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines of code for a given method. NCSS ignores comments, and counts actual statements. Using this algorithm, lines of code that are split are counted as one.

Example

 public class Foo extends Bar {
     public int methd() {
         super.methd();
 
         // this method only has 1 NCSS lines
         return 1;
     }
 }
 

Since:

PMD 3.9

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

NCSS_TYPE_COUNT

public static final String NCSS_TYPE_COUNT

This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines of code for a given type. NCSS ignores comments, and counts actual statements. Using this algorithm, lines of code that are split are counted as one.

Example

 public class Foo extends Bar {
     public Foo() {
         // this class only has 6 NCSS lines
         super();
 
         super.foo();
     }
 }
 

Since:

PMD 3.9

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

NCSS_CONSTRUCTOR_COUNT

public static final String NCSS_CONSTRUCTOR_COUNT

This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines of code for a given constructor. NCSS ignores comments, and counts actual statements. Using this algorithm, lines of code that are split are counted as one.

Example

 public class Foo extends Bar {
     public Foo() {
         super();
 
         // this constructor only has 1 NCSS lines
         super.foo();
     }
 }
 

Since:

PMD 3.9

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

TOO_MANY_METHODS

public static final String TOO_MANY_METHODS

A class with too many methods is probably a good suspect for refactoring, in order to reduce its complexity and find a way to have more fine grained objects.

Since:

PMD 4.2

See Also:

PMD Code Size Rule Set Documentation, Constant Field Values

COMMENT_REQUIRED

public static final String COMMENT_REQUIRED

Denotes whether comments are required (or unwanted) for specific language elements.

Since:

PMD 5.0

See Also:

PMD Comments Rule Set Documentation, Constant Field Values

COMMENT_SIZE

public static final String COMMENT_SIZE

Determines whether the dimensions of non-header comments found are within the specified limits.

Since:

PMD 5.0

See Also:

PMD Comments Rule Set Documentation, Constant Field Values

COMMENT_CONTENT

public static final String COMMENT_CONTENT

A rule for the politically correct... we don't want to offend anyone.

Since:

PMD 5.0

See Also:

PMD Comments Rule Set Documentation, Constant Field Values

UNNECESSARY_CONSTRUCTOR

public static final String UNNECESSARY_CONSTRUCTOR

This rule detects when a constructor is not necessary; i.e., when there is only one constructor, its public, has an empty body, and takes no arguments.

Example

 public class Foo {
     public Foo() {
     }
 }
 

Since:

PMD 1.0

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

NULL_ASSIGNMENT

public static final String NULL_ASSIGNMENT

Assigning a "null" to a variable (outside of its declaration) is usually bad form. Sometimes, this type of assignment is an indication that the programmer doesn't completely understand what is going on in the code. NOTE: This sort of assignment may used in some cases to dereference objects and encourage garbage collection.

Example

 public void bar() {
     Object x = null; // this is OK
     x = new Object();
     // big, complex piece of code here
     x = null; // this is not required
     // big, complex piece of code here
 }
 

Since:

PMD 1.02

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

ONLY_ONE_RETURN

public static final String ONLY_ONE_RETURN

A method should have only one exit point, and that should be the last statement in the method.

Example

 public class OneReturnOnly1 {
     public void foo(int x) {
         if (x > 0) {
             return "hey"; // first exit
         }
         return "hi"; // second exit
     }
 }
 

Since:

PMD 1.0

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

ASSIGNMENT_IN_OPERAND

public static final String ASSIGNMENT_IN_OPERAND

Avoid assignments in operands; this can make code more complicated and harder to read.

Example

 public void bar() {
     int x = 2;
     if ((x = getX()) == 3) {
         System.out.println("3!");
     }
 }
 

Since:

PMD 1.03

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

AT_LEAST_ONE_CONSTRUCTOR

public static final String AT_LEAST_ONE_CONSTRUCTOR

Each class should declare at least one constructor.

Example

 public class Foo {
    // missing constructor
   public void doSomething() { ... }
   public void doOtherThing { ... }
 }
 

Since:

PMD 1.04

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

DONT_IMPORT_SUN

public static final String DONT_IMPORT_SUN

Avoid importing anything from the 'sun.*' packages. These packages are not portable and are likely to change.

Example

 import sun.misc.foo;
 

Since:

PMD 1.5

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

SUSPICIOUS_OCTAL_ESCAPE

public static final String SUSPICIOUS_OCTAL_ESCAPE

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".

Example

 public void foo() {
     // interpreted as octal 12, followed by character '8'
     System.out.println("suspicious: \128");
 }
 

Since:

PMD 1.5

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

CALL_SUPER_IN_CONSTRUCTOR

public static final String CALL_SUPER_IN_CONSTRUCTOR

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.

Example

 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
     }
 }
 

Since:

PMD 3.0

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

UNNECESSARY_PARENTHESES

public static final String UNNECESSARY_PARENTHESES

Sometimes expressions are wrapped in unnecessary parentheses, making them look like function calls.

Example

 public class Foo {
     boolean bar() {
         return (true);
     }
 }
 

Since:

PMD 3.1

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

DEFAULT_PACKAGE

public static final String DEFAULT_PACKAGE

Use explicit scoping instead of the default package private level.

Since:

PMD 3.4

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

BOOLEAN_INVERSION

public static final String BOOLEAN_INVERSION

Use bitwise inversion to invert boolean values - it's the fastest way to do this. See http://www.javaspecialists.co.za/archive/newsletter.do?issue=042&locale=en_US for specific details

Example

 boolean b = true;
 b = !b; // slow
 b ˆ= true; // fast
 

Since:

PMD 3.5

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

DATAFLOW_ANOMALY_ANALYSIS

public static final String DATAFLOW_ANOMALY_ANALYSIS

The dataflow analysis tracks local definitions, undefinitions and references to variables on different paths on the data flow. From those informations there can be found various problems. 1. UR - Anomaly: There is a reference to a variable that was not defined before. This is a bug and leads to an error. 2. DU - Anomaly: A recently defined variable is undefined. These anomalies may appear in normal source text. 3. DD - Anomaly: A recently defined variable is redefined. This is ominous but don't have to be a bug.

Example

 public void foo() {
     int buz = 5;
     buz = 6; // redefinition of buz -> dd-anomaly
     foo(buz);
     buz = 2;
 } // buz is undefined when leaving scope -> du-anomaly
 

Since:

PMD 3.9

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

AVOID_FINAL_LOCAL_VARIABLE

public static final String AVOID_FINAL_LOCAL_VARIABLE

Avoid using final local variables, turn them into fields.

Example

 public class MyClass {
     public void foo() {
         final String finalLocalVariable;
     }
 }
 

Since:

PMD 4.1

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

AVOID_USING_SHORT_TYPE

public static final String AVOID_USING_SHORT_TYPE

Java uses the 'short' type to reduce memory usage, not to optimize calculation. In fact, the JVM does not have any arithmetic capabilities for the short type: the JVM must convert the short into an int, do the proper calculation and convert the int back to a short. Thus any storage gains found through use of the 'short' type may be offset by adverse impacts on performance.

Example

 public class UsingShort {
     private short doNotUseShort = 0;
 
     public UsingShort() {
         short shouldNotBeUsed = 1;
         doNotUseShort += shouldNotBeUsed;
     }
 }
 

Since:

PMD 4.1

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

AVOID_USING_VOLATILE

public static final String AVOID_USING_VOLATILE

Use of the keyword 'volatile' is generally used to fine tune a Java application, and therefore, requires a good expertise of the Java Memory Model. Moreover, its range of action is somewhat misknown. Therefore, the volatile keyword should not be used for maintenance purpose and portability.

Example

 public class ThrDeux {
     private volatile String var1; // not suggested
     private String          var2; // preferred
 }
 

Since:

PMD 4.1

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

AVOID_USING_NATIVE_CODE

public static final String AVOID_USING_NATIVE_CODE

Unnecessary reliance on Java Native Interface (JNI) calls directly reduces application portability and increases the maintenance burden.

Example

 public class SomeJNIClass {
 
     public SomeJNIClass() {
         System.loadLibrary("nativelib");
     }
 
     static {
         System.loadLibrary("nativelib");
     }
 
     public void invalidCallsInMethod() throws SecurityException, NoSuchMethodException {
         System.loadLibrary("nativelib");
     }
 }
 

Since:

PMD 4.1

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

AVOID_ACCESSIBILITY_ALTERATION

public static final String AVOID_ACCESSIBILITY_ALTERATION

Methods such as getDeclaredConstructors(), getDeclaredConstructor(Class[]) and setAccessible(), as the interface PrivilegedAction, allows for the runtime alteration of variable, class, or method visibility, even if they are private. This violates the principle of encapsulation.

Example

 public class Violation {
     public void invalidCallsInMethod() throws SecurityException, NoSuchMethodException {
         // Possible call to forbidden getDeclaredConstructors
         Class[] arrayOfClass = new Class[1];
         this.getClass().getDeclaredConstructors();
         this.getClass().getDeclaredConstructor(arrayOfClass);
         Class clazz = this.getClass();
         clazz.getDeclaredConstructor(arrayOfClass);
         clazz.getDeclaredConstructors();
         // Possible call to forbidden setAccessible
         clazz.getMethod("", arrayOfClass).setAccessible(false);
         AccessibleObject.setAccessible(null, false);
         Method.setAccessible(null, false);
         Method[] methodsArray = clazz.getMethods();
         int nbMethod;
         for (nbMethod = 0; nbMethod < methodsArray.length; nbMethod++) {
             methodsArray[nbMethod].setAccessible(false);
         }
 
         // Possible call to forbidden PrivilegedAction
         PrivilegedAction priv = (PrivilegedAction) new Object();
         priv.run();
     }
 }
 

Since:

PMD 4.1

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

DO_NOT_CALL_GARBAGE_COLLECTION_EXPLICITLY

public static final String DO_NOT_CALL_GARBAGE_COLLECTION_EXPLICITLY

Calls to System.gc(), Runtime.getRuntime().gc(), and System.runFinalization() are not advised. Code should have the same behavior whether the garbage collection is disabled using the option -Xdisableexplicitgc or not. Moreover, "modern" jvms do a very good job handling garbage collections. If memory usage issues unrelated to memory leaks develop within an application, it should be dealt with JVM options rather than within the code itself.

Example

 public class GCCall {
     public GCCall() {
         // Explicit gc call !
         System.gc();
     }
 
     public void doSomething() {
     // Explicit gc call !
        Runtime.getRuntime().gc();
     }
 
     public explicitGCcall() { // Explicit gc call ! System.gc(); }
 
     public void doSomething() { // Explicit gc call ! Runtime.getRuntime().gc(); }
 }
 

Since:

PMD 4.2

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

ONE_DECLARATION_PER_LINE

public static final String ONE_DECLARATION_PER_LINE

Java allows the use of several variables declaration of the same type on one line. However, it can lead to quite messy code. This rule looks for several declarations on the same line.

Example

 public class OneDeclaration {
     String name, lastname; // combined declaration, a violation
 }
 

Since:

PMD 5.0

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

AVOID_PREFIXING_METHOD_PARAMETERS

public static final String AVOID_PREFIXING_METHOD_PARAMETERS

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.

Example

 // Not really clear
 public class Foo {
     public void bar(int inLeftOperand, Result outRightOperand) {
         outRightOperand.setValue(inLeftOperand * outRightOperand.getValue());
     }
 }
 
 // Far more useful
 public class Foo {
     public void bar(final int leftOperand, final Result rightOperand) {
         rightOperand.setValue(leftOperand * rightOperand.getValue());
     }
 }
 

Since:

PMD 5.0

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

AVOID_LITERALS_IN_IF_CONDITION

public static final String AVOID_LITERALS_IN_IF_CONDITION

Avoid using hard-coded literals in conditional statements. By declaring them as static variables or private members with descriptive names maintainability is enhanced.

Example

 public class Literals {
     private static final int TEN = 10;
 
     public void downCastPrimitiveType() {
 
         if (i == 10) { // magic number, buried in a method
             doSomething();
         }
 
         if (i == TEN) { // preferred approach
             doSomething();
         }
     }
 }
 

Since:

PMD 4.2.6

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

USE_OBJECT_FOR_CLEARER_API

public static final String USE_OBJECT_FOR_CLEARER_API

When you write a public method, you should be thinking in terms of an API. If your method is public, it means other class will use it, therefore, you want (or need) to offer a comprehensive and evolutive API. If you pass a lot of information as a simple series of Strings, you may think of using an Object to represent all those information. You'll get a simplier API (such as doWork(Workload workload), rather than a tedious series of Strings) and more importantly, if you need at some point to pass extra data, you'll be able to do so by simply modifying or extending Workload without any modification to your API.

Example

 public class MyClass {
     public void connect(String username, String pssd, String databaseName, String databaseAdress)
     // Instead of those parameters object
     // would ensure a cleaner API and permit
     // to add extra data transparently (no code change):
     // void connect(UserData data);
     {
 
     }
 }
 

Since:

PMD 4.2.6

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

USE_CONCURRENT_HASH_MAP

public static final String USE_CONCURRENT_HASH_MAP

Since Java5 brought a new implementation of the Map designed for multi-threaded access, you can perform efficient map reads without blocking other threads.

Example

 public class ConcurrentApp {
     public void getMyInstance() {
         Map map1 = new HashMap(); // fine for single-threaded access
         Map map2 = new ConcurrentHashMap(); // preferred for use with multiple threads
 
         // the following case will be ignored by this rule
         Map map3 = someModule.methodThatReturnMap(); // might be OK, if the returned map is already thread-safe
     }
 }
 

Since:

PMD 4.2.6

See Also:

PMD Controversial Rule Set Documentation, Constant Field Values

COUPLING_BETWEEN_OBJECTS

public static final String COUPLING_BETWEEN_OBJECTS

This rule counts the number of unique attributes, local variables, and return types within an object. A number higher than the specified threshold can indicate a high degree of coupling.

Example

 import com.Blah;
 import org.Bar;
 import org.Bardo;
 
 public class Foo {
    private Blah var1;
    private Bar var2;
  
     //followed by many imports of unique objects
    void ObjectC doWork() {
      Bardo var55;
      ObjectA var44;
      ObjectZ var93;
      return something;
    }
 }
 

Since:

PMD 1.04

See Also:

PMD Coupling Rule Set Documentation, Constant Field Values

EXCESSIVE_IMPORTS

public static final String EXCESSIVE_IMPORTS

A high number of imports can indicate a high degree of coupling within an object. This rule counts the number of unique imports and reports a violation if the count is above the user-specified threshold.

Example

 import blah.blah.Baz;
 // 18 others from the same package elided
 import blah.blah.Bif;
 

Since:

PMD 1.04

See Also:

PMD Coupling Rule Set Documentation, Constant Field Values

LOOSE_COUPLING

public static final String LOOSE_COUPLING

The use of implementation types as object references limits your ability to use alternate implementations in the future as requirements change. Whenever available, referencing objects by their interface types provides much more flexibility.

Example

 // sub-optimal approach
 public HashSet getFoo() {
     return new HashSet();
 }
 
 // preferred approach
 public Set getFoo() {
     return new HashSet();
 }
 

Since:

PMD 0.7

See Also:

PMD Coupling Rule Set Documentation, Constant Field Values

LOOSE_PACKAGE_COUPLING

public static final String LOOSE_PACKAGE_COUPLING

Avoid using classes from the configured package hierarchy outside of the package hierarchy, except when using one of the configured allowed classes.

Example

 package some.package;
 
 import some.other.package.subpackage.subsubpackage.DontUseThisClass;
 
 public class Bar {
    DontUseThisClass boo = new DontUseThisClass();
 }
 

Since:

PMD 5.0

See Also:

PMD Coupling Rule Set Documentation, Constant Field Values

LAW_OF_DEMETER

public static final String LAW_OF_DEMETER

The Law of Demeter is a simple rule, that says "only talk to friends". It helps to reduce coupling between classes or objects. See also the references: Andrew Hunt, David Thomas, and Ward Cunningham. The Pragmatic Programmer. From Journeyman to Master. Addison-Wesley Longman, Amsterdam, October 1999.; K.J. Lieberherr and I.M. Holland. Assuring good style for object-oriented programs. Software, IEEE, 6(5):38–48, 1989.; http://www.ccs.neu.edu/home/lieber/LoD.html; http://en.wikipedia.org/wiki/Law_of_Demeter

Example

 public class Foo {
     public void example(final Bar b) {
         // this method call is ok, as b is a parameter of "example"
         final C c = b.getC();
 
         // this method call is a violation, as we are using c, which we got from B.
         // We should ask b directly instead, e.g. "b.doItOnC();"
         c.doIt();
 
         // this is also a violation, just expressed differently as a method chain without temporary variables.
         b.getC().doIt();
 
         // a constructor call, not a method call.
         final D d = new D();
         // this method call is ok, because we have create the new instance of D locally.
         d.doSomethingElse();
     }
 }
 

Since:

PMD 5.0

See Also:

PMD Coupling Rule Set Documentation, Constant Field Values

USE_SINGLETON

public static final String USE_SINGLETON

For classes that only have static methods, consider making them Singletons. Note that this doesn't apply to abstract classes, since their subclasses may well include non-static methods. Also, if you want this class to be a Singleton, remember to add a private constructor to prevent instantiation.

Example

 public class MaybeASingleton {
     public static void foo() {
     }
 
     public static void bar() {
     }
 }
 

Since:

PMD 0.3

See Also:

PMD Design Rule Set Documentation, Constant Field Values

SIMPLIFY_BOOLEAN_RETURNS

public static final String SIMPLIFY_BOOLEAN_RETURNS

Avoid unnecessary if-then-else statements when returning a boolean. The result of the conditional test can be returned instead.

Example

 public boolean isBarEqualTo(int x) {
 
     if (bar == x) { // this bit of code...
         return true;
     } else {
         return false;
     }
 }
 
 public boolean isBarEqualTo(int x) {
 
     return bar == x; // can be replaced with this
 }
 

Since:

PMD 0.9

See Also:

PMD Design Rule Set Documentation, Constant Field Values

SIMPLIFY_BOOLEAN_EXPRESSIONS

public static final String SIMPLIFY_BOOLEAN_EXPRESSIONS

Avoid unnecessary comparisons in boolean expressions, they serve no purpose and impacts readability.

Example

 public class Bar {
     // can be simplified to
     // bar = isFoo();
     private boolean bar = (isFoo() == true);
 
     public isFoo() {
         return false;
     }
 }
 

Since:

PMD 1.05

See Also:

PMD Design Rule Set Documentation, Constant Field Values

SWITCH_STATEMENTS_SHOULD_HAVE_DEFAULT

public static final String SWITCH_STATEMENTS_SHOULD_HAVE_DEFAULT

All switch statements should include a default option to catch any unspecified values.

Example

 public void bar() {
     int x = 2;
     switch (x) {
         case 1:
             int j = 6;
         case 2:
             int j = 8;
             // missing default: here
     }
 }
 

Since:

PMD 1.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

AVOID_DEEPLY_NESTED_IF_STATEMENTS

public static final String AVOID_DEEPLY_NESTED_IF_STATEMENTS

Avoid creating deeply nested if-then statements since they are harder to read and error-prone to maintain.

Example

 public class Foo {
     public void bar(int x, int y, int z) {
         if (x > y) {
             if (y > z) {
                 if (z == x) {
                     // !! too deep
                 }
             }
         }
     }
 }
 

Since:

PMD 1.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

AVOID_REASSIGNING_PARAMETERS

public static final String AVOID_REASSIGNING_PARAMETERS

Reassigning values to incoming parameters is not recommended. Use temporary local variables instead.

Example

 public class Foo {
     private void foo(String bar) {
         bar = "something else";
     }
 }
 

Since:

PMD 1.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

SWITCH_DENSITY

public static final String SWITCH_DENSITY

A high ratio of statements to labels in a switch statement implies that the switch statement is overloaded. Consider moving the statements into new methods or creating subclasses based on the switch variable.

Example

 public class Foo {
     public void bar(int x) {
         switch (x) {
             case 1: {
                 // lots of statements
                 break;
             }
             case 2: {
                 // lots of statements
                 break;
             }
         }
     }
 }
 

Since:

PMD 1.02

See Also:

PMD Design Rule Set Documentation, Constant Field Values

CONSTRUCTOR_CALLS_OVERRIDABLE_METHOD

public static final String CONSTRUCTOR_CALLS_OVERRIDABLE_METHOD

Calling overridable methods during construction poses a risk of invoking methods on an incompletely constructed object and can be difficult to debug. It may leave the sub-class unable to construct its superclass or forced to replicate the construction process completely within itself, losing the ability to call super(). If the default constructor contains a call to an overridable method, the subclass may be completely uninstantiable. Note that this includes method calls throughout the control flow graph - i.e., if a constructor Foo() calls a private method bar() that calls a public method buz(), this denotes a problem.

Example

 public class SeniorClass {
     public SeniorClass() {
         toString(); // may throw NullPointerException if overridden
     }
 
     public String toString() {
         return "IAmSeniorClass";
     }
 }
 
 public class JuniorClass extends SeniorClass {
     private String name;
 
     public JuniorClass() {
         super(); // Automatic call leads to NullPointerException
         name = "JuniorClass";
     }
 
     public String toString() {
         return name.toUpperCase();
     }
 }
 

Since:

PMD 1.04

See Also:

PMD Design Rule Set Documentation, Constant Field Values

ACCESSOR_CLASS_GENERATION

public static final String ACCESSOR_CLASS_GENERATION

Instantiation by way of private constructors from outside of the constructor's class often causes the generation of an accessor. A factory method, or non-privatization of the constructor can eliminate this situation. The generated class file is actually an interface. It gives the accessing class the ability to invoke a new hidden package scope constructor that takes the interface as a supplementary parameter. This turns a private constructor effectively into one with package scope, and is challenging to discern.

Example

 public class Outer {
     void method() {
         Inner ic = new Inner();// Causes generation of accessor class
     }
 
     public class Inner {
         private Inner() {
         }
     }
 }
 

Since:

PMD 1.04

See Also:

PMD Design Rule Set Documentation, Constant Field Values

FINAL_FIELD_COULD_BE_STATIC

public static final String FINAL_FIELD_COULD_BE_STATIC

If a final field is assigned to a compile-time constant, it could be made static, thus saving overhead in each object at runtime.

Example

 public class Foo {
     public final int BAR = 42; // this could be static and save some space
 }
 

Since:

PMD 1.1

See Also:

PMD Design Rule Set Documentation, Constant Field Values

CLOSE_RESOURCE

public static final String CLOSE_RESOURCE

Ensure that resources (like Connection, Statement, and ResultSet objects) are always closed after use.

Example

 public class Bar {
     public void foo() {
         Connection c = pool.getConnection();
         try {
             // do stuff
         } catch (SQLException ex) {
             // handle exception
         } finally {
             // oops, should close the connection using 'close'!
             // c.close();
         }
     }
 }
 

Since:

PMD 1.2.2

See Also:

PMD Design Rule Set Documentation, Constant Field Values

NON_STATIC_INITIALIZER

public static final String NON_STATIC_INITIALIZER

A non-static initializer block will be called any time a constructor is invoked (just prior to invoking the constructor). While this is a valid language construct, it is rarely used and is confusing.

Example

 public class MyClass {
     // this block gets run before any call to a constructor
     {
         System.out.println("I am about to construct myself");
     }
 }
 

Since:

PMD 1.5

See Also:

PMD Design Rule Set Documentation, Constant Field Values

DEFAULT_LABEL_NOT_LAST_IN_SWITCH_STATEMENT

public static final String DEFAULT_LABEL_NOT_LAST_IN_SWITCH_STATEMENT

By convention, the default label should be the last label in a switch statement.

Example

 public class Foo {
     void bar(int a) {
         switch (a) {
             case 1: // do something
                 break;
             default: // the default case should be last, by convention
                 break;
             case 2:
                 break;
         }
     }
 }
 

Since:

PMD 1.5

See Also:

PMD Design Rule Set Documentation, Constant Field Values

NON_CASE_LABEL_IN_SWITCH_STATEMENT

public static final String NON_CASE_LABEL_IN_SWITCH_STATEMENT

A non-case label (e.g. a named break/continue label) was present in a switch statement. This legal, but confusing. It is easy to mix up the case labels and the non-case labels.

Example

 public class Foo {
     void bar(int a) {
         switch (a) {
             case 1:
                 // do something
                 break;
                 mylabel:
                 // this is legal, but confusing!
                 break;
             default:
                 break;
         }
     }
 }
 

Since:

PMD 1.5

See Also:

PMD Design Rule Set Documentation, Constant Field Values

OPTIMIZABLE_TO_ARRAY_CALL

public static final String OPTIMIZABLE_TO_ARRAY_CALL

Calls to a collection's toArray() method should specify target arrays sized to match the size of the collection. Initial arrays that are too small are discarded in favour of new ones that have to be created that are the proper size.

Example

 public void arrayCall() {
     List foos = getFoos();
 
     // inefficient, the array will be discarded
     Foo[] fooArray = foos.toArray(new Foo[0]);
 
     // much better; this one sizes the destination array,
     // avoiding of a new one via reflection
     Foo[] fooArray = foos.toArray(new Foo[foos.size()]);
 }
 

Since:

PMD 1.8

See Also:

PMD Design Rule Set Documentation, Constant Field Values

BAD_COMPARISON

public static final String BAD_COMPARISON

Avoid equality comparisons with Double.NaN. Due to the implicit lack of representation precision when comparing floating point numbers these are likely to cause logic errors.

Example

 boolean x = (y == Double.NaN);
 

Since:

PMD 1.8

See Also:

PMD Design Rule Set Documentation, Constant Field Values

EQUALS_NULL

public static final String EQUALS_NULL

Tests for null should not use the equals() method. The '==' operator should be used instead.

Example

 String x = "foo";
 
 if (x.equals(null)) { // bad form
     doSomething();
 }
 
 if (x == null) { // preferred
     doSomething();
 }
 

Since:

PMD 1.9

See Also:

PMD Design Rule Set Documentation, Constant Field Values

CONFUSING_TERNARY

public static final String CONFUSING_TERNARY

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?".

Example

 boolean bar(int x, int y) {
     return (x != y) ? diff : same;
 }
 

Since:

PMD 1.9

See Also:

PMD Design Rule Set Documentation, Constant Field Values

INSTANTIATION_TO_GET_CLASS

public static final String INSTANTIATION_TO_GET_CLASS

Avoid instantiating an object just to call getClass() on it; use the .class public member instead.

Example

 public void instantiation() {
     // replace this
     Class c = new String().getClass();
 
     // with this:
     Class c = String.class;
 }
 

Since:

PMD 2.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

IDEMPOTENT_OPERATIONS

public static final String IDEMPOTENT_OPERATIONS

Avoid idempotent operations - they have no effect.

Example

 public class Foo {
     public void bar() {
         int x = 2;
         x = x;
     }
 }
 

Since:

PMD 2.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

SIMPLE_DATE_FORMAT_NEEDS_LOCALE

public static final String SIMPLE_DATE_FORMAT_NEEDS_LOCALE

Be sure to specify a Locale when creating SimpleDateFormat instances to ensure that locale-appropriate formatting is used.

Example

 public class Foo {
     // Should specify Locale.US (or whatever)
     private SimpleDateFormat sdf = new SimpleDateFormat("pattern");
 }
 

Since:

PMD 2.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

IMMUTABLE_FIELD

public static final String IMMUTABLE_FIELD

Identifies private fields whose values never change once they are initialized either in the declaration of the field or by a constructor. This helps in converting existing classes to becoming immutable ones.

Example

 public class Foo {
     private int x; // could be final
 
     public Foo() {
         x = 7;
     }
 
     public void foo() {
         int a = x + 2;
     }
 }
 

Since:

PMD 2.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

USE_LOCALE_WITH_CASE_CONVERSIONS

public static final String USE_LOCALE_WITH_CASE_CONVERSIONS

When doing String.toLowerCase()/toUpperCase() conversions, use Locales to avoids problems with languages that have unusual conventions, i.e. Turkish.

Example

 class Foo {
  // BAD
  if (x.toLowerCase().equals("list"))...
  // GOOD
  String z = a.toLowerCase(Locale.EN);
 }
 

Since:

PMD 2.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

AVOID_PROTECTED_FIELD_IN_FINAL_CLASS

public static final String AVOID_PROTECTED_FIELD_IN_FINAL_CLASS

Do not use protected fields in final classes since they cannot be subclassed. Clarify your intent by using private or package access modifiers instead.

Example

 public final class Bar {
     private int   x;
     protected int y; // bar cannot be subclassed, so is y really private or package visible?
 
     Bar() {
     }
 }
 

Since:

PMD 2.1

See Also:

PMD Design Rule Set Documentation, Constant Field Values

ASSIGNMENT_TO_NON_FINAL_STATIC

public static final String ASSIGNMENT_TO_NON_FINAL_STATIC

Identifies a possible unsafe usage of a static field.

Example

 public class StaticField {
     static int x;
 
     public FinalFields(int y) {
         x = y; // unsafe
     }
 }
 

Since:

PMD 2.2

See Also:

PMD Design Rule Set Documentation, Constant Field Values

MISSING_STATIC_METHOD_IN_NON_INSTANTIATABLE_CLASS

public static final String MISSING_STATIC_METHOD_IN_NON_INSTANTIATABLE_CLASS

A class that has private constructors and does not have any static methods or fields cannot be used.

Example

 // This class is unusable, since it cannot be
 // instantiated (private constructor),
 // and no static method can be called.
 
 public class Foo {
     private Foo() {
     }
 
     void foo() {
     }
 }
 

Since:

PMD 3.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

AVOID_SYNCHRONIZED_AT_METHOD_LEVEL

public static final String AVOID_SYNCHRONIZED_AT_METHOD_LEVEL

Method-level synchronization can cause problems when new code is added to the method. Block-level synchronization helps to ensure that only the code that needs synchronization gets it.

Example

 public class Foo {
     // Try to avoid this:
     synchronized void foo() {
     }
 
     // Prefer this:
     void bar() {
         synchronized (this) {
         }
     }
 
     // Try to avoid this for static methods:
     static synchronized void fooStatic() {
     }
 
     // Prefer this:
     static void barStatic() {
         synchronized (Foo.class) {
         }
     }
 }
 

Since:

PMD 3.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

MISSING_BREAK_IN_SWITCH

public static final String MISSING_BREAK_IN_SWITCH

Switch statements without break or return statements for each case option may indicate problematic behaviour. Empty cases are ignored as these indicate an intentional fall-through.

Example

 public void bar(int status) {
     switch (status) {
         case CANCELLED:
             doCancelled();
             // break; hm, should this be commented out?
         case NEW:
             doNew();
             // is this really a fall-through?
         case REMOVED:
             doRemoved();
             // what happens if you add another case after this one?
         case OTHER: // empty case - this is interpreted as an intentional fall-through
         case ERROR:
             doErrorHandling();
             break;
     }
 }
 

Since:

PMD 3.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

USE_NOTIFY_ALL_INSTEAD_OF_NOTIFY

public static final String USE_NOTIFY_ALL_INSTEAD_OF_NOTIFY

Thread.notify() awakens a thread monitoring the object. If more than one thread is monitoring, then only one is chosen. The thread chosen is arbitrary; thus its usually safer to call notifyAll() instead.

Example

 void bar() {
     x.notify();
     // If many threads are monitoring x, only one (and you won't know which) will be notified.
     // use instead:
     x.notifyAll();
 }
 

Since:

PMD 3.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

AVOID_INSTANCEOF_CHECKS_IN_CATCH_CLAUSE

public static final String AVOID_INSTANCEOF_CHECKS_IN_CATCH_CLAUSE

Each caught exception type should be handled in its own catch clause.

Example

 try { // Avoid this
       // do something
 } catch (Exception ee) {
     if (ee instanceof IOException) {
         cleanup();
     }
 }
 try { // Prefer this:
       // do something
 } catch (IOException ee) {
     cleanup();
 }
 

Since:

PMD 3.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

ABSTRACT_CLASS_WITH_ABSTRACT_METHOD

public static final String ABSTRACT_CLASS_WITH_ABSTRACT_METHOD

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 directly) a protected constructor can be provided prevent direct instantiation.

Example

 public abstract class Foo {
   void int method1() { ... }
   void int method2() { ... }
   // consider using abstract methods or removing
   // the abstract modifier and adding protected constructors
 }
 

Since:

PMD 3.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

SIMPLIFY_CONDITIONAL

public static final String SIMPLIFY_CONDITIONAL

No need to check for null before an instanceof; the instanceof keyword returns false when given a null argument.

Example

 class Foo {
     void bar(Object x) {
         if (x != null && x instanceof Bar) {
             // just drop the "x != null" check
         }
     }
 }
 

Since:

PMD 3.1

See Also:

PMD Design Rule Set Documentation, Constant Field Values

COMPARE_OBJECTS_WITH_EQUALS

public static final String COMPARE_OBJECTS_WITH_EQUALS

Use equals() to compare object references; avoid comparing them with ==.

Example

 class Foo {
     boolean bar(String a, String b) {
         return a == b;
     }
 }
 

Since:

PMD 3.2

See Also:

PMD Design Rule Set Documentation, Constant Field Values

POSITION_LITERALS_FIRST_IN_COMPARISONS

public static final String POSITION_LITERALS_FIRST_IN_COMPARISONS

Position literals first in comparisons, if the second argument is null then NullPointerExceptions can be avoided, they will just return false.

Example

 class Foo {
     boolean bar(String x) {
         return x.equals("2"); // should be "2".equals(x)
     }
 }
 

Since:

PMD 3.3

See Also:

PMD Design Rule Set Documentation, Constant Field Values

UNNECESSARY_LOCAL_BEFORE_RETURN

public static final String UNNECESSARY_LOCAL_BEFORE_RETURN

Avoid the creation of unnecessary local variables.

Example

 public class Foo {
     public int foo() {
         int x = doSomething();
         return x; // instead, just 'return doSomething();'
     }
 }
 

Since:

PMD 3.3

See Also:

PMD Design Rule Set Documentation, Constant Field Values

NON_THREAD_SAFE_SINGLETON

public static final String NON_THREAD_SAFE_SINGLETON

Non-thread safe singletons can result in bad state changes. Eliminate static singletons if possible by instantiating the object directly. Static singletons are usually not needed as only a single instance exists anyway. Other possible fixes are to synchronize the entire method or to use an initialize-on-demand holder class (do not use the double-check idiom). See Effective Java, item 48.

Example

 class Bar {
     private static Foo foo = null;
 
     // multiple simultaneous callers may see partially initialized objects
     public static Foo getFoo() {
         if (foo == null)
             foo = new Foo();
         return foo;
     }
 }
 

Since:

PMD 3.4

See Also:

PMD Design Rule Set Documentation, Constant Field Values

UNCOMMENTED_EMPTY_METHOD

public static final String UNCOMMENTED_EMPTY_METHOD

Uncommented Empty Method finds instances where a method does not contain statements, but there is no comment. By explicitly commenting empty methods it is easier to distinguish between intentional (commented) and unintentional empty methods.

Example

 public void doSomething() {
 }
 

Since:

PMD 3.4

See Also:

PMD Design Rule Set Documentation, Constant Field Values

UNCOMMENTED_EMPTY_CONSTRUCTOR

public static final String UNCOMMENTED_EMPTY_CONSTRUCTOR

Uncommented Empty Constructor finds instances where a constructor does not contain statements, but there is no comment. By explicitly commenting empty constructors it is easier to distinguish between intentional (commented) and unintentional empty constructors.

Example

 public Foo() {
     super();
 }
 

Since:

PMD 3.4

See Also:

PMD Design Rule Set Documentation, Constant Field Values

AVOID_CONSTANTS_INTERFACE

public static final String AVOID_CONSTANTS_INTERFACE

An interface should be used only to characterize the external behaviour of an implementing class: using an interface as a container of constants is a poor usage pattern and not recommended.

Example

 public interface ConstantsInterface {
     public static final int    CONSTANT1 = 0;
     public static final String CONSTANT2 = "1";
 }
 

Since:

PMD 3.5

See Also:

PMD Design Rule Set Documentation, Constant Field Values

UNSYCHRONIZED_STATIC_DATE_FORMATTER

public static final String UNSYCHRONIZED_STATIC_DATE_FORMATTER

SimpleDateFormat instances are not synchronized. Sun recommends using separate format instances for each thread. If multiple threads must access a static formatter, the formatter must be synchronized either on method or block level.

Example

 public class Foo {
     private static final SimpleDateFormat sdf = new SimpleDateFormat();
 
     void bar() {
         sdf.format(); // poor, no thread-safety
     }
 
     synchronized void foo() {
         sdf.format(); // preferred
     }
 }
 

Since:

PMD 3.6

See Also:

PMD Design Rule Set Documentation, Constant Field Values

PRESERVE_STACK_TRACE

public static final String PRESERVE_STACK_TRACE

Throwing a new exception from a catch block without passing the original exception into the new exception will cause the original stack trace to be lost making it difficult to debug effectively.

Example

 public class Foo {
     void good() {
         try {
             Integer.parseInt("a");
         } catch (Exception e) {
             throw new Exception(e); // first possibility to create exception chain
         }
         try {
             Integer.parseInt("a");
         } catch (Exception e) {
             throw (IllegalStateException) new IllegalStateException().initCause(e); // second possibility to create
                                                                                     // exception chain.
         }
     }
 
     void bad() {
         try {
             Integer.parseInt("a");
         } catch (Exception e) {
             throw new Exception(e.getMessage());
         }
     }
 }
 

Since:

PMD 3.7

See Also:

PMD Design Rule Set Documentation, Constant Field Values

USE_COLLECTION_IS_EMPTY

public static final String USE_COLLECTION_IS_EMPTY

The isEmpty() method on java.util.Collection is provided to determine if a collection has any elements. Comparing the value of size() to 0 does not convey intent as well as the isEmpty() method.

Example

 public class Foo {
     void good() {
         List foo = getList();
         if (foo.isEmpty()) {
             // blah
         }
     }
 
     void bad() {
         List foo = getList();
         if (foo.size() == 0) {
             // blah
         }
     }
 }
 

Since:

PMD 3.9

See Also:

PMD Design Rule Set Documentation, Constant Field Values

CLASS_WITH_ONLY_PRIVATE_CONSTRUCTOR_SHOULD_BE_FINAL

public static final String CLASS_WITH_ONLY_PRIVATE_CONSTRUCTOR_SHOULD_BE_FINAL

A class with only private constructors should be final, unless the private constructor is invoked by a inner class.

Example

 public class Foo { // Should be final
     private Foo() {
     }
 }
 

Since:

PMD 4.1

See Also:

PMD Design Rule Set Documentation, Constant Field Values

EMPTY_METHOD_IN_ABSTRACT_CLASS_SHOULD_BE_ABSTRACT

public static final String EMPTY_METHOD_IN_ABSTRACT_CLASS_SHOULD_BE_ABSTRACT

Empty 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.

Example

 public abstract class ShouldBeAbstract {
     public Object couldBeAbstract() {
         // Should be abstract method ?
         return null;
     }
 
     public void couldBeAbstract() {
     }
 }
 

Since:

PMD 4.1

See Also:

PMD Design Rule Set Documentation, Constant Field Values

SINGULAR_FIELD

public static final String SINGULAR_FIELD

Fields whose scopes are limited to just single methods do not rely on the containing object to provide them to other methods. They may be better implemented as local variables within those methods.

Example

 public class Foo {
     private int x; // no reason to exist at the Foo instance level
 
     public void foo(int y) {
         x = y + 5;
         return x;
     }
 }
 

Since:

PMD 3.1

See Also:

PMD Design Rule Set Documentation, Constant Field Values

RETURN_EMPTY_ARRAY_RATHER_THAN_NULL

public static final String RETURN_EMPTY_ARRAY_RATHER_THAN_NULL

For any method that returns an array, it is a better to return an empty array rather than a null reference. This removes the need for null checking all results and avoids inadvertent NullPointerExceptions.

Example

 public class Example {
     // Not a good idea...
     public int[] badBehavior() {
         // ...
         return null;
     }
 
     // Good behavior
     public String[] bonnePratique() {
         // ...
         return new String[0];
     }
 }
 

Since:

PMD 4.2

See Also:

PMD Design Rule Set Documentation, Constant Field Values

ABSTRACT_CLASS_WITHOUT_ANY_METHOD

public static final String ABSTRACT_CLASS_WITHOUT_ANY_METHOD

If an abstract class does not provides any methods, it may be acting as a simple data container that is not meant to be instantiated. In this case, it is probably better to use a private or protected constructor in order to prevent instantiation than make the class misleadingly abstract.

Example

 public class abstract Example {
     String field;
     int otherField;
 }
 

Since:

PMD 4.2

See Also:

PMD Design Rule Set Documentation, Constant Field Values

TOO_FEW_BRANCHES_FOR_A_SWITCH_STATEMENT

public static final String TOO_FEW_BRANCHES_FOR_A_SWITCH_STATEMENT

Switch statements are indended to be used to support complex branching behaviour. Using a switch for only a few cases is ill-advised, since switches are not as easy to understand as if-then statements. In these cases use the if-then statement to increase code readability.

Since:

PMD 4.2

See Also:

PMD Design Rule Set Documentation, Constant Field Values

LOGIC_INVERSION

public static final String LOGIC_INVERSION

Use opposite operator instead of negating the whole expression with a logic complement operator.

Example

 public boolean bar(int a, int b) {
 
     if (!(a == b)) // use !=
         return false;
 
     if (!(a < b)) // use >=
         return false;
 
     return true;
 }
 

Since:

PMD 5.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

USE_VARARGS

public static final String USE_VARARGS

Java 5 introduced the varargs parameter declaration for methods and constructors. This syntactic sugar provides flexibility for users of these methods and constructors, allowing them to avoid having to deal with the creation of an array.

Example

 public class Foo {
     public void foo(String s, Object[] args) {
         // Do something here...
     }
 
     public void bar(String s, Object... args) {
         // Ahh, varargs tastes much better...
     }
 }
 

Since:

PMD 5.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

FIELD_DECLARATIONS_SHOULD_BE_AT_START_OF_CLASS

public static final String FIELD_DECLARATIONS_SHOULD_BE_AT_START_OF_CLASS

Fields should be declared at the top of the class, before any method declarations, constructors, initializers or inner classes.

Example

 public class HelloWorldBean {
 
     // Field declared before methods / inner classes - OK
     private String _thing;
 
     public String getMessage() {
         return "Hello World!";
     }
 
     // Field declared after methods / inner classes - avoid this
     private String _fieldInWrongLocation;
 }
 

Since:

PMD 5.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

GOD_CLASS

public static final String GOD_CLASS

The God Class rule detects the God Class design flaw using metrics. God classes do too many things, are very big and overly complex. They should be split apart to be more object-oriented. The rule uses the detection strategy described in "Object-Oriented Metrics in Practice". The violations are reported against the entire class. See also the references: Michele Lanza and Radu Marinescu. Object-Oriented Metrics in Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems. Springer, Berlin, 1 edition, October 2006. Page 80.

Since:

PMD 5.0

See Also:

PMD Design Rule Set Documentation, Constant Field Values

EMPTY_CATCH_BLOCK

public static final String EMPTY_CATCH_BLOCK

Empty Catch Block finds instances where an exception is caught, but nothing is done. In most circumstances, this swallows an exception which should either be acted on or reported.

Example

 public void doSomething() {
     try {
         FileInputStream fis = new FileInputStream("/tmp/bugger");
     } catch (IOException ioe) {
         // not good
     }
 }
 

Since:

PMD 0.1

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_IF_STATEMENT

public static final String EMPTY_IF_STATEMENT

Empty If Statement finds instances where a condition is checked but nothing is done about it.

Example

 public class Foo {
     void bar(int x) {
         if (x == 0) {
             // empty!
         }
     }
 }
 

Since:

PMD 0.1

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_WHILE_STATEMENT

public static final String EMPTY_WHILE_STATEMENT

Empty While Statement finds all instances where a while statement does nothing. If it is a timing loop, then you should use Thread.sleep() for it; if it is a while loop that does a lot in the exit expression, rewrite it to make it clearer.

Example

 void bar(int a, int b) {
     while (a == b) {
         // empty!
     }
 }
 

Since:

PMD 0.2

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_TRY_BLOCK

public static final String EMPTY_TRY_BLOCK

Avoid empty try blocks - what's the point?

Example

 public class Foo {
     public void bar() {
         try {
         } catch (Exception e) {
             e.printStackTrace();
         }
     }
 }
 

Since:

PMD 0.4

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_FINALLY_BLOCK

public static final String EMPTY_FINALLY_BLOCK

Empty finally blocks serve no purpose and should be removed.

Example

 public class Foo {
     public void bar() {
         try {
             int x = 2;
         } finally {
             // empty!
         }
     }
 }
 

Since:

PMD 0.4

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_SWITCH_STATEMENTS

public static final String EMPTY_SWITCH_STATEMENTS

Empty switch statements serve no purpose and should be removed.

Example

 public void bar() {
     int x = 2;
     switch (x) {
     // once there was code here
     // but it's been commented out or something
     }
 }
 

Since:

PMD 1.0

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_SYNCHRONIZED_BLOCK

public static final String EMPTY_SYNCHRONIZED_BLOCK

Empty synchronized blocks serve no purpose and should be removed.

Example

 public class Foo {
     public void bar() {
         synchronized (this) {
             // empty!
         }
     }
 }
 

Since:

PMD 1.3

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_STATEMENT_NOT_IN_LOOP

public static final String EMPTY_STATEMENT_NOT_IN_LOOP

An empty statement (or a semicolon by itself) that is not used as the sole body of a 'for' or 'while' loop is probably a bug. It could also be a double semicolon, which has no purpose and should be removed.

Example

 public void doit() {
     // this is probably not what you meant to do
     ;
     // the extra semicolon here this is not necessary
     System.out.println("look at the extra semicolon");
     ;
 }
 

Since:

PMD 1.5

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_INITIALIZER

public static final String EMPTY_INITIALIZER

Empty initializers serve no purpose and should be removed.

Example

 public class Foo {
 
     static {
     } // Why ?
 
     {
     } // Again, why ?
 
 }
 

Since:

PMD 5.0

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_STATEMENT_BLOCK

public static final String EMPTY_STATEMENT_BLOCK

Empty block statements serve no purpose and should be removed.

Example

 public class Foo {
 
     private int _bar;
 
     public void setBar(int bar) {
         {
             _bar = bar;
         } // Why not?
         {
         } // But remove this.
     }
 
 }
 

Since:

PMD 5.0

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_STATIC_INITIALIZER

public static final String EMPTY_STATIC_INITIALIZER

An empty static initializer serve no purpose and should be removed.

Example

 public class Foo {
     static {
         // empty
     }
 }
 

Since:

PMD 1.5

See Also:

PMD Empty Code Rule Set Documentation, Constant Field Values

EMPTY_FINANLIZER

public static final String EMPTY_FINANLIZER

Empty finalize methods serve no purpose and should be removed.

Example

 public class Foo {
     protected void finalize() {
     }
 }
 

Since:

PMD 1.5

See Also:

PMD Finalizers Rule Set Documentation, Constant Field Values

FINALIZE_ONLY_CALLS_SUPER_FINALIZE

public static final String FINALIZE_ONLY_CALLS_SUPER_FINALIZE

If the finalize() is implemented, it should do something besides just calling super.finalize().

Example

 protected void finalize() {
     super.finalize();
 }
 

Since:

PMD 1.5

See Also:

PMD Finalizers Rule Set Documentation, Constant Field Values

FINALIZE_OVERLOADED

public static final String FINALIZE_OVERLOADED

Methods named finalize() should not have parameters. It is confusing and most likely an attempt to overload Object.finalize(). It will not be called by the VM.

Example

 public class Foo {
     // this is confusing and probably a bug
     protected void finalize(int a) {
     }
 }
 

Since:

PMD 1.5

See Also:

PMD Finalizers Rule Set Documentation, Constant Field Values

FINALIZE_DOES_NOT_CALL_SUPER_FINALIZE

public static final String FINALIZE_DOES_NOT_CALL_SUPER_FINALIZE

If the finalize() is implemented, its last action should be to call super.finalize.

Example

 protected void finalize() {
     something();
     // neglected to call super.finalize()
 }
 

Since:

PMD 1.5

See Also:

PMD Finalizers Rule Set Documentation, Constant Field Values

FINALIZE_SHOULD_BE_PROTECTED

public static final String FINALIZE_SHOULD_BE_PROTECTED

When overriding the finalize(), the new method should be set as protected. If made public, other classes may invoke it at inappropriate times.

Example

 public void finalize() {
     // do something
 }
 

Since:

PMD 1.1

See Also:

PMD Finalizers Rule Set Documentation, Constant Field Values

AVOID_CALLING_FINALIZE

public static final String AVOID_CALLING_FINALIZE

The method Object.finalize() is called by the garbage collector on an object when garbage collection determines that there are no more references to the object. It should not be invoked by application logic.

Example

 void foo() {
     Bar b = new Bar();
     b.finalize();
 }
 

Since:

PMD 3.0

See Also:

PMD Finalizers Rule Set Documentation, Constant Field Values

DUPLICATE_IMPORTS

public static final String DUPLICATE_IMPORTS

Duplicate or overlapping import statements should be avoided.

Example

 import java.lang.String;
 import java.lang.*;
 

Since:

PMD 0.5

See Also:

PMD Import Statements Rule Set Documentation, Constant Field Values

DONT_IMPORT_JAVA_LANG

public static final String DONT_IMPORT_JAVA_LANG

Avoid importing anything from the package 'java.lang'. These classes are automatically imported (JLS 7.5.3).

Example

 import java.lang.String; // this is unnecessary
 import java.lang.*; // this is bad
 

Since:

PMD 0.5

See Also:

PMD Import Statements Rule Set Documentation, Constant Field Values

UNUSED_IMPORTS

public static final String UNUSED_IMPORTS

Avoid the use of unused import statements to prevent unwanted dependencies.

Example

 // this is bad, if the class doesn't use java.io.File
 import java.io.File;
 

Since:

PMD 1.0

See Also:

PMD Import Statements Rule Set Documentation, Constant Field Values

IMPORT_FROM_SAME_PACKAGE

public static final String IMPORT_FROM_SAME_PACKAGE

There is no need to import a type that lives in the same package.

Example

 package foo;
 
 import foo.Buz; // no need for this
 import foo.*; // or this
 

Since:

PMD 1.02

See Also:

PMD Import Statements Rule Set Documentation, Constant Field Values

TOO_MANY_STATIC_IMPORTS

public static final String TOO_MANY_STATIC_IMPORTS

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).

Example

 import static Lennon;
 import static Ringo;
 import static George;
 import static Paul;
 import static Yoko; // Too much !
 

Since:

PMD 4.1

See Also:

PMD Import Statements Rule Set Documentation, Constant Field Values

UNNECESSARY_FULLY_QUALIFIED_NAME

public static final String UNNECESSARY_FULLY_QUALIFIED_NAME

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.

Example

 public class Foo {
     private java.util.List list1; // Unnecessary FQN
     private List           list2; // More appropriate given import of 'java.util.List'
 }
 

Since:

PMD 5.0

See Also:

PMD Import Statements Rule Set Documentation, Constant Field Values

USE_PROPER_CLASS_LOADER

public static final String USE_PROPER_CLASS_LOADER

In J2EE, the getClassLoader() method might not work as expected. Use Thread.currentThread().getContextClassLoader() instead.

Example

 public class Foo {
     ClassLoader cl = Bar.class.getClassLoader();
 }
 

Since:

PMD 3.7

See Also:

PMD J2EE Rule Set Documentation, Constant Field Values

MDB_AND_SESSION_BEAN_NAMING_CONVENTION

public static final String MDB_AND_SESSION_BEAN_NAMING_CONVENTION

The EJB Specification states that any MessageDrivenBean or SessionBean should be suffixed by 'Bean'.

Example

 public class SomeBean implements SessionBean {
 } // proper name
 
 public class MissingTheProperSuffix implements SessionBean {
 } // non-standard name
 

Since:

PMD 4.0

See Also:

PMD J2EE Rule Set Documentation, Constant Field Values

REMOTE_SESSION_INTERFACE_NAMING_CONVENTION

public static final String REMOTE_SESSION_INTERFACE_NAMING_CONVENTION

A Remote Home interface type of a Session EJB should be suffixed by 'Home'.

Example

 public interface MyBeautifulHome extends javax.ejb.EJBHome {
 } // proper name
 
 public interface MissingProperSuffix extends javax.ejb.EJBHome {
 } // non-standard name
 

Since:

PMD 4.0

See Also:

PMD J2EE Rule Set Documentation, Constant Field Values

LOCAL_INTERFACE_SESSION_NAMING_CONVENTION

public static final String LOCAL_INTERFACE_SESSION_NAMING_CONVENTION

The Local Interface of a Session EJB should be suffixed by 'Local'.

Example

 public interface MyLocal extends javax.ejb.EJBLocalObject {
 } // proper name
 
 public interface MissingProperSuffix extends javax.ejb.EJBLocalObject {
 } // non-standard name
 

Since:

PMD 4.0

See Also:

PMD J2EE Rule Set Documentation, Constant Field Values

LOCAL_HOME_NAMING_CONVENTION

public static final String LOCAL_HOME_NAMING_CONVENTION

The Local Home interface of a Session EJB should be suffixed by 'LocalHome'.

Example

 public interface MyBeautifulLocalHome extends javax.ejb.EJBLocalHome {
 }// proper name
 
 public interface MissingProperSuffix extends javax.ejb.EJBLocalHome {
 } // non-standard name
 

Since:

PMD 4.0

See Also:

PMD J2EE Rule Set Documentation, Constant Field Values

REMOTE_INTERFACE_NAMING_CONVENTION

public static final String REMOTE_INTERFACE_NAMING_CONVENTION

Remote Interface of a Session EJB should not have a suffix.

Example

 // Poor Session suffix
 public interface BadSuffixSession extends javax.ejb.EJBObject {
 }
 
 // Poor EJB suffix
 public interface BadSuffixEJB extends javax.ejb.EJBObject {
 }
 
 // Poor Bean suffix
 public interface BadSuffixBean extends javax.ejb.EJBObject {
 }
 

Since:

PMD 4.0

See Also:

PMD J2EE Rule Set Documentation, Constant Field Values

DO_NOT_CALL_SYSTEM_EXIT

public static final String DO_NOT_CALL_SYSTEM_EXIT

Web applications should not call System.exit(), since only the web container or the application server should stop the JVM. This rule also checks for the equivalent call Runtime.getRuntime().exit().

Example

 public void bar() {
     System.exit(0); // never call this when running in an application server!
 }
 
 public void foo() {
     Runtime.getRuntime().exit(0); // never stop the JVM manually, the container will do this.
 }
 

Since:

PMD 4.1

See Also:

PMD J2EE Rule Set Documentation, Constant Field Values

STATIC_EJB_FIELD_SHOULD_BE_FINAL

public static final String STATIC_EJB_FIELD_SHOULD_BE_FINAL

According to the J2EE specification, an EJB should not have any static fields with write access. However, static read-only fields are allowed. This ensures proper behavior especially when instances are distributed by the container on several JREs.

Example

 public class SomeEJB extends EJBObject implements EJBLocalHome {
 
     private static int       CountA; // poor, field can be edited
 
     private static final int CountB; // preferred, read-only access
 }
 

Since:

PMD 4.1

See Also:

PMD J2EE Rule Set Documentation, Constant Field Values

DO_NOT_USE_THREADS

public static final String DO_NOT_USE_THREADS

The J2EE specification explicitly forbids the use of threads.

Example

 // This is not allowed
 public class UsingThread extends Thread {
 
 }
 
 // Neither this,
 public class OtherThread implements Runnable {
     // Nor this ...
     public void methode() {
         Runnable thread = new Thread();
         thread.run();
     }
 }
 

Since:

PMD 4.1

See Also:

PMD J2EE Rule Set Documentation, Constant Field Values

BEAN_MEMBERS_SHOULD_SERIALIZE

public static final String BEAN_MEMBERS_SHOULD_SERIALIZE

If a class is a bean, or is referenced by a bean directly or indirectly it needs to be serializable. Member variables need to be marked as transient, static, or have accessor methods in the class. Marking variables as transient is the safest and easiest modification. Accessor methods should follow the Java naming conventions, i.e. for a variable named foo, getFoo() and setFoo() accessor methods should be provided.

Example

 public class Serialized {
     private transient int someFoo; // good, it's transient
     private static int    otherFoo; // also OK
     private int           moreFoo; // OK, has proper accessors, see below
     private int           badFoo;  // bad, should be
                                     // marked transient
 
     private void setMoreFoo(int moreFoo) {
         this.moreFoo = moreFoo;
     }
 
     private int getMoreFoo() {
         return this.moreFoo;
     }
 }
 

Since:

PMD 1.1

See Also:

PMD JavaBeans Rule Set Documentation, Constant Field Values

MISSING_SERIAL_VERSION_UID

public static final String MISSING_SERIAL_VERSION_UID

Serializable classes should provide a serialVersionUID field.

Example

 public class Foo implements java.io.Serializable {
     String name;
     // Define serialization id to avoid serialization related bugs
     // i.e., public static final long serialVersionUID = 4328743;
 }
 

Since:

PMD 3.0

See Also:

PMD JavaBeans Rule Set Documentation, Constant Field Values

JUNIT_STATIC_SUITE

public static final String JUNIT_STATIC_SUITE

The suite() method in a JUnit test needs to be both public and static.

Example

 public class Foo extends TestCase {
     public void suite() {
     } // oops, should be static
 
     private static void suite() {
     } // oops, should be public
 }
 

Since:

PMD 1.0

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

JUNIT_SPELLING

public static final String JUNIT_SPELLING

Some JUnit framework methods are easy to misspell.

Example

 public class Foo extends TestCase {
     public void setup() {
     } // oops, should be setUp
 
     public void TearDown() {
     } // oops, should be tearDown
 }
 

Since:

PMD 1.0

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

JUNIT_ASSERTIONS_SHOULD_INCLUDE_MESSAGE

public static final String JUNIT_ASSERTIONS_SHOULD_INCLUDE_MESSAGE

JUnit assertions should include an informative message - i.e., use the three-argument version of assertEquals(), not the two-argument version.

Example

 public class Foo extends TestCase {
     public void testSomething() {
         assertEquals("foo", "bar");
         // Use the form:
         // assertEquals("Foo does not equals bar", "foo", "bar");
         // instead
     }
 }
 

Since:

PMD 1.04

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

JUNIT_TESTS_SHOULD_INCLUDE_ASSERT

public static final String JUNIT_TESTS_SHOULD_INCLUDE_ASSERT

JUnit tests should include at least one assertion. This makes the tests more robust, and using assert with messages provide the developer a clearer idea of what the test does.

Example

 public class Foo extends TestCase {
     public void testSomething() {
         Bar b = findBar();
         // This is better than having a NullPointerException
         // assertNotNull("bar not found", b);
         b.work();
     }
 }
 

Since:

PMD 2.0

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

TEST_CLASS_WITHOUT_TEST_CASES

public static final String TEST_CLASS_WITHOUT_TEST_CASES

Test classes end with the suffix Test. Having a non-test class with that name is not a good practice, since most people will assume it is a test case. Test classes have test methods named testXXX.

Example

 // Consider changing the name of the class if it is not a test
 // Consider adding test methods if it is a test
 public class CarTest {
     public static void main(String[] args) {
         // do something
     }
     // code
 }
 

Since:

PMD 3.0

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

UNNECESSARY_BOOLEAN_ASSERTION

public static final String UNNECESSARY_BOOLEAN_ASSERTION

A JUnit test assertion with a boolean literal is unnecessary since it always will evaluate to the same thing. Consider using flow control (in case of assertTrue(false) or similar) or simply removing statements like assertTrue(true) and assertFalse(false). If you just want a test to halt after finding an error, use the fail() method and provide an indication message of why it did.

Example

 public class SimpleTest extends TestCase {
     public void testX() {
         assertTrue(true); // serves no real purpose
     }
 }
 

Since:

PMD 3.0

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

USE_ASSERT_EQUALS_INSTEAD_OF_ASSERT_TRUE

public static final String USE_ASSERT_EQUALS_INSTEAD_OF_ASSERT_TRUE

This rule detects JUnit assertions in object equality. These assertions should be made by more specific methods, like assertEquals.

Example

 public class FooTest extends TestCase {
     void testCode() {
         Object a, b;
         assertTrue(a.equals(b)); // bad usage
         assertEquals(a, b); // good usage
     }
 }
 

Since:

PMD 3.1

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

USE_ASSERT_SAME_INSTEAD_OF_ASSERT_TRUE

public static final String USE_ASSERT_SAME_INSTEAD_OF_ASSERT_TRUE

This rule detects JUnit assertions in object references equality. These assertions should be made by more specific methods, like assertSame, assertNotSame.

Example

 public class FooTest extends TestCase {
     void testCode() {
         Object a, b;
         assertTrue(a == b); // bad usage
         assertSame(a, b); // good usage
     }
 }
 

Since:

PMD 3.1

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

USE_ASSERT_NULL_INSTEAD_OF_ASSERT_TRUE

public static final String USE_ASSERT_NULL_INSTEAD_OF_ASSERT_TRUE

This rule detects JUnit assertions in object references equality. These assertions should be made by more specific methods, like assertNull, assertNotNull.

Example

 public class FooTest extends TestCase {
     void testCode() {
         Object a = doSomething();
         assertTrue(a == null); // bad usage
         assertNull(a); // good usage
         assertTrue(a != null); // bad usage
         assertNotNull(a); // good usage
     }
 }
 

Since:

PMD 3.5

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

SIMPLIFY_BOOLEAN_ASSERTION

public static final String SIMPLIFY_BOOLEAN_ASSERTION

Avoid negation in an assertTrue or assertFalse test. For example, rephrase: assertTrue(!expr); as: assertFalse(expr);

Example

 public class SimpleTest extends TestCase {
     public void testX() {
         assertTrue("not empty", !r.isEmpty()); // replace with assertFalse("not empty", r.isEmpty())
         assertFalse(!r.isEmpty()); // replace with assertTrue(r.isEmpty())
     }
 }
 

Since:

PMD 3.6

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

JUNIT_TEST_CONTAINS_TOO_MANY_ASSERTS

public static final String JUNIT_TEST_CONTAINS_TOO_MANY_ASSERTS

JUnit tests should not contain too many asserts. Many asserts are indicative of a complex test, for which it is harder to verify correctness. Consider breaking the test scenario into multiple, shorter test scenarios. Customize the maximum number of assertions used by this Rule to suit your needs.

Example

 public class MyTestCase extends TestCase {
     // Ok
     public void testMyCaseWithOneAssert() {
         boolean myVar = false;
         assertFalse("should be false", myVar);
     }
 
     // Bad, too many asserts (assuming max=1)
     public void testMyCaseWithMoreAsserts() {
         boolean myVar = false;
         assertFalse("myVar should be false", myVar);
         assertEquals("should equals false", false, myVar);
     }
 }
 

Since:

PMD 5.0

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

USE_ASSERT_TRUE_INSTEAD_OF_ASSERT_EQUALS

public static final String USE_ASSERT_TRUE_INSTEAD_OF_ASSERT_EQUALS

When asserting a value is the same as a boolean literal, use assertTrue/assertFalse, instead of assertEquals.

Example

 public class MyTestCase extends TestCase {
     public void testMyCase() {
         boolean myVar = true;
         // Ok
         assertTrue("myVar is true", myVar);
         // Bad
         assertEquals("myVar is true", true, myVar);
         // Bad
         assertEquals("myVar is false", false, myVar);
     }
 }
 

Since:

PMD 5.0

See Also:

PMD JUnit Rule Set Documentation, Constant Field Values

USE_CORRECT_EXCEPTION_LOGGING

public static final String USE_CORRECT_EXCEPTION_LOGGING

To make sure the full stacktrace is printed out, use the logging statement with two arguments: a String and a Throwable.

Example

 public class Main {
     private static final Log _LOG = LogFactory.getLog(Main.class);
 
     void bar() {
         try {
         } catch (Exception e) {
             _LOG.error(e); // Wrong!
         } catch (OtherException oe) {
             _LOG.error(oe.getMessage(), oe); // Correct
         }
     }
 }
 

Since:

PMD 3.2

See Also:

PMD Jakarta Commons Logging Rule Set Documentation, Constant Field Values

PROPER_LOGGER

public static final String PROPER_LOGGER

A logger should normally be defined private static final and be associated with the correct class. Private final Log log; is also allowed for rare cases where loggers need to be passed around, with the restriction that the logger needs to be passed into the constructor.

Example

 public class Foo {
 
     private static final Log LOG = LogFactory.getLog(Foo.class);      // proper way
 
     protected Log            LOG = LogFactory.getLog(Testclass.class); // wrong approach
 }
 

Since:

PMD 3.3

See Also:

PMD Jakarta Commons Logging Rule Set Documentation, Constant Field Values

GUARD_DEBUG_LOGGING

public static final String GUARD_DEBUG_LOGGING

When log messages are composed by concatenating strings, the whole section should be guarded by a isDebugEnabled() check to avoid performance and memory issues.

Example

 public class Test {
     private static final Log __log = LogFactory.getLog(Test.class);
 
     public void test() {
         // okay:
         __log.debug("log something");
 
         // okay:
         __log.debug("log something with exception", e);
 
         // bad:
         __log.debug("log something" + " and " + "concat strings");
 
         // bad:
         __log.debug("log something" + " and " + "concat strings", e);
 
         // good:
         if (__log.isDebugEnabled()) {
             __log.debug("bla" + "", e);
         }
     }
 }
 

Since:

PMD 4.3

See Also:

PMD Jakarta Commons Logging Rule Set Documentation, Constant Field Values

MORE_THAN_ONE_LOGGER

public static final String MORE_THAN_ONE_LOGGER

Normally only one logger is used in each class.

Example

 public class Foo {
     Logger log  = Logger.getLogger(Foo.class.getName());
     // It is very rare to see two loggers on a class, normally
     // log information is multiplexed by levels
     Logger log2 = Logger.getLogger(Foo.class.getName());
 }
 

Since:

PMD 2.0

See Also:

PMD Java Logging Rule Set Documentation, Constant Field Values

LOGGER_IS_NOT_STATIC_FINAL

public static final String LOGGER_IS_NOT_STATIC_FINAL

In most cases, the Logger reference can be declared as static and final.

Example

 public class Foo {
     Logger              log = Logger.getLogger(Foo.class.getName()); // not recommended
 
     static final Logger log = Logger.getLogger(Foo.class.getName()); // preferred approach
 }
 

Since:

PMD 2.0

See Also:

PMD Java Logging Rule Set Documentation, Constant Field Values

SYSTEM_PRINTLN

public static final String SYSTEM_PRINTLN

References to System.(out|err).print are usually intended for debugging purposes and can remain in the codebase even in production code. By using a logger one can enable/disable this behaviour at will (and by priority) and avoid clogging the Standard out log.

Example

 class Foo {
     Logger log = Logger.getLogger(Foo.class.getName());
 
     public void testA() {
         System.out.println("Entering test");
         // Better use this
         log.fine("Entering test");
     }
 }
 

Since:

PMD 2.1

See Also:

PMD Java Logging Rule Set Documentation, Constant Field Values

AVOID_PRINT_STACK_TRACE

public static final String AVOID_PRINT_STACK_TRACE

Avoid printStackTrace(); use a logger call instead.

Example

 class Foo {
     void bar() {
         try {
             // do something
         } catch (Exception e) {
             e.printStackTrace();
         }
     }
 }
 

Since:

PMD 3.2

See Also:

PMD Java Logging Rule Set Documentation, Constant Field Values

REPLACE_VECTOR_WITH_LIST

public static final String REPLACE_VECTOR_WITH_LIST

Consider replacing Vector usages with the newer java.util.ArrayList if expensive thread-safe operations are not required.

Example

 public class Foo {
     void bar() {
         Vector v = new Vector();
     }
 }
 

Since:

PMD 3.4

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

REPLACE_HASHTABLE_WITH_MAP

public static final String REPLACE_HASHTABLE_WITH_MAP

Consider replacing Hashtable usage with the newer java.util.Map if thread safety is not required.

Example

 public class Foo {
     void bar() {
         Hashtable h = new Hashtable();
     }
 }
 

Since:

PMD 3.4

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

REPLACE_ENUMERATION_WITH_ITERATOR

public static final String REPLACE_ENUMERATION_WITH_ITERATOR

Consider replacing Enumeration usages with the newer java.util.Iterator

Example

 public class Foo implements Enumeration {
     private int x = 42;
 
     public boolean hasMoreElements() {
         return true;
     }
 
     public Object nextElement() {
         return String.valueOf(i++);
     }
 }
 

Since:

PMD 3.4

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

AVOID_ENUM_AS_IDENTIFIER

public static final String AVOID_ENUM_AS_IDENTIFIER

Use of the term 'enum' will conflict with newer versions of Java since it is a reserved word.

Example

 public class A {
     public  class foo {
         String enum = "foo";
     }
 }
 

Since:

PMD 3.4

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

AVOID_ASSERT_AS_IDENTIFIER

public static final String AVOID_ASSERT_AS_IDENTIFIER

Use of the term 'assert' will conflict with newer versions of Java since it is a reserved word.

Example

 public class A {
     public  class foo {
         String assert = "foo";
     }
 }
 

Since:

PMD 3.4

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

INTEGER_INSTANTIATION

public static final String INTEGER_INSTANTIATION

Calling new Integer() causes memory allocation that can be avoided by the static Integer.valueOf(). It makes use of an internal cache that recycles earlier instances making it more memory efficient.

Example

 public class Foo {
     private Integer i = new Integer(0); // change to Integer i = Integer.valueOf(0);
 }
 

Since:

PMD 3.5

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

BYTE_INSTANTIATION

public static final String BYTE_INSTANTIATION

Calling new Byte() causes memory allocation that can be avoided by the static Byte.valueOf(). It makes use of an internal cache that recycles earlier instances making it more memory efficient.

Example

 public class Foo {
     private Byte i = new Byte(0); // change to Byte i = Byte.valueOf(0);
 }
 

Since:

PMD 4.0

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

SHORT_INSTANTIATION

public static final String SHORT_INSTANTIATION

Calling new Short() causes memory allocation that can be avoided by the static Short.valueOf(). It makes use of an internal cache that recycles earlier instances making it more memory efficient.

Example

 public class Foo {
     private Short i = new Short(0); // change to Short i = Short.valueOf(0);
 }
 

Since:

PMD 4.0

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

LONG_INSTANTIATION

public static final String LONG_INSTANTIATION

Calling new Long() causes memory allocation that can be avoided by the static Long.valueOf(). It makes use of an internal cache that recycles earlier instances making it more memory efficient.

Example

 public class Foo {
     private Long i = new Long(0); // change to Long i = Long.valueOf(0);
 }
 

Since:

PMD 4.0

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

JUNIT_4_TEST_SHOULD_USE_BEFORE_ANNOTATION

public static final String JUNIT_4_TEST_SHOULD_USE_BEFORE_ANNOTATION

In JUnit 3, the setUp method was used to set up all data entities required in running tests. JUnit 4 skips the setUp method and executes all methods annotated with @Before before all tests

Example

 public class MyTest {
     public void setUp() {
         bad();
     }
 }
 
 public class MyTest2 {
     @Before
     public void setUp() {
         good();
     }
 }
 

Since:

PMD 4.0

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

JUNIT_4_TEST_SHOULD_USE_AFTER_ANNOTATION

public static final String JUNIT_4_TEST_SHOULD_USE_AFTER_ANNOTATION

In JUnit 3, the tearDown method was used to clean up all data entities required in running tests. JUnit 4 skips the tearDown method and executes all methods annotated with @After after running each test.

Example

 public class MyTest {
     public void tearDown() {
         bad();
     }
 }
 
 public class MyTest2 {
     @After
     public void tearDown() {
         good();
     }
 }
 

Since:

PMD 4.0

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

JUNIT_4_TEST_SHOULD_USE_TEST_ANNOTATION

public static final String JUNIT_4_TEST_SHOULD_USE_TEST_ANNOTATION

In JUnit 3, the framework executed all methods which started with the word test as a unit test. In JUnit 4, only methods annotated with the @Test annotation are executed.

Example

 public class MyTest {
     public void testBad() {
         doSomething();
     }
 
     @Test
     public void testGood() {
         doSomething();
     }
 }
 
 

Since:

PMD 4.0

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

JUNIT_4_SUITES_SHOULD_USE_SUITE_ANNOTATION

public static final String JUNIT_4_SUITES_SHOULD_USE_SUITE_ANNOTATION

In JUnit 3, test suites are indicated by the suite() method. In JUnit 4, suites are indicated through the RunWith(Suite.class) annotation.

Example

 public class BadExample extends TestCase {
 
     public static Test suite() {
         return new Suite();
     }
 }
 
 @RunWith(Suite.class)
 @SuiteClasses({ TestOne.class, TestTwo.class })
 public class GoodTest {
 }
 

Since:

PMD 4.0

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

JUNIT_USE_EXPECTED

public static final String JUNIT_USE_EXPECTED

In JUnit4, use the @Test(expected) annotation to denote tests that should throw exceptions.

Example

 public class MyTest {
     @Test
     public void testBad() {
         try {
             doSomething();
             fail("should have thrown an exception");
         } catch (Exception e) {
         }
     }
 
     @Test(expected = Exception.class)
     public void testGood() {
         doSomething();
     }
 }
 

Since:

PMD 4.0

See Also:

PMD Migration Rule Set Documentation, Constant Field Values

SHORT_VARIABLE

public static final String SHORT_VARIABLE

Fields, local variables, or parameter names that are very short are not helpful to the reader.

Example

 public class Something {
     private int q = 15; // field - too short
 
     public static void main(String as[]) { // formal arg - too short
         int r = 20 + q; // local var - too short
         for (int i = 0; i < 10; i++) { // not a violation (inside 'for' loop)
             r += q;
         }
     }
 }
 

Since:

PMD 0.3

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

LONG_VARIABLE

public static final String LONG_VARIABLE

Fields, formal arguments, or local variable names that are too long can make the code difficult to follow.

Example

 public class Something {
     int reallyLongIntName = -3;             // VIOLATION - Field
     public static void main( String argumentsList[] ) { // VIOLATION - Formal
         int otherReallyLongName = -5;       // VIOLATION - Local
         for (int interestingIntIndex = 0;   // VIOLATION - For
              interestingIntIndex < 10;
              interestingIntIndex ++ ) {
     }
 }
 

Since:

PMD 0.3

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

SHORT_METHOD_NAME

public static final String SHORT_METHOD_NAME

Method names that are very short are not helpful to the reader.

Example

 public class ShortMethod {
     public void a(int i) { // Violation
     }
 }
 

Since:

PMD 0.3

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

VARIABLE_NAMING_CONVENTIONS

public static final String VARIABLE_NAMING_CONVENTIONS

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.

Example

 public class Foo {
     public static final int MY_NUM = 0;
     public String           myTest = "";
     DataModule              dmTest = new DataModule();
 }
 

Since:

PMD 1.2

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

METHOD_NAMING_CONVENTIONS

public static final String METHOD_NAMING_CONVENTIONS

Method names should always begin with a lower case character, and should not contain underscores.

Example

 public class Foo {
     public void fooStuff() {
     }
 }
 

Since:

PMD 1.2

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

CLASS_NAMING_CONVENTIONS

public static final String CLASS_NAMING_CONVENTIONS

Class names should always begin with an upper case character.

Example

 public class Foo {
 }
 

Since:

PMD 1.2

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

ABSTRACT_NAMING

public static final String ABSTRACT_NAMING

Abstract classes should be named 'AbstractXXX'.

Example

 public abstract class Foo { // should be AbstractFoo
 }
 

Since:

PMD 1.4

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

AVOID_DOLLAR_SIGNS

public static final String AVOID_DOLLAR_SIGNS

Avoid using dollar signs in variable/method/class/interface names.

Example

 public class Fo$o { // not a recommended name
 }
 

Since:

PMD 1.5

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

METHOD_WITH_SAME_NAME_AS_ENCLOSING_CLASS

public static final String METHOD_WITH_SAME_NAME_AS_ENCLOSING_CLASS

Non-constructor methods should not have the same name as the enclosing class.

Example

 public class MyClass {
 
     public MyClass() {
     } // this is OK because it is a constructor
 
     public void MyClass() {
     } // this is bad because it is a method
 }
 

Since:

PMD 1.5

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

SUSPICIOUS_HASHCODE_METHOD_NAME

public static final String SUSPICIOUS_HASHCODE_METHOD_NAME

The method name and return type are suspiciously close to hashCode(), which may denote an intention to override the hashCode() method.

Example

 public class Foo {
     public int hashcode() { // oops, this probably was supposed to be 'hashCode'
 
     }
 }
 

Since:

PMD 1.5

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

SUSPICIOUS_CONSTANT_FIELD_NAME

public static final String SUSPICIOUS_CONSTANT_FIELD_NAME

Field names using all uppercase characters - Sun's Java naming conventions indicating constants - should be declared as final.

Example

 public class Foo {
     // this is bad, since someone could accidentally
     // do PI = 2.71828; which is actually e
     // final double PI = 3.16; is ok
     double PI = 3.16;
 }
 

Since:

PMD 2.0

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

SUSPICIOUS_EQUALS_METHOD_NAME

public static final String SUSPICIOUS_EQUALS_METHOD_NAME

The method name and parameter number are suspiciously close to equals(Object), which can denote an intention to override the equals(Object) method.

Example

 public class Foo {
     public int equals(Object o) {
         // oops, this probably was supposed to be boolean equals
     }
 
     public boolean equals(String s) {
         // oops, this probably was supposed to be equals(Object)
     }
 
     public boolean equals(Object o1, Object o2) {
         // oops, this probably was supposed to be equals(Object)
     }
 }
 

Since:

PMD 2.0

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

AVOID_FIELD_NAME_MATCHING_TYPE_NAME

public static final String AVOID_FIELD_NAME_MATCHING_TYPE_NAME

It is somewhat confusing to have a field name matching the declaring class name. This probably means that type and/or field names should be chosen more carefully.

Example

 public class Foo extends Bar {
     int foo; // There is probably a better name that can be used
 }
 

Since:

PMD 3.0

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

AVOID_FIELD_NAME_MATCHING_METHOD_NAME

public static final String AVOID_FIELD_NAME_MATCHING_METHOD_NAME

It can be confusing to have a field name with the same name as a method. While this is permitted, having information (field) and actions (method) is not clear naming. Developers versed in Smalltalk often prefer this approach as the methods denote accessor methods.

Example

 public class Foo {
     Object bar;
 
     // bar is data or an action or both?
     void bar() {
     }
 }
 

Since:

PMD 3.0

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

NO_PACKAGE

public static final String NO_PACKAGE

Detects when a class or interface does not have a package definition.

Example

 // no package declaration
 public class ClassInDefaultPackage {
 }
 

Since:

PMD 3.3

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

PACKAGE_CASE

public static final String PACKAGE_CASE

Detects when a package definition contains uppercase characters.

Example

 package com.MyCompany; // should be lowercase name
 

Since:

PMD 3.3

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

MISLEADING_VARIABLE_NAME

public static final String MISLEADING_VARIABLE_NAME

Detects when a non-field has a name starting with 'm_'. This usually denotes a field and could be confusing.

Example

 public class Foo {
     private int m_foo; // OK
 
     public void bar(String m_baz) { // Bad
         int m_boz = 42; // Bad
     }
 }
 

Since:

PMD 3.4

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

BOOLEAN_GET_METHOD_NAME

public static final String BOOLEAN_GET_METHOD_NAME

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.

Example

 public boolean getFoo(); // bad
 
 public boolean isFoo(); // ok
 
 public boolean getFoo(boolean bar); // ok, unless checkParameterizedMethods=true
 

Since:

PMD 4.0

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

SHORT_CLASS_NAME

public static final String SHORT_CLASS_NAME

Classnames with fewer than five characters are not recommended.

Example

 public class Foo {
 }
 

Since:

PMD 5.0

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

GENERICS_NAMING

public static final String GENERICS_NAMING

Names for references to generic values should be limited to a single uppercase letter.

Example

 public interface GenericDao<E extends BaseModel, K extends Serializable> extends BaseDao {
     // This is ok...
 }
 
 public interface GenericDao<E extends BaseModel, K extends Serializable> {
     // Also this
 }
 
 public interface GenericDao<e extends BaseModel, K extends Serializable> {
     // 'e' should be an 'E'
 }
 
 public interface GenericDao<EF extends BaseModel, K extends Serializable> {
     // 'EF' is not ok.
 }
 
 

Since:

PMD 4.2.6

See Also:

PMD Naming Rule Set Documentation, Constant Field Values

LOCAL_VARIABLE_COULD_BE_FINAL

public static final String LOCAL_VARIABLE_COULD_BE_FINAL

A local variable assigned only once can be declared final.

Example

 public class Bar {
     public void foo() {
         String txtA = "a"; // if txtA will not be assigned again it is better to do this:
         final String txtB = "b";
     }
 }
 

Since:

PMD 2.2

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

METHOD_ARGUMENT_COULD_BE_FINAL

public static final String METHOD_ARGUMENT_COULD_BE_FINAL

A method argument that is never re-assigned within the method can be declared final.

Example

 public void foo1(String param) { // do stuff with param never assigning it
 
 }
 
 public void foo2(final String param) { // better, do stuff with param never assigning it
 
 }
 

Since:

PMD 2.2

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

AVOID_INSTANTIATING_OBJECTS_IN_LOOPS

public static final String AVOID_INSTANTIATING_OBJECTS_IN_LOOPS

New objects created within loops should be checked to see if they can created outside them and reused.

Example

 public class Something {
     public static void main(String as[]) {
         for (int i = 0; i < 10; i++) {
             Foo f = new Foo(); // Avoid this whenever you can it's really expensive
         }
     }
 }
 

Since:

PMD 2.2

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

USE_ARRAY_LIST_INSTEAD_OF_VECTOR

public static final String USE_ARRAY_LIST_INSTEAD_OF_VECTOR

ArrayList is a much better Collection implementation than Vector if thread-safe operation is not required.

Example

 public class SimpleTest extends TestCase {
     public void testX() {
         Collection c1 = new Vector();
         Collection c2 = new ArrayList(); // achieves the same with much better performance
     }
 }
 

Since:

PMD 3.0

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

SIMPLIFY_STARTS_WITH

public static final String SIMPLIFY_STARTS_WITH

Since it passes in a literal of length 1, calls to (string).startsWith can be rewritten using (string).charAt(0) at the expense of some readability.

Example

 public class Foo {
 
     boolean checkIt(String x) {
         return x.startsWith("a"); // suboptimal
     }
 
     boolean fasterCheckIt(String x) {
         return x.charAt(0) == 'a'; // faster approach
     }
 }
 

Since:

PMD 3.1

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

USE_STRING_BUFFER_FOR_STRING_APPENDS

public static final String USE_STRING_BUFFER_FOR_STRING_APPENDS

The use of the '+=' operator for appending strings causes the JVM to create and use an internal StringBuffer. If a non-trivial number of these concatenations are being used then the explicit use of a StringBuilder or threadsafe StringBuffer is recommended to avoid this.

Example

 public class Foo {
     void bar() {
         String a;
         a = "foo";
         a += " bar";
         // better would be:
         // StringBuilder a = new StringBuilder("foo");
         // a.append(" bar);
     }
 }
 

Since:

PMD 3.1

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

USE_ARRAYS_AS_LIST

public static final String USE_ARRAYS_AS_LIST

The java.util.Arrays class has a "asList" method that should be used when you want to create a new List from an array of objects. It is faster than executing a loop to copy all the elements of the array one by one.

Example

 public class Test {
     public void foo(Integer[] ints) {
         // could just use Arrays.asList(ints)
         List l = new ArrayList(10);
         for (int i = 0; i < 100; i++) {
             l.add(ints[i]);
         }
         for (int i = 0; i < 100; i++) {
             l.add(a[i].toString()); // won't trigger the rule
         }
     }
 }
 

Since:

PMD 3.5

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

AVOID_ARRAY_LOOPS

public static final String AVOID_ARRAY_LOOPS

Instead of manually copying data between two arrays, use the efficient System.arraycopy method instead.

Example

 public class Test {
   public void bar() {
     int[] a = new int[10];
     int[] b = new int[10];
     for (int i=0;i<10;i++) {
       b[i]=a[i];
     }
   }
 }
      // this will trigger the rule
      for (int i=0;i<10;i++) {
        b[i]=a[c[i]];
      }
 
   }
 }
 

Since:

PMD 3.5

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

UNNECESSARY_WRAPPER_OBJECT_CREATION

public static final String UNNECESSARY_WRAPPER_OBJECT_CREATION

Most wrapper classes provide static conversion methods that avoid the need to create intermediate objects just to create the primitive forms. Using these avoids the cost of creating objects that also need to be garbage-collected later.

Example

 public int convert(String s) {
     int i, i2;
 
     i = Integer.valueOf(s).intValue(); // this wastes an object
     i = Integer.parseInt(s); // this is better
 
     i2 = Integer.valueOf(i).intValue(); // this wastes an object
     i2 = i; // this is better
 
     String s3 = Integer.valueOf(i2).toString(); // this wastes an object
     s3 = Integer.toString(i2); // this is better
 
     return i2;
 }
 

Since:

PMD 3.8

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

ADD_EMPTY_STRING

public static final String ADD_EMPTY_STRING

The conversion of literals to strings by concatenating them with empty strings is inefficient. It is much better to use one of the type-specific toString() methods instead.

Example

 // inefficient
 String s = "" + 123;
 

Since:

PMD 4.0

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

REDUNDANT_FIELD_INITIALIZER

public static final String REDUNDANT_FIELD_INITIALIZER

Java will initialize fields with known default values so any explicit initialization of those same defaults is redundant and results in a larger class file (approximately three additional bytecode instructions per field).

Example

 public class C {
     boolean b     = false; // examples of redundant initializers
     byte    by    = 0;
     short   s     = 0;
     char    c     = 0;
     int     i     = 0;
     long    l     = 0;
 
     float   f     = .0f;  // all possible float literals
     doable  d     = 0d;   // all possible double literals
     Object  o     = null;
 
     MyClass mca[] = null;
     int     i1    = 0, ia1[] = null;
 
     class Nested {
         boolean b = false;
     }
 }
 

Since:

PMD 4.0

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

PREMATURE_DECLARATION

public static final String PREMATURE_DECLARATION

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.

Example

 public int getLength(String[] strings) {
 
     int length = 0; // declared prematurely
 
     if (strings == null || strings.length == 0)
         return 0;
 
     for (String str : strings) {
         length += str.length();
     }
 
     return length;
 }
 

Since:

PMD 5.0

See Also:

PMD Optimization Rule Set Documentation, Constant Field Values

AVOID_CATCHING_THROWABLE

public static final String AVOID_CATCHING_THROWABLE

Catching Throwable errors is not recommended since its scope is very broad. It includes runtime issues such as OutOfMemoryError that should be exposed and managed separately.

Example

 public void bar() {
     try {
         // do something
     } catch (Throwable th) { // should not catch Throwable
         th.printStackTrace();
     }
 }
 

Since:

PMD 1.2

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

SIGNATURE_DECLARE_THROWS_EXCEPTION

public static final String SIGNATURE_DECLARE_THROWS_EXCEPTION

Methods that declare the generic Exception as a possible throwable are not very helpful since their failure modes are unclear. Use a class derived from RuntimeException or a more specific checked exception.

Example

 public void foo() throws Exception {
 }
 

Since:

PMD 1.2

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

EXCEPTION_AS_FLOW_CONTROL

public static final String EXCEPTION_AS_FLOW_CONTROL

Using Exceptions as form of flow control is not recommended as they obscure true exceptions when debugging. Either add the necessary validation or use an alternate control structure.

Example

 public void bar() {
     try {
         try {
         } catch (Exception e) {
             throw new WrapperException(e);
             // this is essentially a GOTO to the WrapperException catch block
         }
     } catch (WrapperException e) {
         // do some more stuff
     }
 }
 

Since:

PMD 1.8

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

AVOID_CATCHING_NPE

public static final String AVOID_CATCHING_NPE

Code should never throw NullPointerExceptions under normal circumstances. A catch block may hide the original error, causing other, more subtle problems later on.

Example

 public class Foo {
     void bar() {
         try {
             // do something
         } catch (NullPointerException npe) {
         }
     }
 }
 

Since:

PMD 1.8

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

AVOID_THROWING_RAW_EXCEPTION_TYPES

public static final String AVOID_THROWING_RAW_EXCEPTION_TYPES

Avoid throwing certain exception types. Rather than throw a raw RuntimeException, Throwable, Exception, or Error, use a subclassed exception or error instead.

Example

 public class Foo {
     public void bar() throws Exception {
         throw new Exception();
     }
 }
 

Since:

PMD 1.8

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

AVOID_THROWING_NULL_POINTER_EXCEPTION

public static final String AVOID_THROWING_NULL_POINTER_EXCEPTION

Avoid throwing NullPointerExceptions. These are confusing because most people will assume that the virtual machine threw it. Consider using an IllegalArgumentException instead; this will be clearly seen as a programmer-initiated exception.

Example

 public class Foo {
     void bar() {
         throw new NullPointerException();
     }
 }
 

Since:

PMD 1.8

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

AVOID_RETHROWING_EXCEPTION

public static final String AVOID_RETHROWING_EXCEPTION

Catch blocks that merely rethrow a caught exception only add to code size and runtime complexity.

Example

 public void bar() {
     try {
         // do something
     } catch (SomeException se) {
         throw se;
     }
 }
 

Since:

PMD 3.8

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

DO_NOT_EXTEND_JAVA_LANG_ERROR

public static final String DO_NOT_EXTEND_JAVA_LANG_ERROR

Errors are system exceptions. Do not extend them.

Example

 public class Foo extends Error {
 }
 

Since:

PMD 4.0

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

DO_NOT_THROW_EXCEPTION_IN_FINALLY

public static final String DO_NOT_THROW_EXCEPTION_IN_FINALLY

Throwing exceptions within a 'finally' block is confusing since they may mask other exceptions or code defects. Note: This is a PMD implementation of the Lint4j rule "A throw in a finally block"

Example

 public class Foo {
     public void bar() {
         try {
             // Here do some stuff
         } catch (Exception e) {
             // Handling the issue
         } finally {
             // is this really a good idea ?
             throw new Exception();
         }
     }
 }
 

Since:

PMD 4.2

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

AVOID_THROWING_NEW_INSTANCE_OF_SAME_EXCEPTION

public static final String AVOID_THROWING_NEW_INSTANCE_OF_SAME_EXCEPTION

Catch blocks that merely rethrow a caught exception wrapped inside a new instance of the same type only add to code size and runtime complexity.

Example

 public void bar() {
     try {
         // do something
     } catch (SomeException se) {
         // harmless comment
         throw new SomeException(se);
     }
 }
 

Since:

PMD 4.2.5

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

AVOID_CATCHING_GENERIC_EXCEPTION

public static final String AVOID_CATCHING_GENERIC_EXCEPTION

Avoid catching generic exceptions such as NullPointerException, RuntimeException, Exception in try-catch block.

Example

 public class PrimitiveType {
 
     public void downCastPrimitiveType() {
         try {
             System.out.println(" i [" + i + "]");
         } catch (Exception e) {
             e.printStackTrace();
         } catch (RuntimeException e) {
             e.printStackTrace();
         } catch (NullPointerException e) {
             e.printStackTrace();
         }
     }
 }
 

Since:

PMD 4.2.6

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

AVOID_LOSING_EXCEPTION_INFORMATION

public static final String AVOID_LOSING_EXCEPTION_INFORMATION

Statements in a catch block that invoke accessors on the exception without using the information only add to code size. Either remove the invocation, or use the return result.

Example

 public void bar() {
     try {
         // do something
     } catch (SomeException se) {
         se.getMessage();
     }
 }
 

Since:

PMD 4.2.6

See Also:

PMD Strict Exceptions Rule Set Documentation, Constant Field Values

AVOID_DUPLICATE_LITERALS

public static final String AVOID_DUPLICATE_LITERALS

Code containing duplicate String literals can usually be improved by declaring the String as a constant field.

Example

 private void bar() {
     buz("Howdy");
     buz("Howdy");
     buz("Howdy");
     buz("Howdy");
 }
 

Since:

PMD 1.0

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

STRING_INSTANTIATION

public static final String STRING_INSTANTIATION

Avoid instantiating String objects; this is usually unnecessary since they are immutable and can be safely shared.

Example

 private String bar = new String("bar"); // just do a String bar = "bar";
 

Since:

PMD 1.0

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

STRING_TO_STRING

public static final String STRING_TO_STRING

Avoid calling toString() on objects already known to be string instances; this is unnecessary.

Example

 private String baz() {
     String bar = "howdy";
     return bar.toString();
 }
 

Since:

PMD 1.0

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

INEFFICIENT_STRING_BUFFERING

public static final String INEFFICIENT_STRING_BUFFERING

Avoid concatenating non-literals in a StringBuffer constructor or append() since intermediate buffers will need to be be created and destroyed by the JVM.

Example

 // Avoid this, two buffers are actually being created here
 StringBuffer sb = new StringBuffer("tmp = " + System.getProperty("java.io.tmpdir"));
 
 // do this instead
 StringBuffer sb = new StringBuffer("tmp = ");
 sb.append(System.getProperty("java.io.tmpdir"));
 

Since:

PMD 3.4

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

UNNECESSARY_CASE_CHANGE

public static final String UNNECESSARY_CASE_CHANGE

Using equalsIgnoreCase() is faster than using toUpperCase/toLowerCase().equals()

Example

 boolean answer1 = buz.toUpperCase().equals("baz"); // should be buz.equalsIgnoreCase("baz")
 

Since:

PMD 3.3

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

USE_STRING_BUFFER_LENGTH

public static final String USE_STRING_BUFFER_LENGTH

Use StringBuffer.length() to determine StringBuffer length rather than using StringBuffer.toString().equals("") or StringBuffer.toString().length() == ...

Example

 StringBuffer sb = new StringBuffer();
 
 if (sb.toString().equals("")) {
 } // inefficient
 
 if (sb.length() == 0) {
 } // preferred
 

Since:

PMD 3.4

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

APPEND_CHARACTER_WITH_CHAR

public static final String APPEND_CHARACTER_WITH_CHAR

Avoid concatenating characters as strings in StringBuffer/StringBuilder.append methods.

Example

 StringBuffer sb = new StringBuffer();
 sb.append("a"); // avoid this
 
 StringBuffer sb = new StringBuffer();
 sb.append('a'); // use this instead
 

Since:

PMD 3.5

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

CONSECUTIVE_LITERAL_APPENDS

public static final String CONSECUTIVE_LITERAL_APPENDS

Consecutively calling StringBuffer/StringBuilder.append with String literals

Example

 StringBuffer buf = new StringBuffer();
 buf.append("Hello").append(" ").append("World"); // poor
 buf.append("Hello World"); // good
 

Since:

PMD 3.5

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

USE_INDEX_OF_CHAR

public static final String USE_INDEX_OF_CHAR

Use String.indexOf(char) when checking for the index of a single character; it executes faster.

Example

 String s = "hello world";
   // avoid this
 if (s.indexOf("d") {}
   // instead do this
 if (s.indexOf('d') {}
 

Since:

PMD 3.5

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

INEFFICIENT_EMPTY_STRING_CHECK

public static final String INEFFICIENT_EMPTY_STRING_CHECK

String.trim().length() is an inefficient way to check if a String is really empty, as it creates a new String object just to check its size. Consider creating a static function that loops through a string, checking Character.isWhitespace() on each character and returning false if a non-whitespace character is found.

Example

 public void bar(String string) {
     if (string != null && string.trim().size() > 0) {
         doSomething();
     }
 }
 

Since:

PMD 3.6

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

INSUFFICIENT_STRING_BUFFER_DECLARATION

public static final String INSUFFICIENT_STRING_BUFFER_DECLARATION

Failing to pre-size a StringBuffer or StringBuilder properly could cause it to re-size many times during runtime. This rule attempts to determine the total number the characters that are actually passed into StringBuffer.append(), but represents a best guess "worst case" scenario. An empty StringBuffer/StringBuilder constructor initializes the object to 16 characters. This default is assumed if the length of the constructor can not be determined.

Example

 StringBuffer bad = new StringBuffer();
 bad.append("This is a long string that will exceed the default 16 characters");
 
 StringBuffer good = new StringBuffer(41);
 good.append("This is a long string, which is pre-sized");
 

Since:

PMD 3.6

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

USELESS_STRING_VALUE_OF

public static final String USELESS_STRING_VALUE_OF

No need to call String.valueOf to append to a string; just use the valueOf() argument directly.

Example

 public String convert(int i) {
     String s;
     s = "a" + String.valueOf(i); // not required
     s = "a" + i; // preferred approach
     return s;
 }
 

Since:

PMD 3.8

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

STRING_BUFFER_INSTANTIATION_WITH_CHAR

public static final String STRING_BUFFER_INSTANTIATION_WITH_CHAR

Individual character values provided as initialization arguments will be converted into integers. This can lead to internal buffer sizes that are larger than expected. Some examples: new StringBuffer() // 16 new StringBuffer(6) // 6 new StringBuffer("hello world") // 11 + 16 = 27 new StringBuffer('A') // chr(A) = 65 new StringBuffer("A") // 1 + 16 = 17 new StringBuilder() // 16 new StringBuilder(6) // 6 new StringBuilder("hello world") // 11 + 16 = 27 new StringBuilder('C') // chr(C) = 67 new StringBuilder("A") // 1 + 16 = 17

Since:

PMD 3.9

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

USE_EQUALS_TO_COMPARE_STRINGS

public static final String USE_EQUALS_TO_COMPARE_STRINGS

Using '==' or '!=' to compare strings only works if intern version is used on both sides. Use the equals() method instead.

Example

 public boolean test(String s) {
     if (s == "one")
         return true; // unreliable
     if ("two".equals(s))
         return true; // better
     return false;
 }
 

Since:

PMD 4.1

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

AVOID_STRING_BUFFER_FIELD

public static final String AVOID_STRING_BUFFER_FIELD

StringBuffers/StringBuilders can grow considerably, and so may become a source of memory leaks if held within objects with long lifetimes.

Example

 public class Foo {
     private StringBuffer buffer; // potential memory leak as an instance variable;
 }
 

Since:

PMD 4.2

See Also:

PMD String and StringBuffer Rule Set Documentation, Constant Field Values

METHOD_RETURNS_INTERNAL_ARRAY

public static final String METHOD_RETURNS_INTERNAL_ARRAY

Exposing internal arrays to the caller violates object encapsulation since elements can be removed or replaced outside of the object that owns it. It is safer to return a copy of the array.

Example

 public class SecureSystem {
     UserData[] ud;
 
     public UserData[] getUserData() {
         // Don't return directly the internal array, return a copy
         return ud;
     }
 }
 

Since:

PMD 2.2

See Also:

PMD Security Code Guidelines Rule Set Documentation, Constant Field Values

ARRAY_IS_STORED_DIRECTLY

public static final String ARRAY_IS_STORED_DIRECTLY

Constructors and methods receiving arrays should clone objects and store the copy. This prevents future changes from the user from affecting the original array.

Example

 public class Foo {
     private String[] x;
 
     public void foo(String[] param) {
         // Don't do this, make a copy of the array at least
         this.x = param;
     }
 }
 

Since:

PMD 2.2

See Also:

PMD Security Code Guidelines Rule Set Documentation, Constant Field Values

UNNECESSARY_CONVERSION_TEMPORARY

public static final String UNNECESSARY_CONVERSION_TEMPORARY

Avoid the use temporary objects when converting primitives to Strings. Use the static conversion methods on the wrapper classes instead.

Example

 public String convert(int x) {
     String foo = new Integer(x).toString(); // this wastes an object
 
     return Integer.toString(x); // preferred approach
 }
 

Since:

PMD 0.1

See Also:

PMD Unnecessary Rule Set Documentation, Constant Field Values

UNNECESSARY_RETURN

public static final String UNNECESSARY_RETURN

Avoid the use of unnecessary return statements.

Example

 public class Foo {
     public void bar() {
         int x = 42;
         return;
     }
 }
 

Since:

PMD 1.3

See Also:

PMD Unnecessary Rule Set Documentation, Constant Field Values

UNNECESSARY_FINAL_MODIFIER

public static final String UNNECESSARY_FINAL_MODIFIER

When a class has the final modifier, all the methods are automatically final and do not need to be tagged as such.

Example

 public final class Foo {
     // This final modifier is not necessary, since the class is final
     // and thus, all methods are final
     private final void foo() {
     }
 }
 

Since:

PMD 3.0

See Also:

PMD Unnecessary Rule Set Documentation, Constant Field Values

USELESS_OVERRIDING_METHOD

public static final String USELESS_OVERRIDING_METHOD

The overriding method merely calls the same method defined in a superclass.

Example

 public void foo(String bar) {
     super.foo(bar); // why bother overriding?
 }
 
 public String foo() {
     return super.foo(); // why bother overriding?
 }
 
 @Id
 public Long getId() {
     return super.getId(); // OK if 'ignoreAnnotations' is false, which is the default behavior
 }
 

Since:

PMD 3.3

See Also:

PMD Unnecessary Rule Set Documentation, Constant Field Values

USELESS_OPERATION_ON_IMMUTABLE

public static final String USELESS_OPERATION_ON_IMMUTABLE

An operation on an Immutable object (String, BigDecimal or BigInteger) won't change the object itself since the result of the operation is a new object. Therefore, ignoring the operation result is an error.

Example

 class Test {
     void method1() {
         BigDecimal bd = new BigDecimal(10);
         bd.add(new BigDecimal(5)); // this will trigger the rule
     }
 
     void method2() {
         BigDecimal bd = new BigDecimal(10);
         bd = bd.add(new BigDecimal(5)); // this won't trigger the rule
     }
 }
 

Since:

PMD 3.5

See Also:

PMD Unnecessary Rule Set Documentation, Constant Field Values

UNUSED_NULL_CHECK_IN_EQUALS

public static final String UNUSED_NULL_CHECK_IN_EQUALS

After checking an object reference for null, you should invoke equals() on that object rather than passing it to another object's equals() method.

Example

 public class Test {
 
     public String method1() {
         return "ok";
     }
 
     public String method2() {
         return null;
     }
 
     public void method(String a) {
         String b;
         // I don't know it method1() can be "null"
         // but I know "a" is not null..
         // I'd better write a.equals(method1())
 
         if (a != null && method1().equals(a)) { // will trigger the rule
             // whatever
         }
 
         if (method1().equals(a) && a != null) { // won't trigger the rule
             // whatever
         }
 
         if (a != null && method1().equals(b)) { // won't trigger the rule
             // whatever
         }
 
         if (a != null && "LITERAL".equals(a)) { // won't trigger the rule
             // whatever
         }
 
         if (a != null && !a.equals("go")) { // won't trigger the rule
             a = method2();
             if (method1().equals(a)) {
                 // whatever
             }
         }
     }
 }
 

Since:

PMD 3.5

See Also:

PMD Unnecessary Rule Set Documentation, Constant Field Values

USELESS_PARANTHESES

public static final String USELESS_PARANTHESES

Useless parentheses should be removed.

Example

 public class Foo {
 
     private int     _bar1;
     private Integer _bar2;
 
     public void setBar(int n) {
         _bar1 = Integer.valueOf((n)); // here
         _bar2 = (n); // and here
     }
 
 }
 

Since:

PMD 5.0

See Also:

PMD Unnecessary Rule Set Documentation, Constant Field Values

UNUSED_PRIVATE_FIELD

public static final String UNUSED_PRIVATE_FIELD

Detects when a private field is declared and/or assigned a value, but not used.

Example

 public class Something {
     private static int FOO = 2; // Unused
     private int        i   = 5; // Unused
     private int        j   = 6;
 
     public int addOne() {
         return j++;
     }
 }
 

Since:

PMD 0.1

See Also:

PMD Unused Rule Set Documentation, Constant Field Values

UNUSED_LOCAL_VARIABLE

public static final String UNUSED_LOCAL_VARIABLE

Detects when a local variable is declared and/or assigned, but not used.

Example

 public class Foo {
     public void doSomething() {
         int i = 5; // Unused
     }
 }
 

Since:

PMD 0.1

See Also:

PMD Unused Rule Set Documentation, Constant Field Values

UNUSED_PRIVATE_METHOD

public static final String UNUSED_PRIVATE_METHOD

Unused Private Method detects when a private method is declared but is unused.

Example

 public class Something {
     private void foo() {
     } // unused
 }
 

Since:

PMD 0.7

See Also:

PMD Unused Rule Set Documentation, Constant Field Values

UNUSED_FORMAL_PARAMETER

public static final String UNUSED_FORMAL_PARAMETER

Avoid passing parameters to methods or constructors without actually referencing them in the method body.

Example

 public class Foo {
     private void bar(String howdy) {
         // howdy is not used
     }
 }
 

Since:

PMD 0.8

See Also:

PMD Unused Rule Set Documentation, Constant Field Values

UNUSED_MODIFIER

public static final String UNUSED_MODIFIER

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.

Example

 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
 }
 

Since:

PMD 1.02

See Also:

PMD Unused Rule Set Documentation, Constant Field Values