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() { ... }Example:
@Override
@Nullable
public String getNameIfPresent() { ... }
| name | description | type | default value | since |
|---|---|---|---|---|
| allowSamelineMultipleAnnotations | To allow annotation(s) to be located on the same line as target element. | Boolean | false | 6.0 |
| allowSamelineSingleParameterlessAnnotation | To allow single parameterless annotation to be located on the same line as target element. | Boolean | true | 6.1 |
| allowSamelineParameterizedAnnotation | To 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, 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. | 6.0 |
Example to allow multiple annotations on the same line
@SuppressWarnings("deprecation") @Mock DataLoader loader; // no violations
Use 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 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 pametrized annotation on the same line
@SuppressWarnings("deprecation") DataLoader loader; // no violations
@Mock DataLoader loader; // violation
Use 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.
| name | description | type | default value | since |
|---|---|---|---|---|
| elementStyle |
Defines the annotation element styles. |
Element Style | compact_no_array | 5.0 |
| closingParens | Defines the policy for ending parenthesis. | Closing Parens | never | 5.0 |
| trailingArrayComma | Defines 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 java.lang.Deprecated annotation is present and the @deprecated Javadoc tag is present when either is present.
| name | description | type | default value | since |
|---|---|---|---|---|
| skipNoJavadoc | When this property is set to true check 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:
<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 java.lang.Override annotation is present when the {@inheritDoc} javadoc tag is present.
| name | description | type | default value | since |
|---|---|---|---|---|
| javaFiveCompatibility | When this property is true this check 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 | 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, section 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)"")),}).
| name | description | type | default value | since |
|---|---|---|---|---|
| format | The warnings property is a regex pattern. 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 | 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.