<p>Since Checkstyle 3.0</p><p> Checks for unused import statements. Checkstyle uses a simple but very reliable algorithm to report on unused import statements. An import statement is considered unused if: </p><ul><li> It is not referenced in the file. The algorithm does not support wild-card imports like <code>import java.io.*;</code>. Most IDE's provide very sophisticated checks for imports that handle wild-card imports. </li><li> It is a duplicate of another import. This is when a class is imported more than once. </li><li> The class imported is from the <code>java.lang</code> package. For example importing <code>java.lang.String</code>. </li><li> The class imported is from the same package. </li><li><b>Optionally:</b> it is referenced in Javadoc comments. This check is on by default, but it is considered bad practice to introduce a compile time dependency for documentation purposes only. As an example, the import <code>java.util.Date</code> would be considered referenced with the Javadoc comment <code>{@link Date}</code>. The alternative to avoid introducing a compile time dependency would be to write the Javadoc comment as <code>{@link java.util.Date}</code>. </li></ul><p> The main limitation of this check is handling the case where an imported type has the same name as a declaration, such as a member variable. </p><p> For example, in the following case the import <code>java.awt.Component</code> will not be flagged as unused: </p><pre><code> import java.awt.Component; class FooBar { private Object Component; // a bad practice in my opinion ... } </code></pre>

<p>Since Checkstyle 3.0</p><p> Checks for unused import statements. Checkstyle uses a simple but very reliable algorithm to report on unused import statements. An import statement is considered unused if: </p><ul><li> It is not referenced in the file. The algorithm does not support wild-card imports like <code>import java.io.*;</code>. Most IDE's provide very sophisticated checks for imports that handle wild-card imports. </li><li> It is a duplicate of another import. This is when a class is imported more than once. </li><li> The class imported is from the <code>java.lang</code> package. For example importing <code>java.lang.String</code>. </li><li> The class imported is from the same package. </li><li><b>Optionally:</b> it is referenced in Javadoc comments. This check is on by default, but it is considered bad practice to introduce a compile time dependency for documentation purposes only. As an example, the import <code>java.util.Date</code> would be considered referenced with the Javadoc comment <code>{@link Date}</code>. The alternative to avoid introducing a compile time dependency would be to write the Javadoc comment as <code>{@link java.util.Date}</code>. </li></ul><p> The main limitation of this check is handling the case where an imported type has the same name as a declaration, such as a member variable. </p><p> For example, in the following case the import <code>java.awt.Component</code> will not be flagged as unused: </p><pre><code> import java.awt.Component; class FooBar { private Object Component; // a bad practice in my opinion ... } </code></pre>

<p>Since Checkstyle 3.0</p><p> Checks for redundant modifiers in: </p><ol><li>Interface and annotation definitions.</li><li>Final modifier on methods of final and anonymous classes.</li><li> Inner <code>interface</code> declarations that are declared as <code>static</code>. </li><li>Class constructors.</li><li> Nested <code>enum</code> definitions that are declared as <code>static</code>. </li></ol><p> Rationale: The Java Language Specification strongly discourages the usage of <code>public</code> and <code>abstract</code> for method declarations in interface definitions as a matter of style. </p><p> Interfaces by definition are abstract so the <code>abstract</code> modifier on the interface is redundant. </p><p> Classes inside of interfaces by definition are public and static, so the <code>public</code> and <code>static</code> modifiers on the inner classes are redundant. On the other hand, classes inside of interfaces can be abstract or non abstract. So, <code>abstract</code> modifier is allowed. </p><p> Fields in interfaces and annotations are automatically public, static and final, so these modifiers are redundant as well. </p><p> As annotations are a form of interface, their fields are also automatically public, static and final just as their annotation fields are automatically public and abstract. </p><p> Enums by definition are static implicit subclasses of java.lang.Enum&lt;E&gt;. So, the <code>static</code> modifier on the enums is redundant. In addition, if enum is inside of interface, <code>public</code> modifier is also redundant. </p><p> Enums can also contain abstract methods and methods which can be overridden by the declared enumeration fields. See the following example: </p><pre><code> public enum EnumClass { FIELD_1, FIELD_2 { @Override public final void method1() {} // violation expected }; public void method1() {} public final void method2() {} // no violation expected } </code></pre><p> Since these methods can be overridden in these situations, the final methods are not marked as redundant even though they can't be extended by other classes/enums. </p><p> Nested <code>enum</code> types are always static by default. </p><p> Final classes by definition cannot be extended so the <code>final</code> modifier on the method of a final class is redundant. </p><p> Public modifier for constructors in non-public non-protected classes is always obsolete: </p><pre><code> public class PublicClass { public PublicClass() {} // OK } class PackagePrivateClass { public PackagePrivateClass() {} // violation expected } </code></pre><p>There is no violation in the following example, because removing public modifier from ProtectedInnerClass constructor will make this code not compiling: </p><pre><code> package a; public class ClassExample { protected class ProtectedInnerClass { public ProtectedInnerClass () {} } } package b; import a.ClassExample; public class ClassExtending extends ClassExample { ProtectedInnerClass pc = new ProtectedInnerClass(); } </code></pre>

<p>Since Checkstyle 3.0</p><p> Checks for long lines. </p><p> Rationale: Long lines are hard to read in printouts or if developers have limited screen space for the source code, e.g. if the IDE displays additional information like project tree, class hierarchy, etc. </p>

<p>Since Checkstyle 3.0</p><p> Checks for redundant modifiers in: </p><ol><li>Interface and annotation definitions.</li><li>Final modifier on methods of final and anonymous classes.</li><li> Inner <code>interface</code> declarations that are declared as <code>static</code>. </li><li>Class constructors.</li><li> Nested <code>enum</code> definitions that are declared as <code>static</code>. </li></ol><p> Rationale: The Java Language Specification strongly discourages the usage of <code>public</code> and <code>abstract</code> for method declarations in interface definitions as a matter of style. </p><p> Interfaces by definition are abstract so the <code>abstract</code> modifier on the interface is redundant. </p><p> Classes inside of interfaces by definition are public and static, so the <code>public</code> and <code>static</code> modifiers on the inner classes are redundant. On the other hand, classes inside of interfaces can be abstract or non abstract. So, <code>abstract</code> modifier is allowed. </p><p> Fields in interfaces and annotations are automatically public, static and final, so these modifiers are redundant as well. </p><p> As annotations are a form of interface, their fields are also automatically public, static and final just as their annotation fields are automatically public and abstract. </p><p> Enums by definition are static implicit subclasses of java.lang.Enum&lt;E&gt;. So, the <code>static</code> modifier on the enums is redundant. In addition, if enum is inside of interface, <code>public</code> modifier is also redundant. </p><p> Enums can also contain abstract methods and methods which can be overridden by the declared enumeration fields. See the following example: </p><pre><code> public enum EnumClass { FIELD_1, FIELD_2 { @Override public final void method1() {} // violation expected }; public void method1() {} public final void method2() {} // no violation expected } </code></pre><p> Since these methods can be overridden in these situations, the final methods are not marked as redundant even though they can't be extended by other classes/enums. </p><p> Nested <code>enum</code> types are always static by default. </p><p> Final classes by definition cannot be extended so the <code>final</code> modifier on the method of a final class is redundant. </p><p> Public modifier for constructors in non-public non-protected classes is always obsolete: </p><pre><code> public class PublicClass { public PublicClass() {} // OK } class PackagePrivateClass { public PackagePrivateClass() {} // violation expected } </code></pre><p>There is no violation in the following example, because removing public modifier from ProtectedInnerClass constructor will make this code not compiling: </p><pre><code> package a; public class ClassExample { protected class ProtectedInnerClass { public ProtectedInnerClass () {} } } package b; import a.ClassExample; public class ClassExtending extends ClassExample { ProtectedInnerClass pc = new ProtectedInnerClass(); } </code></pre>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 3.0</p><p> Checks for long lines. </p><p> Rationale: Long lines are hard to read in printouts or if developers have limited screen space for the source code, e.g. if the IDE displays additional information like project tree, class hierarchy, etc. </p>

<p>Since Checkstyle 3.0</p><p> Checks for unused import statements. Checkstyle uses a simple but very reliable algorithm to report on unused import statements. An import statement is considered unused if: </p><ul><li> It is not referenced in the file. The algorithm does not support wild-card imports like <code>import java.io.*;</code>. Most IDE's provide very sophisticated checks for imports that handle wild-card imports. </li><li> It is a duplicate of another import. This is when a class is imported more than once. </li><li> The class imported is from the <code>java.lang</code> package. For example importing <code>java.lang.String</code>. </li><li> The class imported is from the same package. </li><li><b>Optionally:</b> it is referenced in Javadoc comments. This check is on by default, but it is considered bad practice to introduce a compile time dependency for documentation purposes only. As an example, the import <code>java.util.Date</code> would be considered referenced with the Javadoc comment <code>{@link Date}</code>. The alternative to avoid introducing a compile time dependency would be to write the Javadoc comment as <code>{@link java.util.Date}</code>. </li></ul><p> The main limitation of this check is handling the case where an imported type has the same name as a declaration, such as a member variable. </p><p> For example, in the following case the import <code>java.awt.Component</code> will not be flagged as unused: </p><pre><code> import java.awt.Component; class FooBar { private Object Component; // a bad practice in my opinion ... } </code></pre>

<p>Since Checkstyle 3.0</p><p> Checks for long lines. </p><p> Rationale: Long lines are hard to read in printouts or if developers have limited screen space for the source code, e.g. if the IDE displays additional information like project tree, class hierarchy, etc. </p>

<p>Since Checkstyle 3.0</p><p> Checks for unused import statements. Checkstyle uses a simple but very reliable algorithm to report on unused import statements. An import statement is considered unused if: </p><ul><li> It is not referenced in the file. The algorithm does not support wild-card imports like <code>import java.io.*;</code>. Most IDE's provide very sophisticated checks for imports that handle wild-card imports. </li><li> It is a duplicate of another import. This is when a class is imported more than once. </li><li> The class imported is from the <code>java.lang</code> package. For example importing <code>java.lang.String</code>. </li><li> The class imported is from the same package. </li><li><b>Optionally:</b> it is referenced in Javadoc comments. This check is on by default, but it is considered bad practice to introduce a compile time dependency for documentation purposes only. As an example, the import <code>java.util.Date</code> would be considered referenced with the Javadoc comment <code>{@link Date}</code>. The alternative to avoid introducing a compile time dependency would be to write the Javadoc comment as <code>{@link java.util.Date}</code>. </li></ul><p> The main limitation of this check is handling the case where an imported type has the same name as a declaration, such as a member variable. </p><p> For example, in the following case the import <code>java.awt.Component</code> will not be flagged as unused: </p><pre><code> import java.awt.Component; class FooBar { private Object Component; // a bad practice in my opinion ... } </code></pre>

<p>Since Checkstyle 6.9</p><p> Checks the header of a source file against a header that contains a <a href="https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">regular expression</a> for each line of the source header. </p><p> Rationale: In some projects <a href="#Header">checking against a fixed header</a> is not sufficient, e.g. the header might require a copyright line where the year information is not static. </p><p> For example, consider the following header: </p><pre><code> line 1: ^/{71}$ line 2: ^// checkstyle:$ line 3: ^// Checks Java source code for adherence to a set of rules\.$ line 4: ^// Copyright \(C\) \d\d\d\d Oliver Burn$ line 5: ^// Last modification by \$Author.*\$$ line 6: ^/{71}$ line 7: line 8: ^package line 9: line 10: ^import line 11: line 12: ^/\*\* line 13: ^ \*([^/]|$) line 14: ^ \*/ </code></pre><p> Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for javadoc (line 13 is so complicated to remove conflict with and of javadoc comment). Lines 7, 9 and 11 will be treated as '^$' and will forcefully expect the line to be empty. </p><p> Different programming languages have different comment syntax rules, but all of them start a comment with a non-word character. Hence you can often use the non-word character class to abstract away the concrete comment syntax and allow checking the header for different languages with a single header definition. For example, consider the following header specification (note that this is not the full Apache license header): </p><pre><code> line 1: ^#! line 2: ^&lt;\?xml.*&gt;$ line 3: ^\W*$ line 4: ^\W*Copyright 2006 The Apache Software Foundation or its licensors, as applicable\.$ line 5: ^\W*Licensed under the Apache License, Version 2\.0 \(the "License"\);$ line 6: ^\W*$ </code></pre><p> Lines 1 and 2 leave room for technical header lines, e.g. the "#!/bin/sh" line in Unix shell scripts, or the XML file header of XML files. Set the multiline property to "1, 2" so these lines can be ignored for file types where they do no apply. Lines 3 through 6 define the actual header content. Note how lines 2, 4 and 5 use escapes for characters that have special regexp semantics. </p>

<p>Since Checkstyle 3.2</p><p> According to <a href="https://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.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><p> Purpose of <b>ignore*</b> option is to ignore related violations, however it still impacts on other class members. </p><p> ATTENTION: the check skips class fields which have <a href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.3.3"> forward references</a> from validation due to the fact that we have Checkstyle's limitations to clearly detect user intention of fields location and grouping. For example, <pre><code> public class A { private double x = 1.0; private double y = 2.0; public double slope = x / y; // will be skipped from validation due to forward reference } </code></pre></p>

<p>Since Checkstyle 3.2</p><p> According to <a href="https://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.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><p> Purpose of <b>ignore*</b> option is to ignore related violations, however it still impacts on other class members. </p><p> ATTENTION: the check skips class fields which have <a href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.3.3"> forward references</a> from validation due to the fact that we have Checkstyle's limitations to clearly detect user intention of fields location and grouping. For example, <pre><code> public class A { private double x = 1.0; private double y = 2.0; public double slope = x / y; // will be skipped from validation due to forward reference } </code></pre></p>

<p>Since Checkstyle 3.0</p><p> Checks for unused import statements. Checkstyle uses a simple but very reliable algorithm to report on unused import statements. An import statement is considered unused if: </p><ul><li> It is not referenced in the file. The algorithm does not support wild-card imports like <code>import java.io.*;</code>. Most IDE's provide very sophisticated checks for imports that handle wild-card imports. </li><li> It is a duplicate of another import. This is when a class is imported more than once. </li><li> The class imported is from the <code>java.lang</code> package. For example importing <code>java.lang.String</code>. </li><li> The class imported is from the same package. </li><li><b>Optionally:</b> it is referenced in Javadoc comments. This check is on by default, but it is considered bad practice to introduce a compile time dependency for documentation purposes only. As an example, the import <code>java.util.Date</code> would be considered referenced with the Javadoc comment <code>{@link Date}</code>. The alternative to avoid introducing a compile time dependency would be to write the Javadoc comment as <code>{@link java.util.Date}</code>. </li></ul><p> The main limitation of this check is handling the case where an imported type has the same name as a declaration, such as a member variable. </p><p> For example, in the following case the import <code>java.awt.Component</code> will not be flagged as unused: </p><pre><code> import java.awt.Component; class FooBar { private Object Component; // a bad practice in my opinion ... } </code></pre>

<p>Since Checkstyle 3.2</p><p> According to <a href="https://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.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><p> Purpose of <b>ignore*</b> option is to ignore related violations, however it still impacts on other class members. </p><p> ATTENTION: the check skips class fields which have <a href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.3.3"> forward references</a> from validation due to the fact that we have Checkstyle's limitations to clearly detect user intention of fields location and grouping. For example, <pre><code> public class A { private double x = 1.0; private double y = 2.0; public double slope = x / y; // will be skipped from validation due to forward reference } </code></pre></p>