Since Checkstyle 6.0
Check location of annotation on language elements. By default, Check enforce to locate annotations immediately after documentation block and before target element, annotation should be located on separate line from target element.
Attention: Annotations among modifiers are ignored (looks like false-negative) as there might be a problem with annotations for return types:
public @Nullable Long getStartTimeOrNull() { ... }Such annotations are better to keep close to type. Due to limitations, Checkstyle can not examine the target of an annotation.
Example:
@Override
@Nullable
public String getNameIfPresent() { ... }
| name | description | type | default value | since |
|---|---|---|---|---|
| allowSamelineMultipleAnnotations | Allow annotation(s) to be located on the same line as target element. | Boolean | false | 6.0 |
| allowSamelineSingleParameterlessAnnotation | Allow single parameterless annotation to be located on the same line as target element. | Boolean | true | 6.1 |
| allowSamelineParameterizedAnnotation | Allow one and only parameterized annotation to be located on the same line as target element. | Boolean | false | 6.4 |
| tokens | tokens to check | subset of tokens CLASS_DEF, INTERFACE_DEF, PACKAGE_DEF, ENUM_CONSTANT_DEF, ENUM_DEF, METHOD_DEF, CTOR_DEF, VARIABLE_DEF, PARAMETER_DEF, ANNOTATION_DEF, ANNOTATION_FIELD_DEF. | CLASS_DEF, INTERFACE_DEF, PACKAGE_DEF, ENUM_CONSTANT_DEF, ENUM_DEF, METHOD_DEF, CTOR_DEF, VARIABLE_DEF. | 6.0 |
Example to allow multiple annotations on the same line
@SuppressWarnings("deprecation") @Mock DataLoader loader; // no violations
Use the following configuration:
<module name="AnnotationLocation">
<property name="allowSamelineMultipleAnnotations" value="true"/>
<property name="allowSamelineSingleParameterlessAnnotation"
value="false"/>
<property name="allowSamelineParameterizedAnnotation" value="false"/>
</module>
Example to allow one single parameterless annotation on the same line
@Override public int hashCode() { ... } // no violations
@SuppressWarnings("deprecation") public int foo() { ... } // violation
Use the following configuration:
<module name="AnnotationLocation">
<property name="allowSamelineMultipleAnnotations" value="false"/>
<property name="allowSamelineSingleParameterlessAnnotation"
value="true"/>
<property name="allowSamelineParameterizedAnnotation" value="false"/>
</module>
Example to allow only one and only parameterized annotation on the same line
@SuppressWarnings("deprecation") DataLoader loader; // no violations
@Mock DataLoader loader; // violation
Use the following configuration:
<module name="AnnotationLocation">
<property name="allowSamelineMultipleAnnotations" value="false"/>
<property name="allowSamelineSingleParameterlessAnnotation"
value="false"/>
<property name="allowSamelineParameterizedAnnotation" value="true"/>
</module>
The following example demonstrates how the check validates annotations of method parameters, catch parameters, foreach, for-loop variable definitions.
Configuration:
<module name="AnnotationLocation">
<property name="allowSamelineMultipleAnnotations" value="false"/>
<property name="allowSamelineSingleParameterlessAnnotation"
value="false"/>
<property name="allowSamelineParameterizedAnnotation" value="false"/>
<property name="tokens" value="VARIABLE_DEF, PARAMETER_DEF"/>
</module>
Code example:
public void test(@MyAnnotation String s) { // OK
...
for (@MyAnnotation char c : s.toCharArray()) { ... } // OK
...
try { ... }
catch (@MyAnnotation Exception ex) { ... } // OK
...
for (@MyAnnotation int i = 0; i < 10; i++) { ... } // OK
...
MathOperation c = (@MyAnnotation int a, @MyAnnotation int b) -> a + b; // OK
...
}
All messages can be customized if the default message doesn't suit you. Please see the documentation to learn how to.
Since Checkstyle 8.2
The check does verifying that annotations are located on the same line with their targets. Verifying with this check is not good practice, but it is using by some style guides.
| name | description | type | default value | since |
|---|---|---|---|---|
| tokens | tokens to check | subset of tokens CLASS_DEF, INTERFACE_DEF, ENUM_DEF, METHOD_DEF, CTOR_DEF, VARIABLE_DEF, PARAMETER_DEF, ANNOTATION_DEF, TYPECAST, LITERAL_THROWS, IMPLEMENTS_CLAUSE, TYPE_ARGUMENT, LITERAL_NEW, DOT, ANNOTATION_FIELD_DEF. | CLASS_DEF, INTERFACE_DEF, ENUM_DEF, METHOD_DEF, CTOR_DEF, VARIABLE_DEF. | 8.2 |
To configure the check:
<module name="AnnotationOnSameLine"/>
Example to allow annotations on the same line
@Override public int toString() { ... } // no violations
@Before @Override public void set() { ... } // no violation
Example to disallow annotations on previous line
@SuppressWarnings("deprecation") // violation
@Override // violation
public int foo() { ... }
All messages can be customized if the default message doesn't suit you. Please see the documentation to learn how to.
Since Checkstyle 5.0
This check controls the style with the usage of annotations.
Annotations have three element styles starting with the least verbose.
To not enforce an element style a ElementStyle.IGNORE type is provided. The desired style can be set through the elementStyle property.
Using the ElementStyle.EXPANDED style is more verbose. The expanded version is sometimes referred to as "named parameters" in other languages.
Using the ElementStyle.COMPACT style is less verbose. This style can only be used when there is an element called 'value' which is either the sole element or all other elements have default values.
Using the ElementStyle.COMPACT_NO_ARRAY style is less verbose. It is similar to the ElementStyle.COMPACT style but single value arrays are flagged. With annotations a single value array does not need to be placed in an array initializer. This style can only be used when there is an element called 'value' which is either the sole element or all other elements have default values.
The ending parenthesis are optional when using annotations with no elements. To always require ending parenthesis use the ClosingParens.ALWAYS type. To never have ending parenthesis use the ClosingParens.NEVER type. To not enforce a closing parenthesis preference a ClosingParens.IGNORE type is provided. Set this through the closingParens property.
Annotations also allow you to specify arrays of elements in a standard format. As with normal arrays, a trailing comma is optional. To always require a trailing comma use the TrailingArrayComma.ALWAYS type. To never have a trailing comma use the TrailingArrayComma.NEVER type. To not enforce a trailing array comma preference a TrailingArrayComma.IGNORE type is provided. Set this through the trailingArrayComma property.
By default the ElementStyle is set to COMPACT_NO_ARRAY, the TrailingArrayComma is set to NEVER, and the ClosingParens is set to NEVER.
According to the JLS, it is legal to include a trailing comma in arrays used in annotations but Sun's Java 5 & 6 compilers will not compile with this syntax. This may in be a bug in Sun's compilers since eclipse 3.4's built-in compiler does allow this syntax as defined in the JLS. Note: this was tested with compilers included with JDK versions 1.5.0.17 and 1.6.0.11 and the compiler included with eclipse 3.4.1.
| name | description | type | default value | since |
|---|---|---|---|---|
| elementStyle | Define the annotation element styles. | Element Style | compact_no_array | 5.0 |
| closingParens | Define the policy for ending parenthesis. | Closing Parens | never | 5.0 |
| trailingArrayComma | Define the policy for trailing comma in arrays. | Trailing Comma | never | 5.0 |
To configure the check:
<module name="AnnotationUseStyle"/>
To configure the check to enforce an expanded style, with a trailing array comma set to never and always including the closing parenthesis.
<module name="AnnotationUseStyle">
<property name="elementStyle" value="expanded"/>
<property name="trailingArrayComma" value="never"/>
<property name="closingParens" value="always"/>
</module>
All messages can be customized if the default message doesn't suit you. Please see the documentation to learn how to.
Since Checkstyle 5.0
Verifies that both the @Deprecated annotation is present and the @deprecated javadoc tag are present when either one is present.
Both ways of flagging deprecation serve their own purpose. The @Deprecated annotation is used for compilers and development tools. The @deprecated javadoc tag is used to document why something is deprecated and what, if any, alternatives exist.
In order to properly mark something as deprecated both forms of deprecation should be present.
Package deprecation is a exception to the rule of always using the javadoc tag and annotation to deprecate. Only the package-info.java file can contain a Deprecated annotation and it CANNOT contain a deprecated javadoc tag. This is the case with Sun's javadoc tool released with JDK 1.6.0_11. As a result, this check does not deal with Deprecated packages in any way. No official documentation was found confirming this behavior is correct (of the javadoc tool).
| name | description | type | default value | since |
|---|---|---|---|---|
| skipNoJavadoc | Ignore cases when JavaDoc is missing, but still warns when JavaDoc is present but either @deprecated is missing from JavaDoc or @Deprecated is missing from the element. | Boolean | false | 6.16 |
To configure the check:
<module name="MissingDeprecated"/>
In addition you can configure this check with skipNoJavadoc option to allow it to ignore cases when JavaDoc is missing, but still warns when JavaDoc is present but either @deprecated is missing from JavaDoc or @Deprecated is missing from the element. To configure this check to allow it use:
<module name="MissingDeprecated">
<property name="skipNoJavadoc" value="true" />
</module>
Examples of validating source code with skipNoJavadoc:
@deprecated
public static final int MY_CONST = 123456; // no violation
/** This javadoc is missing deprecated tag. */
@deprecated
public static final int COUNTER = 10; // violation as javadoc exists
All messages can be customized if the default message doesn't suit you. Please see the documentation to learn how to.
Since Checkstyle 5.0
Verifies that the @Override annotation is present when the @inheritDoc javadoc tag is present.
Rationale: The @Override annotation helps compiler tools ensure that an override is actually occurring. It is quite easy to accidentally overload a method or hide a static method and using the @Override annotation points out these problems.
This check will log a violation if using the @inheritDoc tag on a method that is not valid (ex: private, or static method).
There is a slight difference between the @Override annotation in Java 5 versus Java 6 and above. In Java 5, any method overridden from an interface cannot be annotated with @Override. In Java 6 this behavior is allowed.
As a result of the aforementioned difference between Java 5 and Java 6, a property called javaFiveCompatibility is available. This property will only check classes, interfaces, etc. that do not contain the extends or implements keyword or are not anonymous classes. This means it only checks methods overridden from java.lang.Object. Java 5 Compatibility mode severely limits this check. It is recommended to only use it on Java 5 source.
| name | description | type | default value | since |
|---|---|---|---|---|
| javaFiveCompatibility | Enable java 5 compatibility mode. | Boolean | false | 5.0 |
To configure the check:
<module name="MissingOverride"/>
To configure the check for the javaFiveCompatibility mode:
<module name="MissingOverride">
<property name="javaFiveCompatibility"
value="true"/>
</module>
All messages can be customized if the default message doesn't suit you. Please see the documentation to learn how to.
Since Checkstyle 5.0
This check makes sure that all package annotations are in the package-info.java file.
According to the Java Language Specification.
The JLS does not enforce the placement of package annotations. This placement may vary based on implementation. The JLS does highly recommend that all package annotations are placed in the package-info.java file. See Java Language Specification, §7.4.1.
All messages can be customized if the default message doesn't suit you. Please see the documentation to learn how to.
Since Checkstyle 5.0
This check allows you to specify what warnings that @SuppressWarnings is not allowed to suppress. You can also specify a list of TokenTypes that the configured warning(s) cannot be suppressed on.
Limitations: This check does not consider conditionals inside the @SuppressWarnings annotation.
For example: @SuppressWarnings((false) ? (true) ? "unchecked" : "foo" : "unused"). According to the above example, the "unused" warning is being suppressed not the "unchecked" or "foo" warnings. All of these warnings will be considered and matched against regardless of what the conditional evaluates to. The check also does not support code like @SuppressWarnings("un" + "used"), @SuppressWarnings((String) "unused") or @SuppressWarnings({('u' + (char)'n') + (""+("used" + (String)"")),}).
By default, any warning specified will be disallowed on all legal TokenTypes unless otherwise specified via the tokens property.
Also, by default warnings that are empty strings or all whitespace (regex: ^$|^\s+$) are flagged. By specifying, the format property these defaults no longer apply.
This check can be configured so that the "unchecked" and "unused" warnings cannot be suppressed on anything but variable and parameter declarations. See below of an example.
| name | description | type | default value | since |
|---|---|---|---|---|
| format | Specify the RegExp to match against warnings. Any warning being suppressed matching this pattern will be flagged. | Regular Expression | "^\s*+$" | 5.0 |
| tokens | tokens to check | subset of tokens CLASS_DEF, INTERFACE_DEF, ENUM_DEF, ANNOTATION_DEF, ANNOTATION_FIELD_DEF, ENUM_CONSTANT_DEF, PARAMETER_DEF, VARIABLE_DEF, METHOD_DEF, CTOR_DEF. | CLASS_DEF, INTERFACE_DEF, ENUM_DEF, ANNOTATION_DEF, ANNOTATION_FIELD_DEF, ENUM_CONSTANT_DEF, PARAMETER_DEF, VARIABLE_DEF, METHOD_DEF, CTOR_DEF. | 5.0 |
To configure the check:
<module name="SuppressWarnings"/>
To configure the check so that the "unchecked" and "unused" warnings cannot be suppressed on anything but variable and parameter declarations.
<module name="SuppressWarnings">
<property name="format"
value="^unchecked$|^unused$"/>
<property name="tokens"
value="
CLASS_DEF,INTERFACE_DEF,ENUM_DEF,
ANNOTATION_DEF,ANNOTATION_FIELD_DEF,
ENUM_CONSTANT_DEF,METHOD_DEF,CTOR_DEF
"/>
</module>
All messages can be customized if the default message doesn't suit you. Please see the documentation to learn how to.
Since Checkstyle 5.7
Maintains a set of check suppressions from @SuppressWarnings annotations. It allows to prevent Checkstyle from reporting errors from parts of code that were annotated with @SuppressWarnings and using name of the check to be excluded. You can also define aliases for check names that need to be suppressed.
| name | description | type | default value | since |
|---|---|---|---|---|
| aliasList | Specify aliases for check names that can be used in code within SuppressWarnings. | String Set in a format of comma separated attribute=value entries. The attribute is the fully qualified name of the Check and value is its alias. | null | 5.7 |
To prevent FooCheck errors from being reported write:
@SuppressWarnings("foo") interface I { }
@SuppressWarnings("foo") enum E { }
@SuppressWarnings("foo") InputSuppressWarningsFilter() { }
Some real check examples:
This will prevent from invocation of the MemberNameCheck:
@SuppressWarnings({"membername"})
private int J;
You can also use a checkstyle prefix to prevent compiler from processing this annotations. For example this will prevent ConstantNameCheck:
@SuppressWarnings("checkstyle:constantname")
private static final int m = 0;
The general rule is that the argument of the @SuppressWarnings will be matched against class name of the checker in lower case and without Check suffix if present.
If aliasList property was provided you can use your own names e.g below code will work if there was provided a ParameterNumberCheck=paramnum in the aliasList:
@SuppressWarnings("paramnum")
public void needsLotsOfParameters(@SuppressWarnings("unused") int a,
int b, int c, int d, int e, int f, int g, int h) {
...
}
It is possible to suppress all the checkstyle warnings with the argument "all":
@SuppressWarnings("all")
public void someFunctionWithInvalidStyle() {
//...
}
All messages can be customized if the default message doesn't suit you. Please see the documentation to learn how to.