checkstyle/src/xdocs/config_coding.xml

2559 lines
73 KiB
XML

<?xml version="1.0" encoding="ISO-8859-1"?>
<document xmlns="http://maven.apache.org/XDOC/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd">
<properties>
<title>Coding</title>
<author>Checkstyle Development Team</author>
</properties>
<body>
<section name="ArrayTrailingComma">
<subsection name="Description">
<p>
Checks that array initialization contains a trailing comma.
</p>
<source>
int[] a = new int[]
{
1,
2,
3,
};
</source>
<p>
The check allows leaving out the comma at the end if both the left and right curly brackets
are on the same line.
</p>
<source>
return new int[] { 0 };
</source>
<p>
Rationale: Putting this comma in makes it easier to change the order
of the elements or add new elements on the end.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;ArrayTrailingComma&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="AvoidInlineConditionals">
<subsection name="Description">
<p>
Detects inline conditionals. Here is one example of an inline conditional:
</p>
<source>
String a = getParameter("a");
String b = (a==null || a.length&lt;1) ? null : a.substring(1);
</source>
<p>
Rationale: Some developers find inline conditionals hard to read, so
their employer's coding standards forbid them.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;AvoidInlineConditionals&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="CovariantEquals">
<subsection name="Description">
<p>
Checks that classes that define a covariant <code>equals()</code> method also override method <code>equals(java.lang.Object)</code>. Inspired by <a
href="http://www.cs.nyu.edu/~lharris/papers/findbugsPaper.pdf">findbugs</a>.
</p>
<p>
Rationale: Mistakenly defining a covariant <code>equals()</code> method without overriding method <code>equals(java.lang.Object)</code> can produce unexpected
runtime behaviour.
</p>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;CovariantEquals&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="EmptyStatement">
<subsection name="Description">
<p>
Detects empty statements (standalone ";" semicolon).
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;EmptyStatement&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="EqualsAvoidNull">
<subsection name="Description">
<p>
Checks that any combination of String literals with optional
assignment is on the left side of an <code>equals()</code> comparison.
The check also processes <code>String.equalsIgnoreCase()</code>
invocations (which can be suppressed).
</p>
<p>
Rationale: Calling the <code>equals()</code>
method on String literals will avoid a potential
NullPointerException. Also, it is pretty common to see null
checks right before equals comparisons, which is not necessary
in the example below.
</p>
<p>
For example, this code:
</p>
<source>
String nullString = null;
nullString.equals(&quot;My_Sweet_String&quot;);
</source>
<p>should be refactored to:</p>
<source>
String nullString = null;
&quot;My_Sweet_String&quot;.equals(nullString);
</source>
<p>
Limitations: If the equals method is overridden or a covariant
equals method is defined and the implementation is incorrect
(where <code>s.equals(t)</code> does not return
the same result as <code>t.equals(s)</code>) then
rearranging the called on object and parameter may have
unexpected results.
</p>
<p>
Java's autoboxing feature affects how this check is
implemented. Before Java 5, concatenations of two objects by name would not cause a NullPointerException
even if either object is null. Those situations could have been included in this
check. They would simply act as if they were surrounded by <code>String.valueOf()</code>
which would concatenate
the String null.
</p>
<p>
The following example will cause a NullPointerException as a
result of what autoboxing does.
</p>
<source>
Integer i = null, j = null;
String number = "5"
number.equals(i + j);
</source>
<p>
Since it is difficult to determine what kind of Object is
being concatenated, all concatenations of two objects by name are considered
unsafe.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>ignoreEqualsIgnoreCase</td>
<td>whether to ignore <code>String.equalsIgnoreCase()</code> invocations</td>
<td><a href="property_types.html#boolean">boolean</a></td>
<td>false</td>
</tr>
</table>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;EqualsAvoidNull&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="EqualsHashCode">
<subsection name="Description">
<p>
Checks that classes that override <code>equals()</code>
also override <code>hashCode()</code>.
</p>
<p>
Rationale: The contract of <code>equals()</code> and
<code>hashCode()</code> requires that equal objects
have the same hashCode. Therefore, whenever you override <code>equals()</code> you must override <code>
hashCode()</code> to ensure that your class can be used in
hash-based collections.
</p>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;EqualsHashCode&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="FinalLocalVariable">
<subsection name="Description">
<p>
Checks that local variables that never have their values changed are
declared final. The check can be configured to also check that
unchanged parameters are declared final.
</p>
</subsection>
<subsection name="Notes">
<p>
When configured to check parameters, the check ignores parameters of
interface methods and abstract methods.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr class="header">
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>tokens</td>
<td>tokens to check</td>
<td>
subset of tokens <a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#PARAMETER_DEF">PARAMETER_DEF</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#VARIABLE_DEF">VARIABLE_DEF</a>
</td>
<td>
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#VARIABLE_DEF">VARIABLE_DEF</a>
</td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;FinalLocalVariable&quot;/&gt;
</source>
<p>
To configure the check so that it checks local variables and
parameters:
</p>
<source>
&lt;module name=&quot;FinalLocalVariable&quot;&gt;
&lt;property name=&quot;tokens&quot; value=&quot;VARIABLE_DEF,PARAMETER_DEF&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="HiddenField">
<subsection name="Description">
<p>
Checks that a local variable or a parameter does not shadow a field
that is defined in the same class.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>tokens</td>
<td>tokens to check</td>
<td>
subset of tokens <a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#PARAMETER_DEF">PARAMETER_DEF</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#VARIABLE_DEF">VARIABLE_DEF</a>
</td>
<td>
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#PARAMETER_DEF">PARAMETER_DEF</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#VARIABLE_DEF">VARIABLE_DEF</a>
</td>
</tr>
<tr>
<td>ignoreFormat</td>
<td>pattern for names to ignore</td>
<td><a href="property_types.html#regexp">regular expression</a></td>
<td>(not applied)</td>
</tr>
<tr>
<td>ignoreConstructorParameter</td>
<td>Controls whether to ignore constructor parameters.</td>
<td><a href="property_types.html#boolean">Boolean</a></td>
<td><code>false</code></td>
</tr>
<tr>
<td>ignoreSetter</td>
<td>
Controls whether to ignore the parameter of a property setter
method, where the property setter method for field
&quot;xyz&quot; has name &quot;setXyz&quot;, one parameter named
&quot;xyz&quot;, and return type <code>void</code>.
</td>
<td><a href="property_types.html#boolean">Boolean</a></td>
<td><code>false</code></td>
</tr>
<tr>
<td>ignoreAbstractMethods</td>
<td>Controls whether to ignore parameters of abstract methods.</td>
<td><a href="property_types.html#boolean">Boolean</a></td>
<td><code>false</code></td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;HiddenField&quot;/&gt;
</source>
<p>
To configure the check so that it checks local variables but not
parameters:
</p>
<source>
&lt;module name=&quot;HiddenField&quot;&gt;
&lt;property name=&quot;tokens&quot; value=&quot;VARIABLE_DEF&quot;/&gt;
&lt;/module&gt;
</source>
<p>
To configure the check so that it ignores the name
&quot;rcsid&quot;:
</p>
<source>
&lt;module name=&quot;HiddenField&quot;&gt;
&lt;property name=&quot;ignoreFormat&quot; value=&quot;^rcsid$&quot;/&gt;
&lt;/module&gt;
</source>
<p>
To configure the check so that it ignores constructor parameters:
</p>
<source>
&lt;module name=&quot;HiddenField&quot;&gt;
&lt;property name=&quot;ignoreConstructorParameter&quot; value=&quot;true&quot;/&gt;
&lt;/module&gt;
</source>
<p>
To configure the check so that it ignores the parameter of setter
methods:
</p>
<source>
&lt;module name=&quot;HiddenField&quot;&gt;
&lt;property name=&quot;ignoreSetter&quot; value=&quot;true&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="IllegalInstantiation">
<subsection name="Description">
<p>
Checks for illegal instantiations where a factory method is
preferred.
</p>
<p>
Rationale: Depending on the project, for some classes it might be
preferable to create instances through factory methods rather than
calling the constructor.
</p>
<p>
A simple example is the <code>java.lang.Boolean</code>
class. For performance reasons, it is preferable to
use the predefined constants <code> TRUE</code> and
<code>FALSE</code>. Constructor invocations should be
replaced by calls to <code>Boolean.valueOf()</code>.
</p>
<p>
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.
</p>
</subsection>
<subsection name="Notes">
<p>
There is a limitation that it is currently not possible to specify
array classes.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>classes</td>
<td>classes that should not be instantiated</td>
<td><a href="property_types.html#stringSet">String Set</a></td>
<td>{}</td>
</tr>
</table>
</subsection>
<subsection name="Example">
<p>
To configure the check to find instantiations of java.lang.Boolean:
</p>
<source>
&lt;module name=&quot;IllegalInstantiation&quot;&gt;
&lt;property name=&quot;classes&quot; value=&quot;java.lang.Boolean&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="IllegalToken">
<subsection name="Description">
<p>
Checks for illegal tokens.
</p>
<p>
Rational: Certain language features often lead to hard-to-maintain
code or are not obvious to novice developers. Other features may be
discouraged in certain frameworks, such as not having native methods
in Enterprise JavaBeans components.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>tokens</td>
<td>tokens to check</td>
<td>
subset of <a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html">TokenTypes</a>,
</td>
<td>
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#LITERAL_SWITCH">LITERAL_SWITCH</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#POST_INC">POST_INC</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#POST_DEC">POST_DEC</a>
</td>
</tr>
</table>
</subsection>
<subsection name="Example">
<p>
To configure the check to find token LITERAL_NATIVE:
</p>
<source>
&lt;module name=&quot;IllegalToken&quot;&gt;
&lt;property name=&quot;tokens&quot; value=&quot;LITERAL_NATIVE&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="IllegalTokenText">
<subsection name="Description">
<p>
Checks for illegal token text.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>tokens</td>
<td>tokens to check</td>
<td>subset of <a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html">TokenTypes</a>
</td>
<td>empty</td>
</tr>
<tr>
<td>format</td>
<td>illegal pattern</td>
<td><a href="property_types.html#regexp">regular expression</a></td>
<td><code>^$</code> (empty)</td>
</tr>
<tr>
<td>ignoreCase</td>
<td>Controls whether to ignore case when matching.</td>
<td><a href="property_types.html#boolean">Boolean</a></td>
<td><code>false</code></td>
</tr>
<tr>
<td>message</td>
<td>Message which is used to notify about violations;
if empty then the default message is used.</td>
<td><a href="property_types.html#string">String</a></td>
<td><code>&quot;&quot;</code>(empty)</td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check to forbid String literals containing <code>&quot;a href&quot;</code>:
</p>
<source>
&lt;module name=&quot;IllegalTokenText&quot;&gt;
&lt;property name=&quot;tokens&quot; value=&quot;STRING_LITERAL&quot;/&gt;
&lt;property name=&quot;format&quot; value=&quot;a href&quot;/&gt;
&lt;/module&gt;
</source>
<p>
To configure the check to forbid leading zeros in an integer
literal, other than zero and a hex literal:
</p>
<source>
&lt;module name=&quot;IllegalTokenText&quot;&gt;
&lt;property name=&quot;tokens&quot; value=&quot;NUM_INT,NUM_LONG&quot;/&gt;
&lt;property name=&quot;format&quot; value=&quot;^0[^lx]&quot;/&gt;
&lt;property name=&quot;ignoreCase&quot; value=&quot;true&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="InnerAssignment">
<subsection name="Description">
<p>
Checks for assignments in subexpressions, such as in <code>String s = Integer.toString(i = 2);</code>.
</p>
<p>
Rationale: With the exception of <code>for</code>
iterators, all assignments should occur in their own top-level
statement to increase readability. With inner assignments like the
one given above, it is difficult to see all places where a variable is set.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>tokens</td>
<td>assignments to check</td>
<td>subset of tokens <a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#ASSIGN">ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#BAND_ASSIGN">BAND_ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#BOR_ASSIGN">BOR_ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#BSR_ASSIGN">BSR_ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#BXOR_ASSIGN">BXOR_ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#DIV_ASSIGN">DIV_ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#MINUS_ASSIGN">MINUS_ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#MOD_ASSIGN">MOD_ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#PLUS_ASSIGN">PLUS_ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#SL_ASSIGN">SL_ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#SR_ASSIGN">SR_ASSIGN</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#STAR_ASSIGN">STAR_ASSIGN</a></td>
<td>all tokens</td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;InnerAssignment&quot;/&gt;
</source>
<p>
To configure the check for only <code>=</code>, <code> +=</code>, and <code>-=</code> operators:
</p>
<source>
&lt;module name=&quot;InnerAssignment&quot;&gt;
&lt;property name=&quot;tokens&quot; value=&quot;ASSIGN,PLUS_ASSIGN,MINUS_ASSIGN&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="MagicNumber">
<subsection name="Description">
<p>
Checks that there are no &quot;magic numbers&quot;, 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.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>tokens</td>
<td>tokens to check</td>
<td>subset of tokens NUM_DOUBLE, NUM_FLOAT, NUM_INT, NUM_LONG</td>
<td>all tokens</td>
</tr>
<tr>
<td>ignoreNumbers</td>
<td>non-magic numbers</td>
<td>list of numbers</td>
<td>-1, 0, 1, 2</td>
</tr>
<tr>
<td>ignoreHashCodeMethod</td>
<td>ignore magic numbers in hashCode methods</td>
<td><a href="property_types.html#boolean">boolean</a></td>
<td><span class="default">false</span></td>
</tr>
<tr>
<td>ignoreAnnotation</td>
<td>ignore magic numbers in annotation declarations.</td>
<td><a href="property_types.html#boolean">boolean</a></td>
<td><span class="default">false</span></td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;MagicNumber&quot;/&gt;
</source>
<p>
To configure the check so that it checks floating-point numbers
that are not 0, 0.5, or 1:
</p>
<source>
&lt;module name=&quot;MagicNumber&quot;&gt;
&lt;property name=&quot;tokens&quot; value=&quot;NUM_DOUBLE, NUM_FLOAT&quot;/&gt;
&lt;property name=&quot;ignoreNumbers&quot; value=&quot;0, 0.5, 1&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="MissingSwitchDefault">
<subsection name="Description">
<p>
Checks that switch statement has a &quot;default&quot; clause.
</p>
<p>
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 against later changes, e.g. introduction of new types in an
enumeration type.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;MissingSwitchDefault&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="ModifiedControlVariable">
<subsection name="Description">
<p>
Check for ensuring that for loop control variables are not
modified inside the for block. An example is:
</p>
<source>
for (int i = 0; i &lt; 1; i++) {
i++;
}
</source>
<p>
Rationale: If the control variable is modified inside the loop
body, the program flow becomes more difficult to follow. An option
is to replace the for loop with a while loop.
</p>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;ModifiedControlVariable&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="SimplifyBooleanExpression">
<subsection name="Description">
<p>
Checks for over-complicated boolean expressions. Currently finds
code like <code> if (b == true)</code>, <code>b || true</code>, <code>!false</code>,
etc.
</p>
<p>
Rationale: Complex boolean logic makes code hard to understand and
maintain.
</p>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;SimplifyBooleanExpression&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="SimplifyBooleanReturn">
<subsection name="Description">
<p>
Checks for over-complicated boolean return statements. For example
the following code
</p>
<source>
if (valid())
return false;
else
return true;
</source>
<p>
could be written as
</p>
<source>
return !valid();
</source>
<p>
The idea for this Check has been shamelessly stolen from the
equivalent <a href="http://pmd.sourceforge.net">PMD</a> rule.
</p>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;SimplifyBooleanReturn&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="StringLiteralEquality">
<subsection name="Description">
<p>
Checks that string literals are not used with <code>==</code> or
<code>&#33;=</code>.
</p>
<p>
Rationale: Novice Java programmers often use code like:
</p>
<source>
if (x == &quot;something&quot;)
</source>
<p>when they mean</p>
<source>
if (&quot;something&quot;.equals(x))
</source>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;StringLiteralEquality&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="NestedForDepth">
<subsection name="Description">
<p>
Restricts nested <code>for</code> blocks to a specified depth
(default = 1).
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>max</td>
<td>allowed nesting depth</td>
<td><a href="property_types.html#integer">Integer</a></td>
<td><span class="default">1</span></td>
</tr>
</table>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;NestedForDepth&quot;/&gt;
</source>
<p>
To configure the check to allow nesting depth 3:
</p>
<source>
&lt;module name=&quot;NestedForDepth&quot;&gt;
&lt;property name=&quot;max&quot; value=&quot;3&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="NestedIfDepth">
<subsection name="Description">
<p>
Restricts nested if-else blocks to a specified depth (default = 1).
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>max</td>
<td>allowed nesting depth</td>
<td><a href="property_types.html#integer">Integer</a></td>
<td><code>1</code></td>
</tr>
</table>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;NestedIfDepth&quot;/&gt;
</source>
<p>
To configure the check to allow nesting depth 3:
</p>
<source>
&lt;module name=&quot;NestedIfDepth&quot;&gt;
&lt;property name=&quot;max&quot; value=&quot;3&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="NestedTryDepth">
<subsection name="Description">
<p>
Restricts nested try blocks to a specified depth (default = 1).
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>max</td>
<td>allowed nesting depth</td>
<td><a href="property_types.html#integer">Integer</a></td>
<td><code>1</code></td>
</tr>
</table>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;NestedTryDepth&quot;/&gt;
</source>
<p>
To configure the check to allow nesting depth 3:
</p>
<source>
&lt;module name=&quot;NestedTryDepth&quot;&gt;
&lt;property name=&quot;max&quot; value=&quot;3&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="NoClone">
<subsection name="Description">
<p>
Checks that the clone method is not overridden from the
Object class.
</p>
<p>
Rationale: The clone method relies on strange, hard to follow rules that
are difficult to get right and do not work in all situations.
In some cases, either a copy constructor
or a static factory method can be used instead of the clone method
to return copies of an object.
For more information on rules for the clone method and its issues, see Effective Java:
Programming Language Guide First Edition by Joshua Bloch
pages 45-52.
</p>
<p>
This check is almost exactly the same as the {@link NoFinalizerCheck}
</p>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;NoClone&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="NoFinalizer">
<subsection name="Description">
<p>
Verifies there are no <code>finalize()</code> methods
defined in a class.
</p>
</subsection>
<subsection name="Example">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;NoFinalizer&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="SuperClone">
<subsection name="Description">
<p>
Checks that an overriding <code>clone()</code> method
invokes <code>super.clone()</code>.
</p>
<p>
Reference: <a
href="https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#clone%28%29">Object.clone()</a>.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;SuperClone&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="SuperFinalize">
<subsection name="Description">
<p>
Checks that an overriding <code>finalize()</code>
method invokes <code>super.finalize()</code>.
</p>
<p>
Reference: <a
href="http://www.oracle.com/technetwork/java/javamail/finalization-137655.html">
Use Finalization Only When You Must</a>.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;SuperFinalize&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="IllegalCatch">
<subsection name="Description">
<p>
Checks that certain exception types do not appear in a <code>catch</code> statement.
</p>
<p>
Rationale:
Catching java.lang.Exception, java.lang.Error or
java.lang.RuntimeException is almost never acceptable.
Novice developers often simply catch Exception in an
attempt to handle multiple exception classes. This unfortunately
leads to code that inadvertently catches NullPointerException, OutOfMemoryError, etc.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>illegalClassNames</td>
<td>exception class names to reject</td>
<td><a href="property_types.html#stringSet">list of strings</a></td>
<td><code>&quot;java.lang.Exception,
java.lang.Throwable, java.lang.RuntimeException&quot;</code></td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;IllegalCatch&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="IllegalThrows">
<subsection name="Description">
<p>
This check can be used to ensure that types are not declared
to be thrown. Declaring that a method throws java.lang.Error or
java.lang.RuntimeException is almost never acceptable.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>illegalClassNames</td>
<td>throw class names to reject</td>
<td><a href="property_types.html#stringSet">list of strings</a></td>
<td>
<code>&quot;java.lang.Throwable,
java.lang.Error, java.lang.RuntimeException&quot;</code>
</td>
</tr>
<tr>
<td>ignoredMethodNames</td>
<td>names of methods to ignore</td>
<td><a href="property_types.html#stringSet">list of strings</a></td>
<td><code>finalize</code></td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;IllegalThrows&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="PackageDeclaration">
<subsection name="Description">
<p>
Ensures that a class has a package declaration, and (optionally) whether
the package name matches the directory name for the source file.
</p>
<p>
Rationale: Classes that live in the null package cannot be
imported. Many novice developers are not aware of this.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;PackageDeclaration&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="ReturnCount">
<subsection name="Description">
<p>
Restricts the number of return statements (2 by default). Ignores
specified methods (<code>equals()</code> by default).
</p>
<p>
Rationale: Too many return points can mean that code is
attempting to do too much or may be difficult to understand.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>max</td>
<td>maximum allowed number of return statements</td>
<td><a href="property_types.html#integer">Integer</a></td>
<td><code>2</code></td>
</tr>
<tr>
<td>format</td>
<td>method names to ignore</td>
<td><a href="property_types.html#regexp">regular expression</a></td>
<td><code>^equals$</code> (empty)</td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check so that it doesn't allow more than three
return statements per method (ignoring the <code>equals()</code>
method):
</p>
<source>
&lt;module name=&quot;ReturnCount&quot;&gt;
&lt;property name=&quot;max&quot; value=&quot;3&quot;/&gt;
&lt;/module&gt;
</source>
<p>
To configure the check so that it doesn't allow more than three
return statements per method for all methods:
</p>
<source>
&lt;module name=&quot;ReturnCount&quot;&gt;
&lt;property name=&quot;max&quot; value=&quot;3&quot;/&gt;
&lt;property name=&quot;format&quot; value=&quot;^$&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="IllegalType">
<subsection name="Description">
<p>
Checks that particular classes are never used as types in variable
declarations, return values or parameters. Includes a pattern check
that by default disallows abstract classes.
</p>
<p>
Rationale: Helps reduce coupling on concrete classes. In addition
abstract classes should be thought of as convenient base class
implementations of interfaces, and as such, are not types themselves.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>tokens</td>
<td>tokens to check</td>
<td>
subset of tokens <a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#PARAMETER_DEF">PARAMETER_DEF</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#VARIABLE_DEF">VARIABLE_DEF</a>
<a href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#METHOD_DEF">METHOD_DEF</a>
</td>
<td>
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#PARAMETER_DEF">PARAMETER_DEF</a>,
<a
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#VARIABLE_DEF">VARIABLE_DEF</a>
<a href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#METHOD_DEF">METHOD_DEF</a>
</td>
</tr>
<tr>
<td>illegalClassNames</td>
<td>Classes that should not be used as types in variable
declarations, return values or parameters</td>
<td><a href="property_types.html#stringSet">String Set</a></td>
<td>&quot;java.util.GregorianCalendar, java.util.Hashtable,
java.util.HashSet, java.util.HashMap, java.util.ArrayList,
java.util.LinkedList, java.util.LinkedHashMap,
java.util.LinkedHashSet, java.util.TreeSet,
java.util.TreeMap, java.util.Vector&quot;</td>
</tr>
<tr>
<td>legalAbstractClassNames</td>
<td>Abstract classes that may be used as types. </td>
<td><a href="property_types.html#stringSet">String Set</a></td>
<td></td>
</tr>
<tr>
<td>ignoredMethodNames</td>
<td>Methods that should not be checked.</td>
<td><a href="property_types.html#stringSet">String Set</a></td>
<td>&quot;getInitialContext, getEnvironment&quot; </td>
</tr>
<tr>
<td>format</td>
<td>Pattern for illegal class names.</td>
<td><a href="property_types.html#regexp">regular expression</a></td>
<td><code>^(.*[\\.])?Abstract.*$</code></td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check so that it ignores getInstance() methods:
</p>
<source>
&lt;module name=&quot;IllegalType&quot;&gt;
&lt;property name=&quot;ignoredMethodNames&quot; value=&quot;getInstance&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="DeclarationOrder">
<subsection name="Description">
<p>
According to <a
href="http://java.sun.com/docs/codeconv/html/CodeConventions.doc2.html#1852">
Code Conventions for the Java Programming Language</a> , the parts
of a class or interface declaration should appear in the following
order:
</p>
<ol>
<li>
Class (static) variables. First the public class variables, then
protected, then package level (no access modifier), and then
private.
</li>
<li>
Instance variables. First the public class variables, then
protected, then package level (no access modifier), and then
private.
</li>
<li> Constructors </li>
<li> Methods </li>
</ol>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>ignoreConstructors</td>
<td>whether to ignore constructors</td>
<td><a href="property_types.html#boolean">Boolean</a></td>
<td><code>false</code></td>
</tr>
<tr>
<td>ignoreMethods</td>
<td>whether to ignore methods</td>
<td><a href="property_types.html#boolean">Boolean</a></td>
<td><code>false</code></td>
</tr>
<tr>
<td>ignoreModifiers</td>
<td>whether to ignore modifiers</td>
<td><a href="property_types.html#boolean">Boolean</a></td>
<td><code>false</code></td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;DeclarationOrder&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="ParameterAssignment">
<subsection name="Description">
<p> Disallows assignment of parameters.</p>
<p>
Rationale: Parameter assignment is often considered poor programming
practice. Forcing developers to declare parameters as final is often
onerous. Having a check ensure that parameters are never assigned
would give the best of both worlds.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;ParameterAssignment&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="ExplicitInitialization">
<subsection name="Description">
<p>
Checks if any class or object member is explicitly initialized to
default for its type value (<code>null</code> for
object references, zero for numeric types and <code>char</code> and <code>false</code> for
<code>boolean</code>.
</p>
<p>
Rationale: Each instance variable gets initialized twice, to the
same value. Java initializes each instance variable to its default
value (0 or null) before performing any initialization specified in
the code. So in this case, x gets initialized to 0 twice, and bar
gets initialized to null twice. So there is a minor inefficiency.
This style of coding is a holdover from C/C++ style coding, and it
shows that the developer isn't really confident that Java
initializes instance variables to default values.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;ExplicitInitialization&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="DefaultComesLast">
<subsection name="Description">
<p>
Check that the <code>default</code> is after all the
<code>case</code>s in a <code>switch</code> statement.
</p>
<p>
Rationale: Java allows <code>default</code> anywhere
within the <code>switch</code> statement. But it is
more readable if it comes after the last <code>case</code>.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;DefaultComesLast&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="MissingCtor">
<subsection name="Description">
<p>
Checks that classes (except abstract ones) define a constructor and don't
rely on the default one.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;MissingCtor&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="FallThrough">
<subsection name="Description">
<p>
Checks for fall-through in <code>switch</code>
statements. Finds locations where a <code>case</code>
contains Java code but lacks a <code>break</code>, <code>return</code>,
<code>throw</code> or <code>continue</code>
statement.
</p>
<p>
The check honors special comments to suppress the warning. By
default the text "fallthru", "fall through", "fallthrough",
"falls through" and "fallsthrough" are recognized (case
sensitive). The comment containing these words must be all on one line, and must
be on the last non-empty line before the
<code>case</code> triggering the warning or on
the same line before the <code>case</code>
(ugly, but possible).
</p>
<source>
switch (i){
case 0:
i++; // fall through
case 1:
i++;
// falls through
case 2: {
i++;
}
// fallthrough
case 3:
i++;
/* fallthru */case 4:
i++
break;
}
</source>
<p>
Note: The check assumes that there is no unreachable
code in the <code>case</code>.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>checkLastCaseGroup</td>
<td>
Whether the last case group must be checked.
</td>
<td><a href="property_types.html#boolean">Boolean</a></td>
<td><code>false</code></td>
</tr>
<tr>
<td>reliefPattern</td>
<td>
Regular expression to match the relief comment that suppresses
the warning about a fall through.
</td>
<td><a href="property_types.html#regexp">regular expression</a></td>
<td><code>fallthru|falls? ?through</code></td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;FallThrough&quot;/&gt;
</source>
<p>
or
</p>
<source>
&lt;module name=&quot;FallThrough&quot;&gt;
&lt;property name=&quot;reliefPattern&quot; value=&quot;continue in next case&quot;/&gt;
&lt;module name=&quot;FallThrough&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="MultipleStringLiterals">
<subsection name="Description">
<p>
Checks for multiple occurrences of the same string literal within a
single file.
</p>
<p>
Rationale: Code duplication makes maintenance more difficult, so it
can be better to replace the multiple occurrences with a constant.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>allowedDuplicates</td>
<td>
The maximum number of occurrences to allow without generating a
warning
</td>
<td><a href="property_types.html#integer">Integer</a></td>
<td>1</td>
</tr>
<tr>
<td>ignoreStringsRegexp</td>
<td>
Regular expression pattern for ignored strings (with quotation marks)
</td>
<td><a href="property_types.html#regexp">regular expression</a></td>
<td><code>^""$</code> (ignore empty strings)</td>
</tr>
<tr>
<td>ignoreOccurrenceContext</td>
<td>
Token type names where duplicate strings are ignored even if they don't match
ignoredStringsRegexp. This allows you to exclude syntactical contexts like
annotations or static initializers from the check.
</td>
<td>
<a href="property_types.html#stringSet">list</a> of
<a href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html">token type</a>
names
</td>
<td>
<code>ANNOTATION</code>
(ignore strings inside the context of an annotation)
</td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;MultipleStringLiterals&quot;/&gt;
</source>
<p>
To configure the check so that it allows two occurrences of each
string:
</p>
<source>
&lt;module name=&quot;MultipleStringLiterals&quot;&gt;
&lt;property name=&quot;allowedDuplicates&quot; value=&quot;2&quot;/&gt;
&lt;/module&gt;
</source>
<p>
To configure the check so that it ignores ", " and empty strings:
</p>
<source>
&lt;module name=&quot;MultipleStringLiterals&quot;&gt;
&lt;property name=&quot;ignoreStringsRegexp&quot; value='^((&quot;&quot;)|(&quot;, &quot;))$'/&gt;
&lt;/module&gt;
</source>
<p>
To configure the check so that it flags duplicate strings in all
syntactical contexts, even in annotations like
<code>@SuppressWarnings("unchecked")</code>:
</p>
<source>
&lt;module name=&quot;MultipleStringLiterals&quot;&gt;
&lt;property name=&quot;ignoreOccurrenceContext&quot; value=&quot;&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="MultipleVariableDeclarations">
<subsection name="Description">
<p>
Checks that each variable declaration is in its own statement and on
its own line.
</p>
<p>
Rationale: <a
href="http://java.sun.com/docs/codeconv/html/CodeConventions.doc5.html#2991">
the Java code conventions chapter 6.1</a> recommends that
declarations should be one per line/statement.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;MultipleVariableDeclarations&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="RequireThis">
<subsection name="Description">
<p>
Checks that references to instance variables and methods of the present
object are explicitly of the form &quot;this.varName&quot; or
&quot;this.methodName(args)&quot; and that those references don't
rely on the default behavior when &quot;this.&quot; is absent.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>checkFields</td>
<td>Whether to check references to fields.</td>
<td><a href="property_types.html#boolean">boolean</a></td>
<td><code>true</code></td>
</tr>
<tr>
<td>checkMethods</td>
<td>Whether to check references to methods.</td>
<td><a href="property_types.html#boolean">boolean</a></td>
<td><code>true</code></td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
To configure the default check:
</p>
<source>
&lt;module name=&quot;RequireThis&quot;/&gt;
</source>
<p>
To configure to check the <code>this</code> qualifier for fields only:
</p>
<source>
&lt;module name="RequireThis"&gt;
&lt;property name=&quot;checkMethods&quot; value=&quot;false&quot;/&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="UnnecessaryParentheses">
<subsection name="Description">
<p>
Checks for the use of unnecessary parentheses.
</p>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;UnnecessaryParentheses&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="OneStatementPerLine">
<subsection name="Description">
<p>
Checks that there is only one statement per line. The following line
will be flagged as an error:
</p>
<source> x = 1; y = 2; // Two statements on a single line.</source>
</subsection>
<subsection name="Examples">
<p>
To configure the check:
</p>
<source>
&lt;module name=&quot;OneStatementPerLine&quot;/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="VariableDeclarationUsageDistance">
<subsection name="Description">
<p>
Checks the distance between declaration of variable and its first usage.
</p>
</subsection>
<subsection name="Properties">
<table>
<tr>
<th>name</th>
<th>description</th>
<th>type</th>
<th>default value</th>
</tr>
<tr>
<td>allowedDistance</td>
<td>A distance between declaration of variable and its first usage</td>
<td><a href="property_types.html#integer">integer</a></td>
<td>3</td>
</tr>
<tr>
<td>ignoreVariablePattern</td>
<td>pattern for ignoring the distance calculation</td>
<td><a href="property_types.html#regexp">regular expression</a></td>
<td>(not applied)</td>
</tr>
<tr>
<td>validateBetweenScopes</td>
<td>Allows to calculate the distance between declaration of variable and its first usage in the different scopes.</td>
<td><a href="property_types.html#boolean">Boolean</a></td>
<td><code>false</code></td>
</tr>
<tr>
<td>ignoreFinal</td>
<td>Allows to ignore variables with a 'final' modifier.</td>
<td><a href="property_types.html#boolean">Boolean</a></td>
<td><code>true</code></td>
</tr>
</table>
</subsection>
<subsection name="Examples">
<p>
Example #1:
</p>
<source>
int count;
a = a + b;
b = a + a;
count = b; // DECLARATION OF VARIABLE 'count'
// SHOULD BE HERE (distance = 3)
</source>
<p>
Example #2:
</p>
<source>
int count;
{
a = a + b;
count = b; // DECLARATION OF VARIABLE 'count'
// SHOULD BE HERE (distance = 2)
}
</source>
<p>
Check can detect a block of initialization methods. If a variable is used in
such a block and there is no other statements after this variable then distance=1.
</p>
<p>
Case #1:
</p>
<source>
int minutes = 5;
Calendar cal = Calendar.getInstance();
cal.setTimeInMillis(timeNow);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
cal.set(Calendar.HOUR_OF_DAY, hh);
cal.set(Calendar.MINUTE, minutes);
</source>
<p>
The distance for the variable minutes is 1 even
though this variable is used in the fifth method's call.
</p>
<p>
Case #2:
</p>
<source>
int minutes = 5;
Calendar cal = Calendar.getInstance();
cal.setTimeInMillis(timeNow);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
System.out.println(cal);
cal.set(Calendar.HOUR_OF_DAY, hh);
cal.set(Calendar.MINUTE, minutes);
</source>
<p>
The distance for the variable minutes is 6 because there is one more expression
(except the initialization block) between the declaration of this variable and its usage.
</p>
<p>
An example how to configure this Check:
</p>
<source>
&lt;module name="VariableDeclarationUsageDistance"/&gt;
</source>
<p>
An example of how to configure this Check:
- to set the allowed distance to 4;
- to ignore variables with prefix '^temp';
- to force the validation between scopes;
- to check the final variables;
</p>
<source>
&lt;module name="VariableDeclarationUsageDistance"&gt;
&lt;property name="allowedDistance" value="4"&gt;
&lt;property name="ignoreVariablePattern" value="^temp.*"&gt;
&lt;property name="validateBetweenScopes" value="true"&gt;
&lt;property name="mIgnoreFinal" value="false"&gt;
&lt;/module&gt;
</source>
</subsection>
<subsection name="Note">
<p>
ATTENTION!! (Not supported cases)
</p>
<source>
Case #1:
{
int c;
int a = 3;
int b = 2;
{
a = a + b;
c = b;
}
}
</source>
<p>
Distance for variable 'a' = 1;
Distance for variable 'b' = 1;
Distance for variable 'c' = 2.
</p>
<p>
As distance by default is 1 the Check doesn't raise warning for
variables 'a' and 'b' to move them into the block.
</p>
<p>
Case #2:
</p>
<source>
int sum = 0;
for (int i = 0; i &lt; 20; i++) {
a++;
b--;
sum++;
if (sum > 10) {
res = true;
}
}
</source>
<p>
Distance for variable 'sum' = 3.
</p>
<p>
As the distance is more then the default one, the Check
raises warning for variable 'sum' to move it into the 'for(...)' block.
But there is situation when variable 'sum' hasn't to be 0 within each iteration.
So, to avoid such warnings you can use Suppression Filter, provided by
Checkstyle, for the whole class.
</p>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
<section name="OverloadMethodsDeclarationOrder">
<subsection name="Description">
<p>
Checks that overload methods are grouped together.
</p>
</subsection>
<subsection name="Examples">
<p>
Example of incorrect grouping overload methods:
</p>
<source>
public void foo(int i) {}
public void foo(String s) {}
public void notFoo() {} // Have to be after foo(int i, String s)
public void foo(int i, String s) {}
</source>
<p>
An example of how to configure the check is:
</p>
<source>
&lt;module name="OverloadMethodsDeclarationOrder"/&gt;
</source>
</subsection>
<subsection name="Package">
<p>
com.puppycrawl.tools.checkstyle.checks.coding
</p>
</subsection>
<subsection name="Parent Module">
<p>
<a href="config.html#TreeWalker">TreeWalker</a>
</p>
</subsection>
</section>
</body>
</document>