Kotlin linter in spirit of feross/standard (JavaScript) and gofmt (Go).
Features:
- No configuration. Which means no decisions to make, nothing to argue about and no special files to manage.
While this might sound extreme, keep in mind thatktlint
tries to capture (reflect) official code style from kotlinlang.org and Android Kotlin Style Guide (+ we respect you .editorconfig and support additional ruleset|s). - Built-in formatter. So that you wouldn't have to fix all style violations by hand.
- Customizable output.
plain
(+plain?group_by_file
),json
andcheckstyle
reporters are available out-of-the-box. It's also easy to create your own. - A single executable jar with all dependencies included.
Installation | Usage | Integration with Maven / Gradle / IntelliJ IDEA / Emacs | Creating a ruleset | a reporter | Badge | FAQ
- 4 spaces for indentation
(unless a differentindent_size
value is set in .editorconfig (see EditorConfig section for more)); - No semicolons (unless used to separate multiple statements on the same line);
- No wildcard / unused
import
s; - No consecutive blank lines;
- No blank lines before
}
; - No trailing whitespaces;
- No
Unit
returns (fun fn {}
instead offun fn: Unit {}
); - No empty (
{}
) class bodies; - Consistent string templates (
$v
instead of${v}
,${p.v}
instead of${p.v.toString()}
); - Consistent order of modifiers;
- Consistent spacing after keywords, commas; around colons, curly braces, infix operators, etc;
- Newline at the end of each file
(providedinsert_final_newline
is set to true in .editorconfig (see EditorConfig section for more)).
ktlint recognizes the following .editorconfig properties (provided they are specified under [*.{kt,kts}]
):
(values shown below are the defaults and do not need to be specified explicitly)
[*.{kt,kts}]
# possible values: number (e.g. 2), "unset" (makes ktlint ignore indentation completely)
indent_size=4
continuation_indent_size=8
# true / false
insert_final_newline=unset
# possible values: number (e.g. 120) (package name, imports & comments are ignored), "off"
max_line_length=off
Skip all the way to the "Integration" section if you don't plan to use
ktlint
's command line interface.
curl -sSLO https://github.com/shyiko/ktlint/releases/download/0.12.1/ktlint &&
chmod a+x ktlint &&
sudo mv ktlint /usr/local/bin/
... or just download ktlint
from the releases page (ktlint.asc
contains PGP signature which you can verify with curl -sS https://keybase.io/shyiko/pgp_keys.asc | gpg --import && gpg --verify ktlint.asc
).
On macOS (or Linux) you can also use brew - brew install shyiko/ktlint/ktlint
.
If you don't have curl installed - replace
curl -sL
withwget -qO-
.
If you are behind a proxy see - curl / wget manpage. Usually simple
http_proxy=http://proxy-server:port https_proxy=http://proxy-server:port curl -sL ...
is enough.
# check the style of all Kotlin files inside the current dir (recursively)
# (hidden folders will be skipped)
$ ktlint
src/main/kotlin/Main.kt:10:10: Unused import
# check only certain locations (prepend ! to negate the pattern)
$ ktlint "src/**/*.kt" "!src/**/*Test.kt"
# auto-correct style violations
# (if some errors cannot be fixed automatically they will be printed to stderr)
$ ktlint -F "src/**/*.kt"
# print style violations grouped by file
$ ktlint --reporter=plain?group_by_file
# print style violations as usual + create report in checkstyle format
$ ktlint --reporter=plain --reporter=checkstyle,output=ktlint-report-in-checkstyle-format.xml
# install git hook to automatically check files for style violations on commit
$ ktlint --install-git-pre-commit-hook
on Windows you'll have to use
java -jar ktlint ...
.
ktlint --help
for more.
... with Maven
pom.xml
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>ktlint</id>
<phase>verify</phase>
<configuration>
<target name="ktlint">
<java taskname="ktlint" dir="${basedir}" fork="true" failonerror="true"
classname="com.github.shyiko.ktlint.Main" classpathref="maven.plugin.classpath">
<arg value="src/**/*.kt"/>
<!-- to generate report in checkstyle format prepend following args: -->
<!--
<arg value="--reporter=plain"/>
<arg value="--reporter=checkstyle,output=${project.build.directory}/ktlint.xml"/>
-->
<!-- see https://github.com/shyiko/ktlint#usage for more -->
</java>
</target>
</configuration>
<goals><goal>run</goal></goals>
</execution>
<execution>
<id>ktlint-format</id>
<configuration>
<target name="ktlint">
<java taskname="ktlint" dir="${basedir}" fork="true" failonerror="true"
classname="com.github.shyiko.ktlint.Main" classpathref="maven.plugin.classpath">
<arg value="-F"/>
<arg value="src/**/*.kt"/>
</java>
</target>
</configuration>
<goals><goal>run</goal></goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.github.shyiko</groupId>
<artifactId>ktlint</artifactId>
<version>0.12.1</version>
</dependency>
<!-- additional 3rd party ruleset(s) can be specified here -->
</dependencies>
</plugin>
...
To check code style - mvn antrun:run@ktlint
(it's also bound to mvn verify
).
To run formatter - mvn antrun:run@ktlint-format
.
... with Gradle
build.gradle
apply plugin: "java"
repositories {
mavenCentral()
}
configurations {
ktlint
}
dependencies {
ktlint "com.github.shyiko:ktlint:0.12.1"
// additional 3rd party ruleset(s) can be specified here
// just add them to the classpath (ktlint 'groupId:artifactId:version') and
// ktlint will pick them up
}
task ktlint(type: JavaExec, group: "verification") {
description = "Check Kotlin code style."
main = "com.github.shyiko.ktlint.Main"
classpath = configurations.ktlint
args "src/**/*.kt"
// to generate report in checkstyle format prepend following args:
// "--reporter=plain", "--reporter=checkstyle,output=${buildDir}/ktlint.xml"
// see https://github.com/shyiko/ktlint#usage for more
}
check.dependsOn ktlint
task ktlintFormat(type: JavaExec, group: "formatting") {
description = "Fix Kotlin code style deviations."
main = "com.github.shyiko.ktlint.Main"
classpath = configurations.ktlint
args "-F", "src/**/*.kt"
}
Note: For an Android project this config would typically go into your app/build.gradle.
To check code style - gradle ktlint
(it's also bound to gradle check
).
To run formatter - gradle ktlintFormat
.
Another option is to use Gradle plugin (in order of appearance):
Each plugin has some unique features (like incremental build support in case of jeremymailen/kotlinter-gradle) so check them out.
You might also want to take a look at diffplug/spotless which has a built-in support for ktlint. In addition to linting/formatting kotlin code it allows you to keep license headers, markdown documentation, etc. in check.
... with IntelliJ IDEA
While this is not strictly necessary it makes Intellij IDEA's built-in formatter produce 100% ktlint-compatible code.
(inside project's root directory)
ktlint --apply-to-idea
# or if you want to be compliant with Android Kotlin Style Guide
ktlint --apply-to-idea --android
Go to File -> Settings... -> Editor
General -> Auto Import
- check
Optimize imports on the fly (for current project)
.
- check
Code Style -> Kotlin
- open
Imports
tab, select allUse single name import
options and removeimport java.util.*
fromPackages to Use Import with '*'
. - open
Blank Lines
tab, changeKeep Maximum Blank Lines
->In declarations
&In code
to 1 andBefore '}'
to 0. - (optional but recommended) open
Wrapping and Braces
tab, uncheckMethod declaration parameters -> Align when multiline
. - (optional but recommended) open
Tabs and Indents
tab, changeContinuation indent
to 4 (to be compliant with Android Kotlin Style Guide value should stay equal 8).
- open
Inspections
- change
Severity
level ofUnused import directive
,Redundant semicolon
and (optional but recommended)Unused symbol
toERROR
.
- change
... with GNU Emacs
Integrated with something else? Send a PR.
In a nutshell: "ruleset" is a JAR containing one or more Rules gathered together in a RuleSet. ktlint
is relying on
ServiceLoader to discover all available "RuleSet"s
on the classpath (as a ruleset author, all you need to do is to include a META-INF/services/com.github.shyiko.ktlint.core.RuleSetProvider
file
containing a fully qualified name of your RuleSetProvider implementation).
Once packaged in a JAR you can load it with
# enable additional 3rd party ruleset by pointing ktlint to its location on the file system
$ ktlint -R /path/to/custom/rulseset.jar "src/test/**/*.kt"
# you can also use <groupId>:<artifactId>:<version> triple in which case artifact is
# downloaded from Maven Central, JCenter or JitPack (depending on where it's located and
# whether or not it's already present in local Maven cache)
$ ktlint -R com.github.username:rulseset:master-SNAPSHOT
A complete sample project (with tests and build files) is included in this repo under the ktlint-ruleset-template directory (make sure to check NoVarRuleTest as it contains some useful information).
Take a look at ktlint-reporter-plain.
In short, all you need to do is to implement a
Reporter and make it available by registering
a custom ReporterProvider using
META-INF/services/com.github.shyiko.ktlint.core.ReporterProvider
. Pack all of that into a JAR and you're done.
To load a custom (3rd party) reporter use ktlint --reporter=groupId:artifactId:version
/ ktlint --reporter=/path/to/custom-ktlint-reporter.jar
(see ktlint --help
for more).
[![ktlint](https://img.shields.io/badge/code%20style-%E2%9D%A4-FF4081.svg)](https://ktlint.github.io/)
Simplicity.
Spending time on configuration (& maintenance down the road) of hundred-line long style config file(s) is counter-productive. Instead of wasting your energy on something that has no business value - focus on what really matters (not debating whether to use tabs or spaces).
By using ktlint you put the importance of code clarity and community conventions over personal preferences. This makes things easier for people reading your code as well as frees you from having to document & explain what style potential contributor(s) have to follow.
ktlint is a single binary with both linter & formatter included. All you need is to drop it in (no need to get overwhelmed while choosing among dozens of code style options).
Absolutely, "no configuration" doesn't mean "no extensibility". You can add your own ruleset(s) to discover potential bugs, check for anti-patterns, etc.
See Creating A Ruleset.
This is meant primarily as an escape latch for the rare cases when ktlint is not able to produce the correct result (please report any such instances using GitHub Issues).
To disable a specific rule you'll need to turn on the verbose mode (ktlint --verbose ...
). At the end of each line
you'll see an error code. Use it as an argument for ktlint-disable
directive (shown below).
import package.* // ktlint-disable no-wildcard-imports
/* ktlint-disable no-wildcard-imports */
import package.a.*
import package.b.*
/* ktlint-enable no-wildcard-imports */
To disable all checks:
import package.* // ktlint-disable
Make sure to read CONTRIBUTING.md.
git clone https://github.com/shyiko/ktlint && cd ktlint
./mvnw # shows how to build, test, etc. project
This project is not affiliated with or endorsed by the Jetbrains.
All code, unless specified otherwise, is licensed under the MIT license.
Copyright (c) 2016 Stanley Shyiko.