GitHub Twitter Stackoverflow GoogleGroups JProfiler

Google's Java Style Checkstyle Coverage

Useful information

This coverage report was created for Google Java Style( cached page), version of 26 Apr 2025.

Checkstyle configuration for 'Google Java Style'

Legend

"--" - There is no rule in this paragraph.
"↓" - This paragraph is the high-level point of some group.
- Existing Check covers all requirements from Google.
- Existing Check covers some part of requirements from Google.
- Requirements are not possible to check by Checkstyle at all.

Coverage table

ATTENTION: Links to config and sample files in the following table reference to latest (not released yet) config. Config might be slightly different from what we have in the latest release. Please always use config that is embedded to jar or use a custom version copied from one that matches your checkstyle version.

Sample files consists of files that show what code is correct and what is not. The incorrect code is marked with a "violation" comment and a message explaining the incorrect code. All the sections have their own sample files that contain example code for the particular section. Please keep in mind that some section's sample files might contain false positive violations; such sections are marked with a blue tick, showing that Checkstyle does not fully cover that section.

Google's Java Style Rule Checkstyle Checks Used Sample files
1 Introduction --
1.1 Terminology notes --
1.2 Guide notes --
2 Source file basics ↓
2.1 File name OuterTypeFilename ( config) samples
2.2 File encoding: UTF-8 explanation
2.3 Special characters ↓
2.3.1 Whitespace characters FileTabCharacter ( config) samples
2.3.2 Special escape sequences IllegalTokenText ( config) samples
2.3.3 Non-ASCII characters AvoidEscapedUnicodeCharacters ( config) samples
3 Source file structure EmptyLineSeparator ( config)

Rule is not enforced in package-info.java file. It will be addressed at: #17541

Rule for module-info.java file is not covered because of lack of support for Java modules Grammar, see details at: #8240 		samples
3.1 License or copyright information, if present --
3.2 Package statement LineLength ( config)

NoLineWrap ( config) 		samples
3.3 Import statements ↓
3.3.1 No wildcard imports AvoidStarImport ( config) samples
3.3.2 No line-wrapping LineLength ( config)

NoLineWrap ( config) 		samples
3.3.3 Ordering and spacing CustomImportOrder ( config) samples
3.3.4 No static import for classes Violations of this guideline cannot be detected by Checkstyle due to its limitation, multiple file checking is not supported.
3.4 Class declaration ↓
3.4.1 Exactly one top-level class declaration OneTopLevelClass ( config) samples
3.4.2 Class member ordering --
3.4.2.1 Overloads: never split OverloadMethodsDeclarationOrder ( config)

ConstructorsDeclarationGrouping ( config) 		samples
3.5 Module declaration ↓
3.5.1 Ordering and spacing of module directives Checkstyle currently does not have a Parser to support module-info.java file Grammar. For more information, see the discussion at: #17170
4 Formatting --
4.1 Braces ↓
4.1.1 Use of optional braces NeedBraces ( config) samples
4.1.2 Nonempty blocks: K & R style LeftCurly ( config)

RightCurly ( config)

There are some false-negatives regarding ELSE and DEFAULT blocks, they will be addressed at: #15791 and #14782 		samples
4.1.3 Empty blocks: may be concise RegexpSinglelineJava ( config)

There are some false-negatives regarding K & R style brackets for empty blocks, they're addressed at: #15791 		samples
4.2 Block indentation: +2 spaces Indentation ( config) samples
4.3 One statement per line OneStatementPerLine ( config) samples
4.4 Column limit: 100 LineLength ( config)

We can detect URL with protocol type as http://, https:// etc.
However, there are some cases we cannot cover, for example: JSNI(see reason at: #14938), detecting command lines, long identifiers and so on.

To disable this rule for above cases, please use SuppressWithNearbyTextFilter . Check out Suppressions section to learn how to use this suppression.
samples
4.5 Line-wrapping --
4.5.1 Where to break OperatorWrap ( config)

SeparatorWrap ( config)

MethodParamPad ( config)

Line break before and after the lambda(->) is not covered. It will be addressed at: #17253 		samples
4.5.2 Indent continuation lines at least +4 spaces Indentation ( config) samples
4.6 Whitespace ↓
4.6.1 Vertical Whitespace EmptyLineSeparator ( config)

Blank lines between two consecutive fields are optional. This exception is not satisfied 		samples
4.6.2 Horizontal whitespace WhitespaceAround ( config)

GenericWhitespace ( config)

MethodParamPad ( config)

ParenPad ( config)

WhitespaceAfter ( config)

NoWhitespaceBefore ( config)

NoWhitespaceBeforeCaseDefaultColon ( config)

MatchXpath ( config)

A single whitespace before the empty block({}) of a class, method, interface, static, loops(while, do, for), and record is not covered. It will be addressed at: #17715 		samples
4.6.3 Horizontal alignment: never required --
4.7 Grouping parentheses: recommended --
4.8 Specific constructs ↓
4.8.1 Enum classes --
4.8.2 Variable declarations ↓
4.8.2.1 One variable per declaration MultipleVariableDeclarations ( config) samples
4.8.2.2 Declared when needed VariableDeclarationUsageDistance ( config)
samples
4.8.3 Arrays ↓
4.8.3.1 Array initializers: can be "block-like" --
4.8.3.2 No C-style array declarations ArrayTypeStyle ( config) samples
4.8.4 Switch statements and expressions --
4.8.4.1 Indentation Indentation ( config)

Line break after { of non-empty block in switch-rule is not covered. It will be addressed at: #17565 		samples
4.8.4.2 Fall-through: commented FallThrough ( config) samples
4.8.4.3 Exhaustiveness and presence of the default label MissingSwitchDefault ( config)

"Exception: enum type may omit the default statement group" requirement can not be covered as we can not distinguish types, enum values may look the same as static final String constants. 		samples
4.8.4.4 Switch expressions --
4.8.5 Annotations ↓
4.8.5.1 Type-use annotations Violations of this guideline cannot be detected by Checkstyle due to its limitation, multiple file checking is not supported.
4.8.5.2 Class, package, and module annotations AnnotationLocation ( config)

InvalidJavadocPosition ( config)

Annotation rule for modules is not covered because of lack of support for Java modules Grammar, see details at: #8240 		samples
4.8.5.3 Methods And Constructors Annotations AnnotationLocation ( config)

InvalidJavadocPosition ( config) 		samples
4.8.5.4 Field Annotations AnnotationLocation ( config)

InvalidJavadocPosition ( config) 		samples
4.8.5.5 Parameter and local variable annotations --

For type-use annotations see 4.8.5.1 Type-use annotations
4.8.6 Comments ↓
4.8.6.1 Block comment style CommentsIndentation ( config) samples
4.8.6.2 TODO comments TodoComment ( config) samples
4.8.7 Modifiers ModifierOrder ( config)

Rule for Modifiers on requires module directives is not covered because of lack of support for Java modules Grammar, see details at: #8240 		samples
4.8.8 Numeric Literals UpperEll ( config) samples
4.8.9 Text Blocks TextBlockGoogleStyleFormatting ( config) samples
5 Naming ↓
5.1 Rules common to all identifiers CatchParameterName ( config)

All other types of identifiers are covered in special sections below 		samples
5.2 Rules by identifier type ↓
5.2.1 Package and module names PackageName ( config)

Modules name validation is not covered because of lack of support for Java modules Grammar, see details at: #8240 		samples
5.2.2 Class names TypeName () config

Checkstyle is a Static analysis tool and cannot determine whether a name is a noun, an adjective, or any other grammatical category. 		samples
5.2.3 Method names MethodName ( config)

There are some false-negatives regarding the use of underscores in the method names. They will be addressed at: #17841

Checkstyle is a Static analysis tool and cannot determine whether a name is a noun, an adjective, or any other grammatical category. 		samples
5.2.4 Constant names Every constant is a static final field, but not all static final fields are constants - impossible to check such rule.
5.2.5 Non-constant field names MemberName ( config)

There are some false-negatives regarding the use of underscore in the member names. They will be addressed at: #17842

As with section 5.2.4, it is impossible to automatically distinguish true constants from static final fields that are not constants. MemberName cannot verify that static final fields use lowerCamelCase when they are not constants (e.g., static final List<String> names). Checkstyle cannot determine whether a static final field is semantically a constant or not. 		samples
5.2.6 Parameter names ParameterName () config

CatchParameterName ( config)

LambdaParameterName ( config)

RecordComponentName ( config) 		samples
5.2.7 Local variable names LocalVariableName ( config)

PatternVariableName ( config) 		samples
5.2.8 Type variable names MethodTypeParameterName ( config)

ClassTypeParameterName ( config)

InterfaceTypeParameterName ( config)

RecordTypeParameterName ( config)
samples
5.3 Camel case: defined AbbreviationAsWordInName ( config)

Non covered:
1. Some words are ambiguously hyphenated in the English language. No way to distinguish "YouTubeImporter" or "YoutubeImporter".

2. There are some false-negatives regarding the use of underscores in method and member names. They will be addressed at: #17841 and #17842 respectively. 		samples
6 Programming Practices ↓
6.1 @Override: always used Violations of this guideline cannot be detected by Checkstyle due to its limitation, multiple file checking is not supported.

Coverage is missing for explicitly declared accessor method for a record component. It will be addressed at: #17561
6.2 Caught exceptions: not ignored EmptyCatchBlock ( config) samples
6.3 Static members: qualified using class Violations of this guideline cannot be detected by Checkstyle due to its limitation, multiple file checking is not supported.
6.4 Finalizers: not used NoFinalizer ( config) samples
7 Javadoc ↓
7.1 Formatting ↓
7.1.1 General form SingleLineJavadoc ( config)

JavadocLeadingAsteriskAlign ( config)

InvalidJavadocPosition ( config) 		samples
7.1.2 Paragraphs JavadocParagraph ( config)

RequireEmptyLineBeforeBlockTagGroup ( config) 		samples
7.1.3 Block tags AtclauseOrder ( config)

JavadocTagContinuationIndentation ( config)

NonEmptyAtclauseDescription ( config) 		samples
7.2 The summary fragment SummaryJavadoc ( config) samples
7.3 Where Javadoc is used MissingJavadocType ( config)

MissingJavadocMethod ( config)

JavadocMethod ( config) 		samples
7.3.1 Exception: self-explanatory members MissingJavadocMethod ( config)

Optional javadoc for "simple, obvious" members is only valid for getters/setters, but they should follow certain rules mentioned at Check's Description section.

JavadocMethod ( config) 		samples
7.3.2 Exception: overrides MissingJavadocMethod ( config)

Overrides are checked by presence of "@Override" annotation on method.

JavadocMethod ( config) 		samples
7.3.4 Non-required Javadoc InvalidJavadocPosition ( config) samples

Severity Level

To adjust the default severity level for violations using Checkstyle's Google style configuration, set the following system property:

org.checkstyle.google.severity

For detailed guidance on severity levels, refer to the Severity Level. To configure this property, see the instructions for the CLI's -p option , or use the properties parameter in Ant, or set the Java system property before running Checkstyle.

Suppressions

It is possible to suppress some violations by embeded filters SuppressionFilter, SuppressionXpathFilter, SuppressWithNearbyCommentFilter, SuppressionCommentFilter, SuppressWarningsFilter and SuppressWithNearbyTextFilter.

Location of config file for SuppressionFilter can be defined by system property org.checkstyle.google.suppressionfilter.config (default value is checkstyle-suppressions.xml).

Location of config file for SuppressionXpathFilter can be defined by system property org.checkstyle.google.suppressionxpathfilter.config (default value is checkstyle-xpath-suppressions.xml).

To suppress a check in the next line of code using SuppressWithNearbyCommentFilterprecede the line of code with // CHECKSTYLE.SUPPRESS: NameOfTheCheck (replace NameOfTheCheck with the actual check to be suppressed).

To suppress a check on a block of code using SuppressionCommentFilter add // CHECKSTYLE.OFF: NameOfTheCheck before the beginning of the code block and // CHECKSTYLE.ON: NameOfTheCheck after the end of the code block (replace NameOfTheCheck with the actual check to be suppressed).

To suppress a check using SuppressWarningsFilter use Java's@SuppressWarnings({"checkstyle:name_of_the_check", ...}) annotation. Each value passed in the array parameter must meet the format checkstyle:name_of_the_check where the checkstyle: is optional and name_of_the_check is the actual name of check to be suppressed in lowercase format.

To suppress a check for few lines below or above, use SuppressWithNearbyTextFilter suppression, use // CHECKSTYLE.SUPPRESS: NameOfCheck for ([+-]\d+) lines comment. ( replace NameOfCheck with the check you want to suppress. For suppressing a check few lines below, replace ([+-]\d+) with +NumberOfLines where NumberOfLines is number of the lines below from the comment's line number, for suppressing a check few lines above, use "-" instead of "+". )

For more details please review exact configuration of Filters in google_checks.xml: SuppressionFilter, SuppressionXpathFilter SuppressWithNearbyCommentFilter, SuppressionCommentFilter, SuppressWarningsFilter, SuppressWithNearbyTextFilter