Checks for Coding problems

Checkstyle Logo

AvoidInlineConditionals

Description

Detects inline conditionals. An example inline conditional is this:

String a = getParameter("a");
String b = (a==null || a.length<1) ? null : a.substring(1);
      

Rationale: Some developers find inline conditionals hard to read, so their company's coding standards forbids them.

Examples

To configure the check:

<module name="AvoidInlineConditionals"/>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

DoubleCheckedLocking

Description

The "double-checked locking" idiom (DCL) tries to avoid the runtime cost of synchronization. An example that uses the DCL idiom is this:

public class MySingleton
{
    private static theInstance = null;

    private MySingleton() {}

    public MySingleton getInstance() {
        if ( theInstance == null ) { // synchronize only if necessary
            synchronized( MySingleton.class ) {
                if ( theInstance == null ) {
                    theInstance = new MySingleton();
                }
            }
        }
    }
}
      

The problem with the DCL idiom in Java is that it just does not work correctly. Using it introduces bugs that are extremely hard to track down and reproduce. The "Double-Checked Locking is Broken" Declaration has an in depth explanation of the exact problem which has to do with the semantics of the Java memory model.

The DoubleCheckedLocking check will find source code where a test is wrapped in a synchronized block that is wrapped in the same test, like in the example above.

Examples

To configure the check:

<module name="DoubleCheckedLocking"/>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

EmptyStatement

Description

Detects empty statements (standalone ;).

Examples

To configure the check:

<module name="EmptyStatement"/>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

EqualsHashCode

Description

Checks that classes that override equals() also override hashCode().

Rationale: The contract of equals() and hashCode() requires that equal objects have the same hashCode. Hence, whenever you override equals() you must override hashCode() to ensure that your class can be used in collections that are hash based.

Example

To configure the check:

<module name="EqualsHashCode"/>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

HiddenField

Description

Checks that a local variable or a parameter does not shadow a field that is defined in the same class.

Properties

name description type default value
tokens tokens to check subset of tokens PARAMETER_DEF, VARIABLE_DEF PARAMETER_DEF, VARIABLE_DEF

Examples

To configure the check:

<module name="HiddenField"/>
      

To configure the check so that it checks local variables but not parameters:

<module name="HiddenField">
    <property name="tokens" value="VARIABLE_DEF"/>
</module>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

IllegalInstantiation

Description

Checks for illegal instantiations where a factory method is preferred.

Rationale: Depending on the project, for some classes it might be preferable to create instances through factory methods rather than calling the constructor.

A simple example is the java.lang.Boolean class. In order to save memory and CPU cycles, it is preferable to use the predefined constants TRUE and FALSE. Constructor invocations should be replaced by calls to Boolean.valueOf().

Some extremely performance sensitive projects may require the use of factory methods for other classes as well, to enforce the usage of number caches or object pools.

Notes

There is a limitation that it is currently not possible to specify array classes.

name description type default value
classes classes that should not be instantiated String Set {}

Example

To configure the check to find instantiations of java.lang.Boolean:

<module name="IllegalInstantiation">
    <property name="classes" value="java.lang.Boolean"/>
</module>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

InnerAssignment

Description

Checks for assignments in subexpressions, such as in String s = Integer.toString(i = 2);.

Rationale: With the exception of for iterators, all assignments should occur in their own toplevel statement to increase readability. With inner assignments like the above it is difficult to see all places where a variable is set.

Properties

name description type default value
tokens assignments to check subset of tokens ASSIGN, BAND_ASSIGN, BOR_ASSIGN, BSR_ASSIGN, BXOR_ASSIGN, DIV_ASSIGN, MINUS_ASSIGN, MOD_ASSIGN, PLUS_ASSIGN, SL_ASSIGN, SR_ASSIGN, STAR_ASSIGN all tokens

Examples

To configure the check:

<module name="InnerAssignment"/>
      

To configure the check for only =, +=, and -= operators:

<module name="InnerAssignment">
    <property name="tokens" value="ASSIGN,PLUS_ASSIGN,MINUS_ASSIGN"/>
</module>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

MagicNumber

Description

Checks that there are no "magic numbers", where a magic number is a numeric literal that is not defined as a constant. By default, -1, 0, 1, and 2 are not considered to be magic numbers.

Properties

name description type default value
tokens tokens to check subset of tokens NUM_DOUBLE, NUM_FLOAT, NUM_INT, NUM_LONG all tokens
ignoreNumbers non-magic numbers list of numbers -1, 0, 1, 2

Examples

To configure the check:

<module name="MagicNumber"/>
      

To configure the check so that it checks floating-point numbers that are neither 0, 0.5, nor 1:

<module name="MagicNumber">
    <property name="tokens" value="NUM_DOUBLE, NUM_FLOAT"/>
    <property name="ignoreNumbers" value="0, 0.5, 1"/>
</module>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

MissingSwitchDefault

Description

Checks that switch statement has "default" clause.

Rationale: It's usually a good idea to introduce a default case in every switch statement. Even if the developer is sure that all currently possible cases are covered, this should be expressed in the default branch, e.g. by using an assertion. This way the code is protected aginst later changes, e.g. introduction of new types in an enumeration type.

Examples

To configure the check:

<module name="MissingSwitchDefault"/>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

RedundantThrows

Description

Checks for redundant exceptions declared in throws clause such as duplicates, unchecked exceptions or subclasses of another declared exception.

Properties

name description type default value
allowUnchecked whether unchecked exceptions in throws are allowed or not boolean false
allowSubclasses whether subclass of another declared exception is allowed in throws clause boolean false

Examples

To configure the default check:

<module name="RedundantThrows"/>
      

To configure the check to allow unchecked exception in throws clause

<module name="RedundantThrows">
    <property name="allowUnchecked" value="true"/>
</module>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

SimplifyBooleanExpression

Description

Checks for overly complicated boolean expressions. Currently finds code like if (b == true), b || true, !false, etc.

Rationale: Complex boolean logic makes code hard to understand and maintain.

Example

To configure the check:

<module name="SimplifyBooleanExpression"/>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker

SimplifyBooleanReturn

Description

Checks for overly complicated boolean return statements. For example the following code

if (valid())
    return false;
else
    return true;
      

could be written as

return !valid();
      

The Idea for this Check has been shamelessly stolen from the equivalent PMD rule.

Example

To configure the check:

<module name="SimplifyBooleanReturn"/>
      

Package

com.puppycrawl.tools.checkstyle.checks

Parent Module

TreeWalker


Back to the Checkstyle Home Page