All rules
Block tag punctuation¶
Description of certain block tags, if present, should end with a period, question mark or exclamation mark.
Before
After
Configuration
| Setting | Default value |
|---|---|
BlockTagPunctuation#tags |
@param, @return |
BlockTagPunctuation#tags |
@param, @return |
rulebook_punctuate_block_tags |
@constructor, @receiver, @property, @param, @return |
--punctuate-block-tags |
@param, @return |
TODO comment¶
TODO comment keywords should be uppercase and followed by exactly one space.
Before
After
Trailing comma in call¶
Put a trailing comma in a multiline call site, omit when it is a single line.
Before
After
Trailing comma in collection¶
Put a trailing comma in a multiline collection site, omit when it is a single line. In Java and Groovy, this rule applies to array initializers. In Python, this rule applies to tuples.
Before
After
Trailing comma in declaration¶
Put a trailing comma in a multiline declaration site, omit when it is a single line.
Before
After
Unused import¶
Remove unused import statements.
Before
After
Wildcard import¶
Import directives must be single-type instead of wildcard imports.
Before
After
Clipping¶
Block comment clip¶
Short block comments should be written in a single line.
Before
After
Braces clip¶
Empty code blocks should be joined with the preceding code.
Before
After
Brackets clip¶
Empty collection initializers should be joined with the preceding code.
Before
After
Parentheses clip¶
Empty method declarations and calls should be joined with the preceding code.
Before
After
Tags clip¶
Empty generic types should be joined with the preceding code.
Before
After
Declaring¶
Deprecated type¶
Prefer to use built-in types provided by the language.
Before
After
Double quotes in block comment¶
Use double quotes in Python docstrings.
Before
After
Internal error¶
Use Exception as superclass of custom exceptions. Most applications should not
extend Error or Throwable.
Before
After
Lowercase d¶
Double floating point literals should be suffixed with lowercase d, which is
more readable than D.
Before
After
Lowercase f¶
Floating point literals should be suffixed with lowercase f.
Before
After
Lowercase Hexadecimal¶
All letters in hexadecimal literals should be lowercase.
Before
After
Lowercase i¶
Integer literals should be suffixed with lowercase i.
Before
After
Missing inline in contract¶
Kotlin contract functions that carry a runnable parameter should have inline
modifier. Without the modifier, user cannot assign a global variable within the
code block.
Before
After
Missing private constructor¶
Utility classes should have a final modifier and a private constructor to prevent instantiation.
Before
After
Redundant qualifier¶
Strip fully qualified names when they are already imported.
Before
After
Single quotes in literal¶
Wrap string in single quotes, unless there is a template or a single quote.
Before
After
Unnecessary abstract¶
Abstract classes need at least one abstract function.
Before
After
Unnecessary parentheses in lambda¶
Single parameter lambdas should not have parentheses.
Before
After
Tip
Parentheses on lambda parameters is a syntax error in:
- Kotlin if parameter is single
- Groovy closures, not lambdas
Uppercase L¶
Long integer literals should be suffixed with uppercase L.
Before
After
Expressing¶
Complicated boolean equality¶
Simplify boolean expressions when applicable.
Before
After
Complicated size equality¶
Use isEmpty() or isNotEmpty() instead of comparing collection size with
zero. In languages with truthy values, use the collection itself in a boolean
context.
Before
After
Confusing predicate¶
Use the positive form in a predicate call when it is a single expression and the calling function can be inverted.
Before
After
Deprecated identity¶
Use structural equality instead of referential equality when comparing with
primitive values. In Kotlin, null is included in the set of primitive values.
Before
After
Redundant equality¶
Compare primitives with identity operator ===.
Before
After
Redundant equals¶
Use explicit operator instead of named function in Groovy.
Before
After
Formatting¶
Empty file¶
Empty files should be removed. JVM source files with only package declaration is considered empty.
Before
File size¶
File length should not be longer than 1.000 lines of code. If a file exceeds the limit, it should be split into multiple files.
Before
After
Configuration
| Setting | Default value |
|---|---|
FileLength#max |
1.000 |
ClassSize#maxLines |
1.000 |
rulebook_max_file_size |
1.000 |
--max-file-size |
1.000 |
rulebook-max-file-size |
1.000 |
max-lines |
1.000 |
max-lines |
1.000 |
Indent style¶
Use spaces instead of tabs for indentation.
Before
After
Line feed¶
Apply Unix-style line feed (LF) as a line separator.
Before
After
Line length¶
Length of a line should not exceed certain number of characters.
Before
After
Configuration
| Setting | Default value |
|---|---|
LineLength#max |
100 |
LineLength#length |
100 |
rulebook_max_line_length |
100 |
--max-line-length |
100 |
rulebook-max-line-length |
100 |
max-len |
100 |
max-len |
100 |
Trailing newline¶
End files with a newline character.
Before
After
Unnecessary trailing space¶
A line should not end with a whitespace character.
Before
After
Naming¶
Abbreviation as word¶
Ensures that the first letter of acronyms longer than three characters are always capitalized.
Before
After
Boolean property interoperability¶
Kotlin field definitions that are Boolean types should be prefixed with is.
Otherwise, the compiler will generate a getter method with get prefix.
Before
After
Class name¶
Class, interface and object names are written in PascalCase.
Before
After
Constant name¶
Constant fields should be written in SCREAMING_SNAKE_CASE.
Before
After
File name¶
If the file contains a single class, the file name should be the same as the root class name.
Before
After
Generic name¶
Generic type parameters should be named with a single uppercase letter. This rule is ignored when there are multiple generic type parameters in the same declaration.
Before
After
Identifier name¶
Non-constant fields, functions and parameters should be written in camelCase. In Python and C/C++, the snake_case style is used instead.
Before
After
Illegal variable name¶
Prohibits primitive type names, base Object type names and their plural forms
as identifiers of properties, parameters and local variables. The name of the
identifier should be descriptive and meaningful.
Before
After
Configuration
| Setting | Default value |
|---|---|
IllegalIdentifierName#format |
object, integer, string, objects, integers, strings |
IllegalVariableName#names |
object, integer, string, object, integers, strings |
rulebook_illegal_variable_names |
any, boolean, byte, char, double, float, int, long, short, string, many, booleans, bytes, chars, doubles, floats, ints, longs, shorts |
--illegal-variable-names |
integer, string, integers, strings |
bad-names |
objs, ints, strs |
id-denylist |
error, object, number, string, objects, numbers, strings |
id-denylist |
error, object, number, string, objects, numbers, strings |
Meaningless word¶
Prohibits meaningless source names in class, interface, object and files. The name of utility classes (or files) should be the plural form of the extended class.
Before
After
Configuration
| Setting | Default value |
|---|---|
MeaninglessWord#words |
Util, Utility, Helper, Manager, Wrapper |
MeaninglessWord#words |
Util, Utility, Helper, Manager, Wrapper |
rulebook_meaningless_words |
Util, Utility, Helper, Manager, Wrapper |
--meaningless-words |
Util, Utility, Helper, Manager, Wrapper |
rulebook-meaningless-words |
Util, Utility, Helper, Manager, Wrapper |
Package name¶
Package names should be written in lowercase with no separators. In C++, namespaces are considered as packages.
Before
After
Ordering¶
Block tag order¶
Block tags should be ordered in the following sequence: @constructor,
@receiver, @param, @property, @return, @throws, @see.
Before
After
Common function position¶
Place Object built-in methods such as toString(), hashCode() and equals()
at the end of the class.
Before
After
Import order¶
Import directives should be ordered alphabetically without any blank lines.
Before
After
Inner class position¶
Place inner classes at the end of the class.
Before
After
Member order¶
The class should be organized as follows: properties, initializer block, constructors, methods and static members. Inner classes should be declared next to the last member that uses them.
Before
After
Configuration
| Setting | Default value |
|---|---|
MemberOrder#order |
property, constructor, function, static |
MemberOrder#order |
property, constructor, function, static |
rulebook_member_order |
property, initializer, constructor, function, companion |
--member-order |
property, constructor, function, static |
rulebook-member-order |
property, constructor, function, static |
sort-class-members |
property, constructor, function, static |
sort-class-members |
property, constructor, function, static |
Modifier order¶
Visibility modifiers first, followed by abstraction modifiers, then other modifiers.
Before
After
Named import order¶
Multiple import directives from the same package should be ordered alphabetically.
Before
After
Overload function position¶
Place overloaded functions next to each other.
After
After
Static import position¶
Static import directives are to be placed before non-static imports, separated by a blank line.
Before
After
Scripting¶
Decentralized dependency¶
Declare dependencies in a centralizeed version catalog file and refer to them by their alias in the build script.
Before
After
Eager API¶
Prefer eager calls over lazy ones.
Before
After
Lonely configuration¶
Avoid opening a scope for a single configuration.
Before
After
Root project name¶
Specify the root project name in settings.gradle or settings.gradle.kts.
After
Script file name¶
Script file names are in lowercase with words separated by hyphens.
Before
After
Spacing¶
Block comment spaces¶
Ensures that block comments starts and ends with a whitespace. In multiline comments, each line after the asterisk should be indented by a whitespace.
Before
After
Block tag indentation¶
Multi-line block tag descriptions should be indented by four spaces, or five spaces from the leading asterisk.
Before
After
Case separator¶
Multiline switch-case entries end with a blank line while short entries are joined.
Before
After
Comment spaces¶
End-of-file comments should be separated by a single whitespace from the preceding code, and start with a single whitespace.
Before
After
Warning
PEP8 requires leading two spaces for comments.
Member separator¶
Class, function and property declarations should be separated by a blank line. There is an exception for a group of properties.
Before
After
Missing blank line before block tags¶
Separate block tag group from the summary with a blank line.
Before
After
Stating¶
Complicated assignment¶
Use shorthand assignment operators when the variable being assigned is also used in the expression.
Before
After
Illegal catch¶
Catch specific exception subclass instead of the generic Throwable,
Exception or Error.
Before
After
Illegal throw¶
Throw a narrower exception type instead of Exception, Error or Throwable.
Before
After
Lonely case¶
If a switch statement has single branch, it should be replaced with an if statement.
Before
After
Lonely if¶
A single if statement in an else block should be merged with the parent if statement.
Before
After
Missing braces¶
Enforces the use of braces for multiline if, else, for, while and do
statements.
Before
After
Nested if-else¶
If a block ends with an if statement without else and the body is at least 2 lines, it should be inverted to avoid nesting and unnecessary indentation.
Before
After
Redundant default¶
If every branch of a switch statement has a continue, return or throw statement, the default branch can be lifted.
Before
After
Redundant else¶
When every if and else-if block has a continue, return or throw statement, the else block can be lifted.
Before
After
Redundant if¶
If-else statement that returns boolean can be simplified by returning the condition.
Before
After
Semicolon¶
Do not use semicolons at the end of statements in languages that do not require them.
Before
After
Warning
Semicolons are enforced in JavaScript and TypeScript to prevent issues with automatic semicolon insertion.
Unnecessary continue¶
The last continue statement in a loop is useless.
Before
After
Unnecessary return¶
The last return statement in a function is useless.
Before
After
Testing¶
Complicated assertion¶
Use targeted assertion methods instead of general ones with complicated conditions.
Before
After
Confusing assertion¶
Flip assertions instead of negating conditions.
Before
After
Deprecated annotation¶
Prefer Kotlin test annotations over JUnit ones.
Before
After
Trimming¶
Block comment trim¶
Do not start or end block comments with whitespaces.
Before
After
Braces trim¶
Prohibits empty first and last lines in code blocks.
Before
After
Brackets trim¶
Prohibits empty first and last lines in collection initializers.
Before
After
Comment trim¶
Prohibits empty first and last lines in EOL comments.
Before
After
Duplicate blank line¶
Prohibits consecutive blank lines in the code.
Before
Warning
PEP8 allows two blank lines between top-level functions and class definitions.
After
Duplicate blank line in block comment¶
Prohibits consecutive blank lines in block comments.
Before
After
Duplicate blank line in comment¶
Prohibits consecutive blank lines in comments.
Before
After
Duplicate space¶
Prohibits consecutive spaces in the code.
Before
After
Parentheses trim¶
Prohibits empty first and last lines in method declarations and calls.
Before
After
Tags trim¶
Prohibits empty first and last lines in generic type parameters.
Before
After
Unnecessary blank line after colon¶
Prohibits first empty line in Python function and class definitions.
Before
After
Unnecessary leading blank line¶
The first line of a file cannot be a blank line.
Before
After
Wrapping¶
Assignment wrap¶
Assignee and the value of assignment spanning multiple lines should be separated by a newline.
Before
After
Chain call wrap¶
Each method call in a chain should be aligned with the dot operator.
Before
After
Elvis wrap¶
In a multiline statement, the elvis operator should be separated into a new line instead of trailing the statement.
Before
After
Infix call wrap¶
When breaking an infix function call, the operator should be placed at the end of the line.
Before
After
Lambda wrap¶
When breaking a multiline lambda expression, the body should be placed on a new line.
Before
After
Operator wrap¶
A line break should be placed after the operator in a binary expression.
Before
After
Parameter wrap¶
When breaking a multiline parameter list, each parameter should be placed on a new line.
Before
After
Statement wrap¶
Compound statements are not allowed.
Before
After