1745 lines
58 KiB
XML
Executable File
1745 lines
58 KiB
XML
Executable File
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
<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>Miscellaneous</title>
|
|
<author>Checkstyle Development Team</author>
|
|
</properties>
|
|
|
|
<body>
|
|
<section name="NewlineAtEndOfFile">
|
|
<subsection name="Description">
|
|
<p>
|
|
Checks whether files end with a line separator.
|
|
</p>
|
|
|
|
<p>
|
|
Rationale: Any source files and text files in general should
|
|
end with a line separator, especially when using source control management
|
|
systems such as CVS. CVS will even print a warning when it
|
|
encounters a file that doesn't end with a line separator.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>lineSeparator</td>
|
|
<td>type of line separator</td>
|
|
<td>
|
|
One of "system" (system default),
|
|
"crlf" (Windows-style), "cr"
|
|
(Mac-style) and "lf" (Unix-style)
|
|
</td>
|
|
<td>"system"</td>
|
|
</tr>
|
|
<tr>
|
|
<td>fileExtensions</td>
|
|
<td>file type extension of the files to check.</td>
|
|
<td><a href="property_types.html#stringSet">String Set</a></td>
|
|
<td>all files</td>
|
|
</tr>
|
|
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
To configure the check:
|
|
</p>
|
|
<source>
|
|
<module name="NewlineAtEndOfFile"/>
|
|
</source>
|
|
|
|
<p>
|
|
To configure the check to always use Unix-style line separators:
|
|
</p>
|
|
<source>
|
|
<module name="NewlineAtEndOfFile">
|
|
<property name="lineSeparator" value="lf"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>
|
|
To configure the check to work only on Java, XML and Python files:
|
|
</p>
|
|
<source>
|
|
<module name="NewlineAtEndOfFile">
|
|
<property name="fileExtensions" value="java, xml, py"/>
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#Checker">Checker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="TodoComment">
|
|
<subsection name="Description">
|
|
<p>
|
|
A check for <code>TODO:</code> comments. Actually
|
|
it is a generic <a
|
|
href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular
|
|
expression</a> matcher on Java comments. To check for other
|
|
patterns in Java comments, set the <code>format</code> property.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>format</td>
|
|
<td>Pattern to match comments against</td>
|
|
<td><a href="property_types.html#regexp">regular expression</a></td>
|
|
<td><code>TODO:</code></td>
|
|
</tr>
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Notes">
|
|
<p>
|
|
Using <code>TODO:</code> comments is a great way
|
|
to keep track of tasks that need to be done. Having them
|
|
reported by Checkstyle makes it very hard to forget about
|
|
them.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
To configure the check:
|
|
</p>
|
|
<source>
|
|
<module name="TodoComment"/>
|
|
</source>
|
|
|
|
<p>
|
|
To configure the check for comments that contain <code>WARNING</code>:
|
|
</p>
|
|
<source>
|
|
<module name="TodoComment">
|
|
<property name="format" value="WARNING"/>
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="Translation">
|
|
<subsection name="Description">
|
|
<p>
|
|
A <a href="config.html#Overview">FileSetCheck</a> that ensures
|
|
the correct translation of code by checking property files for
|
|
consistency regarding their keys. Two property files
|
|
describing one and the same context are consistent if they
|
|
contain the same keys.
|
|
</p>
|
|
|
|
<p>
|
|
Consider the following properties file in the same directory:
|
|
</p>
|
|
<source>
|
|
#messages.properties
|
|
hello=Hello
|
|
cancel=Cancel
|
|
|
|
#messages_de.properties
|
|
hell=Hallo
|
|
ok=OK
|
|
</source>
|
|
|
|
<p>
|
|
The Translation check will find the typo in the German <code>hello</code>
|
|
key, the missing <code>ok</code> key in the default resource file and the
|
|
missing <code>cancel</code> key in the German resource file:
|
|
</p>
|
|
<source>
|
|
messages_de.properties: Key 'hello' missing.
|
|
messages_de.properties: Key 'cancel' missing.
|
|
messages.properties: Key 'hell' missing.
|
|
messages.properties: Key 'ok' missing.
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>fileExtensions</td>
|
|
<td>
|
|
file type extension to identify translation files. Setting
|
|
this property is typically only required if your
|
|
translation files are preprocessed and the original files
|
|
do not have the extension <code>.properties</code>
|
|
</td>
|
|
<td><a href="property_types.html#stringSet">String Set</a></td>
|
|
<td><code>properties</code></td>
|
|
</tr>
|
|
<tr>
|
|
<td>basenameSeparator</td>
|
|
<td>Allows setting file names separator</td>
|
|
<td><a href="property_types.html#string">String</a></td>
|
|
<td><code>_</code></td>
|
|
</tr>
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Example">
|
|
<p>
|
|
To configure the check for files with '_' name separator:
|
|
</p>
|
|
<source>
|
|
<module name="Translation"/>
|
|
</source>
|
|
|
|
<p>
|
|
To configure the check for files with user-set name separator:
|
|
</p>
|
|
<source>
|
|
<module name="Translation">
|
|
<property name="basenameSeparator" value="STRING_LITERAL"/>
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#Checker">Checker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="UncommentedMain">
|
|
<subsection name="Description">
|
|
<p>
|
|
Checks for uncommented main() methods.
|
|
</p>
|
|
|
|
<p>
|
|
Rationale: A main() method is often used for debugging
|
|
purposes. When debugging is finished, developers often forget
|
|
to remove the method, which changes the API and increases the
|
|
size of the resulting class or JAR file. With the exception of
|
|
the real program entry points, all main() methods should be
|
|
removed or commented out of the sources.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>excludedClasses</td>
|
|
<td>Pattern for qualified names of classes which are allowed
|
|
to have a main method.</td>
|
|
<td><a href="property_types.html#regexp">regular expression</a></td>
|
|
<td><code>^$</code></td>
|
|
</tr>
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
To configure the check:
|
|
</p>
|
|
<source>
|
|
<module name="UncommentedMain"/>
|
|
</source>
|
|
|
|
<p>
|
|
To configure the check to allow the <code>main</code> method for all classes
|
|
with "Main" name:
|
|
</p>
|
|
<source>
|
|
<module name="UncommentedMain">
|
|
<property name="excludedClasses" value="\.Main$"/>
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="UpperEll">
|
|
<subsection name="Description">
|
|
<p>
|
|
Checks that long constants are defined with an upper ell. That
|
|
is <code>' L'</code> and not <code>'l'</code>. This is in accordance with the Java
|
|
Language Specification, <a
|
|
href="http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#48282">
|
|
Section 3.10.1</a>.
|
|
</p>
|
|
|
|
<p>
|
|
The capital L looks a lot like <code>1</code>.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
To configure the check:
|
|
</p>
|
|
<source>
|
|
<module name="UpperEll"/>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="ArrayTypeStyle">
|
|
<subsection name="Description">
|
|
<p>
|
|
Checks the style of array type definitions. Some like Java style:
|
|
<code>public static void main(String[] args)</code> and some like
|
|
C style: public static void main(String args[])
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>javaStyle</td>
|
|
<td>
|
|
Controls whether to enforce Java style (true) or C style (false).
|
|
</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 check to enforce Java style:
|
|
</p>
|
|
<source>
|
|
<module name="ArrayTypeStyle"/>
|
|
</source>
|
|
|
|
<p>
|
|
To configure the check to enforce C style:
|
|
</p>
|
|
<source>
|
|
<module name="ArrayTypeStyle">
|
|
<property name="javaStyle" value="false"/>
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="FinalParameters">
|
|
<subsection name="Description">
|
|
<p>
|
|
Check that parameters for methods, constructors, and catch blocks are
|
|
final. Interface and abstract methods are not checked: the final
|
|
keyword does not make sense for interface and abstract method
|
|
parameters as there is no code that could modify the parameter.
|
|
</p>
|
|
|
|
<p>
|
|
Rationale: Changing the value of parameters during the execution of
|
|
the method's algorithm can be confusing and should be avoided. A
|
|
great way to let the Java compiler prevent this coding style is to
|
|
declare parameters final.
|
|
</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>blocks to check</td>
|
|
|
|
<td>subset of tokens <a
|
|
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#METHOD_DEF">METHOD_DEF</a>,
|
|
<a
|
|
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#CTOR_DEF">CTOR_DEF</a>,
|
|
<a
|
|
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#LITERAL_CATCH">LITERAL_CATCH</a></td>
|
|
|
|
<td><a
|
|
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#METHOD_DEF">METHOD_DEF</a>,
|
|
<a
|
|
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html#CTOR_DEF">CTOR_DEF</a></td>
|
|
|
|
</tr>
|
|
<tr>
|
|
<td>ignorePrimitiveTypes</td>
|
|
<td>ignore primitive types as parameters</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 to enforce final parameters for methods and
|
|
constructors:
|
|
</p>
|
|
<source>
|
|
<module name="FinalParameters"/>
|
|
</source>
|
|
|
|
<p>
|
|
To configure the check to enforce final parameters only for
|
|
constructors:
|
|
</p>
|
|
<source>
|
|
<module name="FinalParameters">
|
|
<property name="tokens" value="CTOR_DEF"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
To configure the check to allow ignoring
|
|
<a href="http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html">
|
|
primitive datatypes</a> as parameters:
|
|
</p>
|
|
<source>
|
|
<module name="FinalParameters">
|
|
<property name="ignorePrimitiveTypes" value="true"/>
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="DescendantToken">
|
|
<subsection name="Description">
|
|
<p>
|
|
Checks for restricted tokens beneath other tokens.
|
|
</p>
|
|
|
|
<p>
|
|
WARNING: This is a very powerful and flexible check, but, at the
|
|
same time, it is low-level and very implementation-dependent because
|
|
its results depend on the grammar we use to build abstract syntax
|
|
trees. Thus we recommend using other checks when they provide the
|
|
desired functionality. Essentially, this check just works on the level
|
|
of an abstract syntax tree and knows nothing about language structures.
|
|
</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>token types to check</td>
|
|
<td>subset of tokens declared in <a
|
|
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html">TokenTypes</a></td>
|
|
<td>empty set</td>
|
|
</tr>
|
|
<tr>
|
|
<td>limitedTokens</td>
|
|
<td>set of tokens with limited occurrences as descendants</td>
|
|
<td>subset of tokens declared in <a
|
|
href="apidocs/com/puppycrawl/tools/checkstyle/api/TokenTypes.html">TokenTypes</a></td>
|
|
<td>empty set</td>
|
|
</tr>
|
|
<tr>
|
|
<td>minimumDepth</td>
|
|
<td>the minimum depth for descendant counts</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td>0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>maximumDepth</td>
|
|
<td>the maximum depth for descendant counts</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td>java.lang.Integer.MAX_VALUE</td>
|
|
</tr>
|
|
<tr>
|
|
<td>minimumNumber</td>
|
|
<td>a minimum count for descendants</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td>0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>maximumNumber</td>
|
|
<td>a maximum count for descendants</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td>java.lang.Integer.MAX_VALUE</td>
|
|
</tr>
|
|
<tr>
|
|
<td>sumTokenCounts</td>
|
|
<td>
|
|
whether the number of tokens found should be calculated
|
|
from the sum of the individual token counts
|
|
</td>
|
|
<td><a href="property_types.html#boolean">Boolean</a></td>
|
|
<td><code>false</code></td>
|
|
</tr>
|
|
<tr>
|
|
<td>minimumMessage</td>
|
|
<td>error message when the minimum count is not reached</td>
|
|
<td><a href="property_types.html#string">String</a></td>
|
|
<td>"descendant.token.min"</td>
|
|
</tr>
|
|
<tr>
|
|
<td>maximumMessage</td>
|
|
<td>error message when the maximum count is exceeded</td>
|
|
<td><a href="property_types.html#string">String</a></td>
|
|
<td>"descendant.token.max"</td>
|
|
</tr>
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
Comparing <code>this</code> with <code>null</code> (i.e. <code>this ==
|
|
null</code> and <code>this != null</code>):
|
|
</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="EQUAL,NOT_EQUAL"/>
|
|
<property name="limitedTokens" value="LITERAL_THIS,LITERAL_NULL"/>
|
|
<property name="maximumNumber" value="1"/>
|
|
<property name="maximumDepth" value="1"/>
|
|
<property name="sumTokenCounts" value="true"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>String literal equality check:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="EQUAL,NOT_EQUAL"/>
|
|
<property name="limitedTokens" value="STRING_LITERAL"/>
|
|
<property name="maximumNumber" value="0"/>
|
|
<property name="maximumDepth" value="1"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>Switch with no default:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="LITERAL_SWITCH"/>
|
|
<property name="maximumDepth" value="2"/>
|
|
<property name="limitedTokens" value="LITERAL_DEFAULT"/>
|
|
<property name="minimumNumber" value="1"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>
|
|
Assert statement may have side effects (formatted for browser
|
|
display):
|
|
</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="LITERAL_ASSERT"/>
|
|
<property name="limitedTokens" value="ASSIGN,DEC,INC,POST_DEC,
|
|
POST_INC,PLUS_ASSIGN,MINUS_ASSIGN,STAR_ASSIGN,DIV_ASSIGN,MOD_ASSIGN,
|
|
BSR_ASSIGN,SR_ASSIGN,SL_ASSIGN,BAND_ASSIGN,BXOR_ASSIGN,BOR_ASSIGN,
|
|
METHOD_CALL"/>
|
|
<property name="maximumNumber" value="0"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>
|
|
The initialiser in <code>for</code> performs no setup (where a <code>while</code> statement could be used instead):
|
|
</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="FOR_INIT"/>
|
|
<property name="limitedTokens" value="EXPR"/>
|
|
<property name="minimumNumber" value="1"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>
|
|
The condition in <code>for</code> performs no check:
|
|
</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="FOR_CONDITION"/>
|
|
<property name="limitedTokens" value="EXPR"/>
|
|
<property name="minimumNumber" value="1"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>
|
|
A switch within a switch:
|
|
</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="LITERAL_SWITCH"/>
|
|
<property name="limitedTokens" value="LITERAL_SWITCH"/>
|
|
<property name="maximumNumber" value="0"/>
|
|
<property name="minimumDepth" value="1"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>A return statement from within a catch or finally block:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="LITERAL_FINALLY,LITERAL_CATCH"/>
|
|
<property name="limitedTokens" value="LITERAL_RETURN"/>
|
|
<property name="maximumNumber" value="0"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>A try statement within a catch or finally block:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="LITERAL_CATCH,LITERAL_FINALLY"/>
|
|
<property name="limitedTokens" value="LITERAL_TRY"/>
|
|
<property name="maximumNumber" value="0"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>Too many cases within a switch:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="LITERAL_SWITCH"/>
|
|
<property name="limitedTokens" value="LITERAL_CASE"/>
|
|
<property name="maximumDepth" value="2"/>
|
|
<property name="maximumNumber" value="10"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>Too many local variables within a method:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="METHOD_DEF"/>
|
|
<property name="limitedTokens" value="VARIABLE_DEF"/>
|
|
<property name="maximumDepth" value="2"/>
|
|
<property name="maximumNumber" value="10"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>Too many returns from within a method:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="METHOD_DEF"/>
|
|
<property name="limitedTokens" value="LITERAL_RETURN"/>
|
|
<property name="maximumNumber" value="3"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>Too many fields within an interface:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="INTERFACE_DEF"/>
|
|
<property name="limitedTokens" value="VARIABLE_DEF"/>
|
|
<property name="maximumDepth" value="2"/>
|
|
<property name="maximumNumber" value="0"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>Limits the number of exceptions a method can throw:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="LITERAL_THROWS"/>
|
|
<property name="limitedTokens" value="IDENT"/>
|
|
<property name="maximumNumber" value="1"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>Limits the number of expressions in a method:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="METHOD_DEF"/>
|
|
<property name="limitedTokens" value="EXPR"/>
|
|
<property name="maximumNumber" value="200"/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>Disallows empty statements:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="EMPTY_STAT"/>
|
|
<property name="limitedTokens" value="EMPTY_STAT"/>
|
|
<property name="maximumNumber" value="0"/>
|
|
<property name="maximumDepth" value="0"/>
|
|
<property name="maximumMessage"
|
|
value="Empty statement is not allowed."/>
|
|
</module>
|
|
</source>
|
|
|
|
<p>Too many fields within a class:</p>
|
|
<source>
|
|
<module name="DescendantToken">
|
|
<property name="tokens" value="CLASS_DEF"/>
|
|
<property name="limitedTokens" value="VARIABLE_DEF"/>
|
|
<property name="maximumDepth" value="2"/>
|
|
<property name="maximumNumber" value="10"/>
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="Indentation">
|
|
<subsection name="Description">
|
|
<p>
|
|
Checks correct indentation of Java code.
|
|
</p>
|
|
|
|
<p>
|
|
The idea behind this is that while pretty printers are
|
|
sometimes convenient for bulk reformats of legacy code, they often
|
|
either aren't configurable enough or just can't anticipate how
|
|
format should be done. Sometimes this is personal preference, other
|
|
times it is practical experience. In any case, this check should
|
|
just ensure that a minimal set of indentation rules is followed.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>basicOffset</td>
|
|
<td>how many spaces to use for new indentation level</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td>4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>braceAdjustment</td>
|
|
<td>how far braces should be indented when on the next line</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td>0</td>
|
|
</tr>
|
|
<tr>
|
|
<td>caseIndent</td>
|
|
<td>how much to indent a case label</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td>4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>throwsIndent</td>
|
|
<td>how far a throws clause should be indented when on next line</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td>4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>arrayInitIndent</td>
|
|
<td>how much to indent an array initialisation when on next line</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td>4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>lineWrappingIndentation</td>
|
|
<td>how far continuation line should be indented when line-wrapping is present</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td>4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>forceStrictCondition</td>
|
|
<td>force strict condition in line wrapping case. If value is true, line wrap indent
|
|
have to be same as lineWrappingIndentation parameter</td>
|
|
<td><a href="property_types.html#boolean">Boolean</a></td>
|
|
<td>false</td>
|
|
</tr>
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
To configure the check:
|
|
</p>
|
|
<source>
|
|
<module name="Indentation"/>
|
|
</source>
|
|
|
|
<p>
|
|
To configure the check to enforce the indentation style recommended by
|
|
Oracle:
|
|
</p>
|
|
|
|
<source>
|
|
<module name="Indentation">
|
|
<property name="caseIndent" value="0"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
To configure the Check to enforce strict condition in line-wrapping validation.
|
|
</p>
|
|
<source>
|
|
<module name="Indentation">
|
|
<property name="forceStrictCondition" value="true"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
Such config doesn't allow next cases:
|
|
</p>
|
|
<source>
|
|
void foo(String aFooString,
|
|
int aFooInt) {} // indent:8 ; expected: 4; warn, because 8 != 4
|
|
</source>
|
|
<p>
|
|
But if forceStrictCondition = false, this code is valid:
|
|
</p>
|
|
<source>
|
|
void foo(String aFooString,
|
|
int aFooInt) {} // indent:8 ; expected: > 4; ok, because 8 > 4
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks.indentation
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="TrailingComment">
|
|
<subsection name="Description">
|
|
<p>
|
|
The check to ensure that requires that comments be the only thing on
|
|
a line. For the case of <code>//</code> comments that means that the only thing
|
|
that should precede it is whitespace. It doesn't check comments if
|
|
they do not end a line; for example, it accepts the following:
|
|
<code>Thread.sleep( 10 <some comment here> );</code> Format
|
|
property is intended to deal with the "} // while" example.
|
|
</p>
|
|
|
|
<p>
|
|
Rationale: Steve McConnel in <cite>Code Complete</cite> suggests that
|
|
endline comments are a bad practice. An end line comment would be
|
|
one that is on the same line as actual code. For example:
|
|
</p>
|
|
|
|
<source>
|
|
a = b + c; // Some insightful comment
|
|
d = e / f; // Another comment for this line
|
|
</source>
|
|
|
|
<p>
|
|
Quoting <cite>Code Complete</cite> for the justification:
|
|
</p>
|
|
|
|
<ul>
|
|
<li> "The comments have to be aligned so that they do not
|
|
interfere with the visual structure of the code. If you don't align
|
|
them neatly, they'll make your listing look like it's been through a
|
|
washing machine."
|
|
</li>
|
|
<li> "Endline comments tend to be hard to format...It takes
|
|
time to align them. Such time is not spent learning more about the
|
|
code; it's dedicated solely to the tedious task of pressing the
|
|
spacebar or tab key."
|
|
</li>
|
|
<li> "Endline comments are also hard to maintain. If the code
|
|
on any line containing an endline comment grows, it bumps the
|
|
comment farther out, and all the other endline comments will have to
|
|
bumped out to match. Styles that are hard to maintain aren't
|
|
maintained...."
|
|
</li>
|
|
<li> "Endline comments also tend to be cryptic. The right side
|
|
of the line doesn't offer much room and the desire to keep the
|
|
comment on one line means the comment must be short. Work then goes
|
|
into making the line as short as possible instead of as clear as
|
|
possible. The comment usually ends up as cryptic as
|
|
possible...."
|
|
</li>
|
|
<li> "A systemic problem with endline comments is that it's
|
|
hard to write a meaningful comment for one line of code. Most
|
|
endline comments just repeat the line of code, which hurts more than
|
|
it helps."
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
McConnel's comments on being hard to maintain when the size of the line
|
|
changes are even more important in the age of automated
|
|
refactorings.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>format</td>
|
|
<td>pattern for strings allowed before the comment</td>
|
|
<td><a href="property_types.html#regexp">regular expression</a></td>
|
|
<td><code>^[\\s\\}\\);]*$</code></td>
|
|
</tr>
|
|
<tr>
|
|
<td>legalComment</td>
|
|
<td>pattern for text allowed in trailing comments. (This
|
|
pattern will not be applied to multiline comments and the text of the
|
|
comment will be trimmed before matching.)</td>
|
|
<td><a href="property_types.html#regexp">regular expression</a></td>
|
|
<td>(not set)</td>
|
|
</tr>
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
To configure the check:
|
|
</p>
|
|
<source>
|
|
<module name="TrailingComment"/>
|
|
</source>
|
|
|
|
<p>
|
|
To configure the check so it enforces only comment on a line:
|
|
</p>
|
|
<source>
|
|
<module name="TrailingComment">
|
|
<property name="format" value="^\\s*$"/>
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks.indentation
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="Regexp">
|
|
<subsection name="Description">
|
|
<p>
|
|
A check that makes sure that a specified pattern exists, exists less
|
|
than a set number of times, or does not exist in the file.
|
|
</p>
|
|
<p>
|
|
This check combines all the functionality provided by
|
|
<a href="config_header.html#RegexpHeader">RegexpHeader</a>
|
|
except supplying the regular expression from a file.
|
|
</p>
|
|
<p>
|
|
It differs from them in that it works in multiline mode.
|
|
Its regular expression can span multiple lines and it checks this
|
|
against the whole file at once.
|
|
The others work in singleline mode.
|
|
Their single or multiple regular expressions can only span one line.
|
|
They check each of these against each line in the file in turn.
|
|
</p>
|
|
<p>
|
|
<b>Note:</b> Because of the different mode of operation there may be
|
|
some changes in the regular expressions used to achieve a particular end.
|
|
</p>
|
|
<p>In multiline mode...</p>
|
|
<ul>
|
|
<li> <code>^</code> means the beginning of a line, as opposed to beginning of the input.</li>
|
|
<li> For beginning of the input use <code>\A</code>.</li>
|
|
<li> <code>$</code> means the end of a line, as opposed to the end of the input.</li>
|
|
<li> For end of input use <code>\Z</code>.</li>
|
|
<li> Each line in the file is terminated with a line feed character.</li>
|
|
</ul>
|
|
<p>
|
|
<b>Note:</b> Not all regular expression engines are created equal. Some provide extra
|
|
functions that others do not and some elements of the syntax may vary.
|
|
This check makes use of the <a
|
|
href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/package-summary.html">
|
|
java.util.regex package</a>; please check its documentation for
|
|
details of how to construct a regular expression to achieve a particular
|
|
goal.
|
|
</p>
|
|
<p>
|
|
<b>Note:</b> When entering a regular expression as a parameter in the
|
|
XML config file you must also take into account the XML rules. e.g. if
|
|
you want to match a < symbol you need to enter &lt;. The regular
|
|
expression should be entered on one line.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>format</td>
|
|
<td>pattern</td>
|
|
<td><a href="property_types.html#regexp">regular expression</a></td>
|
|
<td><code>$^</code> (empty)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>message</td>
|
|
<td>message which is used to notify about violations,
|
|
if empty then the default (hard-coded) message is used.</td>
|
|
<td><a href="property_types.html#string">String</a></td>
|
|
<td><code>""</code>(empty)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>illegalPattern</td>
|
|
<td>Controls whether the pattern is required or illegal.</td>
|
|
<td><a href="property_types.html#boolean">Boolean</a></td>
|
|
<td><code>false</code></td>
|
|
</tr>
|
|
<tr>
|
|
<td>duplicateLimit</td>
|
|
<td>Controls whether to check for duplicates of a required pattern,
|
|
any negative value means no checking for duplicates, any positive
|
|
value is used as the maximum number of allowed duplicates, if the
|
|
limit is exceeded errors will be logged.</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td><code>-1</code></td>
|
|
</tr>
|
|
<tr>
|
|
<td>errorLimit</td>
|
|
<td>Controls the maximum number of errors before the check will abort.</td>
|
|
<td><a href="property_types.html#integer">Integer</a></td>
|
|
<td><code>100</code></td>
|
|
</tr>
|
|
<tr>
|
|
<td>ignoreComments</td>
|
|
<td>Controls whether to ignore matches found within comments.</td>
|
|
<td><a href="property_types.html#boolean">Boolean</a></td>
|
|
<td><code>false</code></td>
|
|
</tr>
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
The following examples are mainly copied from the other 3 checks
|
|
mentioned above, to show how the same results can be achieved using
|
|
this check in place of them.
|
|
</p>
|
|
<p>
|
|
<b>To use like Required Regexp check:</b>
|
|
</p>
|
|
<p>
|
|
An example of how to configure the check to make sure a copyright
|
|
statement is included in the file:
|
|
</p>
|
|
<p> The statement. </p>
|
|
<source>
|
|
// This code is copyrighted
|
|
</source>
|
|
<p> The check. </p>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property name="format" value="// This code is copyrighted"/>
|
|
</module>
|
|
</source>
|
|
<p> Your statement may be multiline. </p>
|
|
<source>
|
|
// This code is copyrighted
|
|
// (c) MyCompany
|
|
</source>
|
|
<p> Then the check would be. </p>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property name="format" value="// This code is copyrighted\n// \(c\) MyCompany"/>
|
|
</module>
|
|
</source>
|
|
<p><b>Note:</b> To search for parentheses () in a regular expression
|
|
you must escape them like \(\). This is required by the regexp engine,
|
|
otherwise it will think they are special instruction characters.
|
|
</p>
|
|
<p>
|
|
And to make sure it appears only once:
|
|
</p>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property name="format" value="// This code is copyrighted\n// \(c\) MyCompany"/>
|
|
<property name="duplicateLimit" value="0"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
It can also be useful to attach a meaningful message to the check:
|
|
</p>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property name="format" value="// This code is copyrighted\n// \(c\) MyCompany"/>
|
|
<property name="message" value="Copyright"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
<b>To use like illegal regexp check:</b>
|
|
</p>
|
|
<p>
|
|
An example of how to configure the check to make sure there are no
|
|
calls to <code>System.out.println</code>:
|
|
</p>
|
|
<source>
|
|
<module name="Regexp">
|
|
<!-- . matches any character, so we need to escape it and use \. to match dots. -->
|
|
<property name="format" value="System\.out\.println"/>
|
|
<property name="illegalPattern" value="true"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
You may want to make the above check ignore comments, like this:
|
|
</p>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property name="format" value="System\.out\.println"/>
|
|
<property name="illegalPattern" value="true"/>
|
|
<property name="ignoreComments" value="true"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
An example of how to configure the check to find trailing whitespace
|
|
at the end of a line:
|
|
</p>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property name="format" value="[ \t]+$"/>
|
|
<property name="illegalPattern" value="true"/>
|
|
<property name="message" value="Trailing whitespace"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
An example of how to configure the check to find case-insensitive
|
|
occurrences of "debug":
|
|
</p>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property name="format" value="(?i)debug"/>
|
|
<property name="illegalPattern" value="true"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
<b>Note:</b> The (?i) at the beginning of the regular expression
|
|
tells the regexp engine to ignore the case.
|
|
</p>
|
|
<p>
|
|
There is also a feature to limit the number of errors reported.
|
|
When the limit is reached the check aborts with a message
|
|
reporting that the limit has been reached.
|
|
The default limit setting is 100, but this can be change as shown in
|
|
the following example.
|
|
</p>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property name="format" value="(?i)debug"/>
|
|
<property name="illegalPattern" value="true"/>
|
|
<property name="errorLimit" value="1000"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
<b>To use like <a
|
|
href="config_header.html#RegexpHeader">RegexpHeader
|
|
</a>:</b>
|
|
</p>
|
|
<p>
|
|
To configure the check to verify that each file starts with the
|
|
following multiline header.
|
|
</p>
|
|
<p>Note the following:</p>
|
|
<ul>
|
|
<li>\A means the start of the file.</li>
|
|
<li>The date can be any 4 digit number.</li>
|
|
</ul>
|
|
|
|
<source>
|
|
// Copyright (C) 2004 MyCompany
|
|
// All rights reserved
|
|
</source>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property
|
|
name="format"
|
|
value="\A// Copyright \(C\) \d\d\d\d MyCompany\n// All rights reserved"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
A more complex example. Note how the import and javadoc multilines are
|
|
handled, there can be any number of them.
|
|
</p>
|
|
<source>
|
|
///////////////////////////////////////////////////////////////////////
|
|
// checkstyle:
|
|
// Checks Java source code for adherence to a set of rules.
|
|
// Copyright (C) 2004 Oliver Burn
|
|
// Last modification by $Author A.N.Other$
|
|
///////////////////////////////////////////////////////////////////////
|
|
|
|
package com.puppycrawl.checkstyle;
|
|
|
|
import java.util.thing1;
|
|
import java.util.thing2;
|
|
import java.util.thing3;
|
|
|
|
/**
|
|
* javadoc line 1
|
|
* javadoc line 2
|
|
* javadoc line 3
|
|
*/
|
|
</source>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property
|
|
name="format"
|
|
value="\A/{71}\n// checkstyle:\n// Checks Java source code for
|
|
adherence to a set of rules\.\n// Copyright \(C\) \d\d\d\d Oliver Burn\n
|
|
// Last modification by \$Author.*\$\n/{71}\n\npackage [\w\.]*;\n\n
|
|
(import [\w\.]*;\n)*\n/\*\*\n( \*[^/]*\n)* \*/"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
<b>More examples:</b>
|
|
</p>
|
|
<p>
|
|
The next 2 examples deal with the following example Java source file:
|
|
</p>
|
|
<source>
|
|
/*
|
|
* PID.java
|
|
*
|
|
* Copyright (c) 2001 ACME
|
|
* 123 Some St.
|
|
* Somewhere.
|
|
*
|
|
* This software is the confidential and proprietary information of ACME.
|
|
* ("Confidential Information"). You shall not disclose such
|
|
* Confidential Information and shall use it only in accordance with
|
|
* the terms of the license agreement you entered into with ACME.
|
|
*
|
|
* $Log: config_misc.xml,v $
|
|
* Revision 1.7 2007/01/16 12:16:35 oburn
|
|
* Removing all reference to mailing lists
|
|
*
|
|
* Revision 1.6 2005/12/25 16:13:10 o_sukhodolsky
|
|
* Fix for rfe 1248106 (TYPECAST is now accepted by NoWhitespaceAfter)
|
|
*
|
|
* Fix for rfe 953266 (thanks to Paul Guyot (pguyot) for submitting patch)
|
|
* IllegalType can be configured to accept some abstract classes which
|
|
* matches to regexp of illegal type names (property legalAbstractClassNames)
|
|
*
|
|
* TrailingComment now can be configured to accept some trailing comments
|
|
* (such as NOI18N) (property legalComment, rfe 1385344).
|
|
*
|
|
* Revision 1.5 2005/11/06 11:54:12 oburn
|
|
* Incorporate excellent patch [ 1344344 ] Consolidation of regexp checks.
|
|
*
|
|
* Revision 1.3.8.1 2005/10/11 14:26:32 someone
|
|
* Fix for bug 251. The broken bit is fixed
|
|
*/
|
|
|
|
package com.acme.tools;
|
|
|
|
import com.acme.thing1;
|
|
import com.acme.thing2;
|
|
import com.acme.thing3;
|
|
|
|
/**
|
|
*
|
|
* <P>
|
|
* <I>This software is the confidential and proprietary information of
|
|
* ACME (<B>"Confidential Information"</B>). You shall not
|
|
* disclose such Confidential Information and shall use it only in
|
|
* accordance with the terms of the license agreement you entered into
|
|
* with ACME.</I>
|
|
* </P>
|
|
*
|
|
* &#169; copyright 2002 ACME
|
|
*
|
|
* @author Some Body
|
|
*/
|
|
public class PID extends StateMachine implements WebObject.Constants {
|
|
|
|
/** javadoc. */
|
|
public static final int A_SETPOINT = 1;
|
|
.
|
|
.
|
|
.
|
|
} // class PID
|
|
</source>
|
|
<p>
|
|
This checks for the presence of the header, the first 16 lines.
|
|
</p>
|
|
<p>Note the following:</p>
|
|
<ul>
|
|
<li>Line 2 and 13 contain the file name. These are checked to
|
|
make sure they are the same, and that they match the class name.</li>
|
|
<li>The date can be any 4 digit number.</li>
|
|
</ul>
|
|
|
|
<source>
|
|
<module name="Regexp">
|
|
<property
|
|
name="format"
|
|
value="\A/\*\n \* (\w*)\.java\n \*\n \* Copyright \(c\)
|
|
\d\d\d\d ACME\n \* 123 Some St\.\n \* Somewhere\.\n \*\n
|
|
\* This software is the confidential and proprietary information
|
|
of ACME\.\n \* \("Confidential Information"\)\. You
|
|
shall not disclose such\n \* Confidential Information and shall
|
|
use it only in accordance with\n \* the terms of the license
|
|
agreement you entered into with ACME\.\n \*\n
|
|
\* \$Log: config_misc.xml,v $
|
|
\* \Revision 1.7 2007/01/16 12:16:35 oburn
|
|
\* \Removing all reference to mailing lists
|
|
\* \
|
|
\* \Revision 1.6 2005/12/25 16:13:10 o_sukhodolsky
|
|
\* \Fix for rfe 1248106 (TYPECAST is now accepted by NoWhitespaceAfter)
|
|
\* \
|
|
\* \Fix for rfe 953266 (thanks to Paul Guyot (pguyot) for submitting patch)
|
|
\* \IllegalType can be configured to accept some abstract classes which
|
|
\* \matches to regexp of illegal type names (property legalAbstractClassNames)
|
|
\* \
|
|
\* \TrailingComment now can be configured to accept some trailing comments
|
|
\* \(such as NOI18N) (property legalComment, rfe 1385344).
|
|
\* \
|
|
\* \Revision 1.5 2005/11/06 11:54:12 oburn
|
|
\* \Incorporate excellent patch [ 1344344 ] Consolidation of regexp checks.
|
|
\* \\n(.*\n)*([\w|\s]*( class | interface )\1)"/>
|
|
<property name="message" value="Correct header not found"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
This checks for the presence of a copyright notice within the class
|
|
javadoc, lines 24 to 37.
|
|
</p>
|
|
<source>
|
|
<module name="Regexp">
|
|
<property
|
|
name="format"
|
|
value="(/\*\*\n)( \*.*\n)*( \* &lt;P&gt;\n \* &lt;I&gt;
|
|
This software is the confidential and proprietary information of\n
|
|
\* ACME \(&lt;B&gt;&quot;Confidential Information&quot;&lt;/B&gt;
|
|
\)\. You shall not\n \* disclose such Confidential Information
|
|
and shall use it only in\n \* accordance with the terms of the
|
|
license agreement you entered into\n \* with ACME\.&lt;/I&gt;\n
|
|
\* &lt;/P&gt;\n \*\n \* &#169; copyright \d\d\d\d ACME\n
|
|
\*\n \* @author .*)(\n\s\*.*)*/\n[\w|\s]*( class | interface )"/>
|
|
<property name="message" value="Copyright in class/interface Javadoc"/>
|
|
<property name="duplicateLimit" value="0"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
<b>Note:</b> To search for things that mean something in XML, like
|
|
< you need to escape them like &lt;. This is required so the
|
|
XML parser does not act on them, but instead passes the correct
|
|
character to the regexp engine.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="OuterTypeFilename">
|
|
<subsection name="Description">
|
|
<p>
|
|
Checks that the outer type name and the file name match. For example,
|
|
the class <code>Foo</code> must be in a file named
|
|
<code>Foo.java</code>.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<p>None.</p>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
To configure the check:
|
|
</p>
|
|
<source>
|
|
<module name="OuterTypeFilename"/>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="UniqueProperties">
|
|
<subsection name="Description">
|
|
<p>
|
|
Checks properties files for duplicated properties.
|
|
</p>
|
|
<p>
|
|
Rationale: Multiple property keys usually appear after merge
|
|
or rebase of several branches. While there are no errors in
|
|
runtime, there can be a confusion due to having different values
|
|
for the duplicated properties.
|
|
</p>
|
|
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>fileExtensions</td>
|
|
<td>file type extension of the files to check.</td>
|
|
<td><a href="property_types.html#stringSet">String Set</a></td>
|
|
<td>properties</td>
|
|
</tr>
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
To configure the check:
|
|
</p>
|
|
<source>
|
|
<module name="UniqueProperties">
|
|
<property name="fileExtensions" value="properties" />
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#Checker">Checker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="AvoidEscapedUnicodeCharacters">
|
|
<subsection name="Description">
|
|
<p>
|
|
Restrict using <a href = "http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.3">
|
|
Unicode escapes</a> (e.g. \u221e).
|
|
It is possible to allow using escapes for
|
|
<a href="http://en.wiktionary.org/wiki/Appendix:Control_characters"> non-printable(control) characters</a>.
|
|
Also, this check can be configured to allow using escapes
|
|
if trail comment is present. By the option it is possible to
|
|
allow using escapes if literal contains only them.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>allowEscapesForControlCharacters</td>
|
|
<td>Allow use escapes for non-printable(control) characters.</td>
|
|
<td><a href="property_types.html#boolean">Boolean</a></td>
|
|
<td>false</td>
|
|
</tr>
|
|
<tr>
|
|
<td>allowByTailComment</td>
|
|
<td>Allow use escapes if trail comment is present.</td>
|
|
<td><a href="property_types.html#boolean">Boolean</a></td>
|
|
<td>false</td>
|
|
</tr>
|
|
<tr>
|
|
<td>allowIfAllCharactersEscaped</td>
|
|
<td>Allow if all characters in literal are escaped.</td>
|
|
<td><a href="property_types.html#boolean">Boolean</a></td>
|
|
<td>false</td>
|
|
</tr>
|
|
<tr>
|
|
<td>allowNonPrintableEscapes</td>
|
|
<td>Allow non-printable escapes.</td>
|
|
<td><a href="property_types.html#boolean">Boolean</a></td>
|
|
<td>false</td>
|
|
</tr>
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
Examples of using Unicode:
|
|
</p>
|
|
<source>
|
|
String unitAbbrev = "μs"; //Best: perfectly clear even without a comment.
|
|
String unitAbbrev = "\u03bcs"; //Poor: the reader has no idea what this is.
|
|
</source>
|
|
<p>
|
|
An example of how to configure the check is:
|
|
</p>
|
|
<source>
|
|
<module name="AvoidEscapedUnicodeCharacters"/>
|
|
</source>
|
|
<p>
|
|
An example of non-printable(control) characters.
|
|
</p>
|
|
<source>
|
|
return '\ufeff' + content; // byte order mark
|
|
</source>
|
|
<p>
|
|
An example of how to configure the check to allow using escapes
|
|
for non-printable(control) characters:
|
|
</p>
|
|
<source>
|
|
<module name="AvoidEscapedUnicodeCharacters">
|
|
<property name="allowEscapesForControlCharacters" value="true"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
Example of using escapes with trail comment:
|
|
</p>
|
|
<source>
|
|
String unitAbbrev = "\u03bcs"; // Greek letter mu, "s"
|
|
</source>
|
|
<p>
|
|
An example of how to configure the check to allow using escapes
|
|
if trail comment is present:
|
|
</p>
|
|
<source>
|
|
<module name="AvoidEscapedUnicodeCharacters">
|
|
<property name="allowByTailComment" value="true"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
Example of using escapes if literal contains only them:
|
|
</p>
|
|
<source>
|
|
String unitAbbrev = "\u03bc\u03bc\u03bc";
|
|
</source>
|
|
<p>
|
|
An example of how to configure the check to allow escapes
|
|
if literal contains only them:
|
|
</p>
|
|
<source>
|
|
<module name="AvoidEscapedUnicodeCharacters">
|
|
<property name="allowIfAllCharactersEscaped" value="true"/>
|
|
</module>
|
|
</source>
|
|
<p>
|
|
An example of how to configure the check to allow non-printable escapes:
|
|
</p>
|
|
<source>
|
|
<module name="AvoidEscapedUnicodeCharacters">
|
|
<property name="allowNonPrintableEscapes" value="true"/>
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#TreeWalker">TreeWalker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
<section name="UniqueProperties">
|
|
<subsection name="Description">
|
|
<p>
|
|
Checks properties file for a duplicated properties.
|
|
</p>
|
|
<p>
|
|
Rationale: Multiple property keys usually appears after merge
|
|
or rebase of several branches. While there is no errors in
|
|
runtime, there can be a confusion on having different values
|
|
for the duplicated properties.
|
|
</p>
|
|
|
|
</subsection>
|
|
|
|
<subsection name="Properties">
|
|
<table>
|
|
<tr>
|
|
<th>name</th>
|
|
<th>description</th>
|
|
<th>type</th>
|
|
<th>default value</th>
|
|
</tr>
|
|
<tr>
|
|
<td>fileExtensions</td>
|
|
<td>file type extension of the files to check.</td>
|
|
<td><a href="property_types.html#stringSet">String Set</a></td>
|
|
<td>properties</td>
|
|
</tr>
|
|
</table>
|
|
</subsection>
|
|
|
|
<subsection name="Examples">
|
|
<p>
|
|
To configure the check:
|
|
</p>
|
|
<source>
|
|
<module name="UniqueProperties">
|
|
<property name="fileExtensions" value="properties" />
|
|
</module>
|
|
</source>
|
|
</subsection>
|
|
|
|
<subsection name="Package">
|
|
<p>
|
|
com.puppycrawl.tools.checkstyle.checks
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection name="Parent Module">
|
|
<p>
|
|
<a href="config.html#Checker">Checker</a>
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
</body>
|
|
</document>
|