Current Rulesets
List of rulesets and rules contained in each ruleset.
- scratchpad (
These are new rules that are still in progress
)
- Favorites (
The Favorites ruleset contains links to rules that I like to use. Usually I
combine this ruleset with the unusedcode.xml, basic.xml, and import.xml rulesets for my projects.
This ruleset also serves as an example of how to do a custom ruleset.
)
- Finalizer Rules (
These rules deal with different problems that can occur with finalizers.
)
- Unused Code Rules (
The Unused Code Ruleset contains a collection of rules that find unused code.
)
- Datenflussanomalieanalyse (
Dieses Ruleset enthaelt Regeln fuer die Datenflussanomalieanalyse.
Begriffe: d-definiert, r-referenziert, u-undefiniert
Folgende Konstellationen werden durch diese Regeln abgedeckt:
dd, du, ur
)
- Controversial Rules (
The Controversial Ruleset contains rules that, for whatever reason, are considered controversial. They
are separated out here to allow people to include as they see fit via custom rulesets. This ruleset was
initially created in response to discussions over UnnecessaryConstructorRule which Tom likes but
most people really dislike :-)
)
- Coupling Rules (
These are rules which find instances of high or inappropriate coupling between objects and packages.
)
- Optimization Rules (
These rules deal with different optimizations that generally apply to performance best practices.
)
- Basic Rules (
The Basic Ruleset contains a collection of good practices which everyone should follow.
)
- Design Rules (
The Design Ruleset contains a collection of rules that find questionable designs.
)
- Security Code Guidelines (
These rules check the security guidelines from Sun, published at http://java.sun.com/security/seccodeguide.html#gcg
)
- Strict Exception Rules (
These rules provide some strict guidelines about throwing and catching exceptions.
)
- JavaBean Rules (
The JavaBeans Ruleset catches instances of bean rules not being followed.
)
- java.lang.String Rules (
These rules deal with different problems that can occur with String manipulation.
)
- Code Size Rules (
The Code Size Ruleset contains a collection of rules that find code size related problems.
)
- Import Statement Rules (
These rules deal with different problems that can occur with a class' import statements.
)
- Clone Implementation Rules (
The Clone Implementation ruleset contains a collection of rules that find questionable usages of the clone() method.
)
- Naming Rules (
The Naming Ruleset contains a collection of rules about names - too long, too short, and so forth.
)
- my-rules ()
- JUnit Rules (
These rules deal with different problems that can occur with JUnit tests.
)
- Java Logging Rules (
The Java Logging ruleset contains a collection of rules that find questionable usages of the Logger.
)
- newrules (
These are new rules for the next release
)
- Braces Rules (
The Braces Ruleset contains a collection of braces rules.
)
scratchpad
ConstructorCallsOverridableMethod (
Calling overridable methods during construction poses a risk of invoking methods on an
incompletely constructed object. This situation can be difficult to discern.
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(), there's a problem.
)Favorites
() () () () () () () () () () () ()Finalizer Rules
EmptyFinalizer (
If the finalize() method is empty, then it does not need to exist.
) FinalizeOnlyCallsSuperFinalize (
If the finalize() is implemented, it should do something besides just calling
super.finalize().
) FinalizeOverloaded (
Methods named finalize() should not have parameters. It is
confusing and probably a bug to overload finalize(). It will
not be called by the VM.
) FinalizeDoesNotCallSuperFinalize (
If the finalize() is implemented, its last action should be to call super.finalize
) ExplicitCallToFinalize (
An explicit call was made to a finalize method. Finalize methods
are meant to be executed at most once (by the garbage collector).
Calling it explicitly could result in the method being executed
twice for that object (once by you, once by the garbage collector).
) FinalizeShouldBeProtected (
If you override finalize(), make it protected. Otherwise, subclasses
may not called your implementation of finalize.
)Unused Code Rules
UnusedPrivateField (
Detects when a private field is declared and/or assigned a value, but not used.
) UnusedLocalVariable (
Detects when a local variable is declared and/or assigned, but not used.
) UnusedPrivateMethod (
Unused Private Method detects when a private method is declared but is unused.
) UnusedFormalParameter (
Avoid passing parameters to methods and then not using those parameters.
)Datenflussanomalieanalyse
Controversial Rules
UnnecessaryConstructor (
Unnecessary constructor detects when a constructor is not necessary; i.e., when there's only one constructor,
it's public, has an empty body, and takes no arguments.
) NullAssignment (
Assigning a "null" to a variable (outside of its declaration) is usually in
bad form. Some times, the assignment is an indication that the programmer doesn't
completely understand what is going on in the code. NOTE: This sort of assignment
may in rare cases be useful to encourage garbage collection. If that's what you're using
it for, by all means, disregard this rule :-)
) OnlyOneReturn (
A method should have only one exit point, and that should be the last statement in the method.
) UnusedModifier (
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.
) AssignmentInOperand (
Avoid assigments in operands; this can make code more complicated and harder to read.
) AtLeastOneConstructor (
Each class should declare at least one constructor.
) DontImportSun (
Avoid importing anything from the 'sun.*' packages. These packages are not portable and are likely to change.
) SuspiciousOctalEscape (
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".
) CallSuperInConstructor (
It is a good practice to call super() in a constructor. If super() is not called
but another constructor, such as an overloaded constructor, of the class is called, this rule
will not report it.
) UnnecessaryParentheses (
Sometimes return statement expressions are wrapped in unnecessary parentheses,
making them look like a function call.
) SingularField (
A field that's only used by one method could perhaps be replaced by a local variable
)Coupling Rules
CouplingBetweenObjects (
Rule counts unique attributes, local variables and return types within an object. An amount
higher than specified threshold can indicate a high degree of couping with in an object
) ExcessiveImports (
A high number of imports can indicate a high degree of coupling within
an object. Rule counts the number of unique imports and reports a violation
if the count is above the user defined threshold.
) LooseCoupling (
Avoid using implementation types (i.e., HashSet); use the interface (i.e, Set) instead
)Optimization Rules
LocalVariableCouldBeFinal (
A local variable assigned only once can be declared final.
) MethodArgumentCouldBeFinal (
A method argument that is never assigned can be declared final.
) AvoidInstantiatingObjectsInLoops (
Detects when a new object is created inside a loop
) UseArrayListInsteadOfVector (
ArrayList is a much better Collection implementation than Vector.
) SimplifyStartsWith (
Since it passes in a literal of length 1, this call to String.startsWith can be rewritten using String.charAt(0) to save some time.
) UseStringBufferForStringAppends (
Finds usages of += for appending strings.
)Basic Rules
EmptyCatchBlock (
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.
) EmptyIfStmt (
Empty If Statement finds instances where a condition is checked but nothing is done about it.
) EmptyWhileStmt (
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's a while loop that does a lot in the exit expression, rewrite it to make it clearer.
) EmptyTryBlock (
Avoid empty try blocks - what's the point?
) EmptyFinallyBlock (
Avoid empty finally blocks - these can be deleted.
) EmptySwitchStatements (
Avoid empty switch statements.
) JumbledIncrementer (
Avoid jumbled loop incrementers - it's usually a mistake, and it's confusing even if it's what's intended.
) ForLoopShouldBeWhileLoop (
Some for loops can be simplified to while loops - this makes them more concise.
) UnnecessaryConversionTemporary (
Avoid unnecessary temporaries when converting primitives to Strings
) OverrideBothEqualsAndHashcode (
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.
) DoubleCheckedLocking (
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. For more details see http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html.
) ReturnFromFinallyBlock (
Avoid returning from a finally block - this can discard exceptions.
) EmptySynchronizedBlock (
Avoid empty synchronized blocks - they're useless.
) UnnecessaryReturn (
Avoid unnecessary return statements
) EmptyStaticInitializer (
An empty static initializer was found.
) UnconditionalIfStatement (
Do not use "if" statements that are always true or always false.
) EmptyStatementNotInLoop (
An empty statement (aka a semicolon by itself) that is not used
as the sole body of a for loop or while loop is probably a bug. It
could also be a double semicolon, which is useless and should be
removed.
) BooleanInstantiation (
Avoid instantiating Boolean objects, instead use Boolean.TRUE or Boolean.FALSE.
) UnnecessaryFinalModifier (
When a class has the final modifier, all the methods are marked finally.
) CollapsibleIfStatements (
Sometimes two 'if' statements can be consolidated by separating their conditions with a boolean short-circuit operator.
)Design Rules
UseSingleton (
If you have a class that has nothing but static methods, consider making it a Singleton.
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.
) SimplifyBooleanReturns (
Avoid unnecessary if..then..else statements when returning a boolean
) SimplifyBooleanExpressions (
Avoid unnecessary comparisons in boolean expressions - this makes simple code seem complicated.
) SwitchStmtsShouldHaveDefault (
Switch statements should have a default label.
) AvoidDeeplyNestedIfStmts (
Deeply nested if..then statements are hard to read.
) AvoidReassigningParameters (
Reassigning values to parameters is a questionable practice. Use a temporary local variable instead.
) SwitchDensity (
A high ratio of statements to labels in a switch statement implies that the switch
statement is doing too much work. Consider moving the statements either into new
methods, or creating subclasses based on the switch variable.
) ConstructorCallsOverridableMethod (
Calling overridable methods during construction poses a risk of invoking methods on an
incompletely constructed object. This situation can be difficult to discern.
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(), there's a problem.
) AccessorClassGeneration (
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-privitization 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, though not visible to the naked eye.
) FinalFieldCouldBeStatic (
If a final field is assigned to a compile-time constant, it could be
made static, thus saving overhead in each object
) CloseConnection (
Ensure that Connection objects are always closed after use
) NonStaticInitializer (
A nonstatic 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.
) DefaultLabelNotLastInSwitchStmt (
The default label in a switch statement should be the last label, by convention.
Most programmers will expect the default label (if present) to be the last one.
) NonCaseLabelInSwitchStatement (
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.
) OptimizableToArrayCall (
A call to Collection.toArray can use the Collection's size vs an empty Array of the desired type.
) BadComparison (
Avoid equality comparisons with Double.NaN - these are
likely to be logic errors.
) EqualsNull (
Newbie programmers sometimes get the comparison concepts confused
and use equals() to compare to null.
) ConfusingTernary (
In an "if" expression with an "else" clause, avoid negation in
the test. For example, rephrase:
if (x != y) diff(); else same();
as:
if (x == y) same(); else diff();
Most "if (x != y)" cases without an "else" are often return
cases, so consistent use of this rule makes the code easier
to read. Also, this resolves trivial ordering problems, such
as "does the error case go first?" or "does the common case
go first?".
) InstantiationToGetClass (
Avoid instantiating an object just to call getClass() on it; use the .class public member instead
) IdempotentOperations (
Avoid idempotent operations - they are silly.
) SimpleDateFormatNeedsLocale (
Be sure to specify a Locale when creating a new instance of SimpleDateFormat.
) ImmutableField (
Identifies private fields whose values never change once they are initialized either in the declaration of the field or by
a constructor. This aids in converting existing classes to immutable classes.
) UseLocaleWithCaseConversions (
When doing a String.toLowerCase()/toUpperCase() call, use a Locale. This avoids
problems with certain locales, i.e. Turkish.
) AvoidProtectedFieldInFinalClass (
Do not use protected fields in final classes since they cannot be subclassed.
Clarify your intent by using private or package access modifiers instead.
) AssignmentToNonFinalStatic (
Identifies a possible unsafe usage of a static field.
) MissingStaticMethodInNonInstantiatableClass (
A class that has private constructors and does not have any static method cannot be used.
) AvoidCallingFinalize (
finalize() is called by the garbage collector on an object when garbage collection determines
that there are no more references to the object.
) AvoidSynchronizedAtMethodLevel (
Method level synchronization can backfire when new code is added to the method. Block-level
synchronization helps to ensure that only the code that needs synchronization gets it.
) MissingBreakInSwitch (
A switch statement without an enclosed break statement may be a bug.
) UseNotifyAllInsteadOfNotify (
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 it's usually safer to call notifyAll() instead.
) AvoidInstanceofChecksInCatchClause (
Each caught exception type should be handled in its own catch clause.
) AbstractClassWithoutAbstractMethod (
The abstract class does not contain any abstract methods. An abstract class suggests
an incomplete implementation, which is to be completed by subclasses implementing the
abstract methods. If the class is intended to be used as a base class only (not to be instantiated
direcly) a protected constructor can be provided prevent direct instantiation.
) SimplifyConditional (
No need to check for null before an instanceof; the instanceof keyword returns false when given a null argument.
)Security Code Guidelines
MethodReturnsInternalArray (
Exposing internal arrays directly allows the user to modify some code that could be critical.
It is safer to return a copy of the array.
) ArrayIsStoredDirectly (
Constructors and methods receiving arrays shuold clone objects and store the copy.
This prevents that future changes from the user affect the internal functionallity.
)Strict Exception Rules
AvoidCatchingThrowable (
This is dangerous because if a java.lang.Error, for example OutOfMemmoryError,
occurs then it will be caught. The container should handle java.lang.Error.
If application code will catch them, try to log them (which will probably fail)
and continue silently the situation will not be desirable.
) SignatureDeclareThrowsException (
It is unclear which exceptions that can be thrown from the methods.
It might be difficult to document and understand the vague interfaces.
Use either a class derived from RuntimeException or a checked exception.
) ExceptionTypeChecking (
At some places Exception is caught and then a check with instanceof is performed.
This result in messy code. It's considered better to catch all the specific
exceptions instead.
) ExceptionAsFlowControl (
Using Exceptions as flow control leads to GOTOish code.
) AvoidCatchingNPE (
Code should never throw NPE under normal circumstances. A catch block may hide the original error, causing other more subtle errors in its wake.
) AvoidThrowingCertainExceptionTypes (
1) Avoid throwing certain exception types. Rather than throw a raw RuntimeException, Throwable,
Exception, or Error, use a subclassed exception or error instead.
2) Avoid throwing a NullPointerException - it's confusing because most people will assume that the
VM threw NPE. Consider using InvalidArgumentException("Null parameter") which will be clearly seen as
a programmer initiated exception.. Use IllegalArgumentException or IllegalStateException instead.
)JavaBean Rules
BeanMembersShouldSerialize (
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,
marked as 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.if you have a variable foo, you should
provide getFoo and setFoo methods.
) MissingSerialVersionUID (
Classes that are serializable should provide a serialVersionUID field.
)java.lang.String Rules
AvoidDuplicateLiterals (
Code containing duplicate String literals can usually be improved by declaring the String as a constant field.
) StringInstantiation (
Avoid instantiating String objects; this is usually unnecessary.
) StringToString (
Avoid calling toString() on String objects; this is unnecessary
) AvoidConcatenatingNonLiteralsInStringBuffer (
Avoid concatenating non literals in a StringBuffer constructor or append().
)Code Size Rules
ExcessiveMethodLength (
Excessive Method Length usually means that the method is doing
too much. There is usually quite a bit of Cut and Paste there
as well. Try to reduce the method size by creating helper methods,
and removing cut and paste.
Default value is 2.5 sigma greater than the mean.
There are three parameters available:
minimum - Minimum Length before reporting.
sigma - Std Deviations away from the mean before reporting.
topscore - The Maximum Number of reports to generate.
At this time, only one can be used at a time.
) ExcessiveParameterList (
This checks to make sure that the Parameter Lists in the project aren't
getting too long. If there are long parameter lists, then that is
generally indicative that another object is hiding around there.
Basically, try to group the parameters together.
Default value is 2.5 sigma greater than the mean.
NOTE: In version 0.9 and higher, their are three parameters available:
minimum - Minimum Length before reporting.
sigma - Std Deviations away from the mean before reporting.
topscore - The Maximum Number of reports to generate.
At this time, only one can be used at a time.
) ExcessiveClassLength (
Long Class files are indications that the class may be trying to
do too much. Try to break it down, and reduce the size to something
managable.
Default value is 2.5 sigma greater than the mean.
NOTE: In version 0.9 and higher, their are three parameters available:
minimum - Minimum Length before reporting.
sigma - Std Deviations away from the mean before reporting.
topscore - The Maximum Number of reports to generate.
At this time, only one can be used at a time.
) CyclomaticComplexity (
Complexity is determined by the number of decision points in a method plus one for the
method entry. The decision points are 'if', 'while', 'for', and 'case labels'. Scale:
1-4 (low complexity) 5-7 (moderate complexity) 8-10 (high complexity) 10+ (very high complexity)
) ExcessivePublicCount (
A large amount of public methods and attributes declared in an object can indicate the class may need
to be broken up as increased effort will be required to thoroughly test such a class.
) TooManyFields (
Classes that have too many fields could be redesigned to have less fields
and some nested object grouping some of the information collected on the
many fields.
)Import Statement Rules
DuplicateImports (
Avoid duplicate import statements.
) DontImportJavaLang (
Avoid importing anything from the package 'java.lang'. These classes are automatically imported (JLS 7.5.3).
) UnusedImports (
Avoid unused import statements.
) ImportFromSamePackage (
No need to import a type that's in the same package.
)Clone Implementation Rules
ProperCloneImplementation (
Object clone() should be implemented with super.clone()
) CloneThrowsCloneNotSupportedException (
The method clone() should throw a CloneNotSupportedException
) CloneMethodMustImplementCloneable (
The method clone() should only be implemented if the class implements Cloneable interface
)Naming Rules
ShortVariable (
Detects when a field, local or parameter has a short name.
) LongVariable (
Detects when a field, formal or local variable is declared with a long name.
) ShortMethodName (
Detects when very short method names are used.
) VariableNamingConventions (
A variable naming conventions rule - customize this to your liking
Final variables should be all caps
Non-final variables should not include underscores
) MethodNamingConventions (
Method names should always begin with a lower case character, and should not contain underscores.
) ClassNamingConventions ( Class names should always begin with an upper case character.
) AbstractNaming (
Abstract classes should be named 'AbstractXXX'.
) AvoidDollarSigns (
Avoid using dollar signs in variable/method/class/interface names.
) MethodWithSameNameAsEnclosingClass (
Non-constructor methods should not have the same name as the enclosing class.
) SuspiciousHashcodeMethodName (
The method name and return type are suspiciously close to hashCode(), which
may mean you are trying (and failing) to override the hashCode() method.
) SuspiciousConstantFieldName (
A field name is all in uppercase characters, which in sun's java naming
conventions indicate a constant. However, the field is not final.
) SuspiciousEqualsMethodName (
The method name and parameter number are suspiciously close to
equals(Object), which may mean you are trying (and failing) to override the equals(Object)
method.
) AvoidFieldNameMatchingTypeName (
It is somewhat confusing to have a field name matching the declaring class name.
This proabably means that type and or field names could be more precise.
) AvoidFieldNameMatchingMethodName (
It is somewhat confusing to have a field name with the same name as a method.
While this is totally legal, having information (field) and actions (method) is
not clear naming.
) AvoidNonConstructorMethodsWithClassName (
It is very easy to confuse methods with classname with constructors. It is preferrable
to name these non-constructor methods in a different way.
)my-rules
() () () () () () () () () () () () () () ()JUnit Rules
JUnitStaticSuite (
The suite() method in a JUnit test needs to be both public and static.
) JUnitSpelling (
Some JUnit framework methods are easy to misspell.
) JUnitAssertionsShouldIncludeMessage (
JUnit assertions should include a message - i.e., use the three argument version of
assertEquals(), not the two argument version.
) JUnitTestsShouldIncludeAssert (
JUnit assertions should include an assertion - This makes the tests more robust
and assert() with messages provide the developer a clearer idea of what
the test does.
) TestClassWithoutTestCases (
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.
) UnnecessaryBooleanAssertion (
A (junit test) asserttion with a boolean literal is unnecessary, since it always will eval 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);
) UseAssertEqualsInsteadOfAssertTrue (
This rule detects JUnit assertions in object equality. These assertions
should be made by more specific methods, like assertEquals.
) UseAssertSameInsteadOfAssertTrue (
This rule detects JUnit assertions in object references equality. These assertions
should be made by more specific methods, like assertSame, assertNotSame.
)Java Logging Rules
MoreThanOneLogger (
Normally only one logger is used in each class.
) LoggerIsNotStaticFinal (
In most cases, the Logger can be declared static and final.
) SystemPrintln (
System.(out|err).print is used, consider using a logger.
)Braces Rules
IfStmtsMustUseBraces (
Avoid using if statements without using curly braces
) WhileLoopsMustUseBraces (
Avoid using 'while' statements without using curly braces
) IfElseStmtsMustUseBraces (
Avoid using if..else statements without using curly braces
) ForLoopsMustUseBraces (
Avoid using 'for' statements without using curly braces
)
