skip to content

ktlint

3 roadmaps5 questions

ktlint enforces the official style with a check task and a format task that fixes most violations, configured through .editorconfig. Its value is ending style debates, which is exactly how you should pitch it.

part ofKotlinoverview, primer and where to startread it →
on this pageshow

explore

questions

5

What is ktlint, and what is the difference between the ktlintCheck and ktlintFormat Gradle tasks?

level: juniorimportance: must knowfreq 70%

answer

  1. Check = report + fail, Format = rewrite files
  2. Anti-bikeshedding, official Kotlin style
  3. ktlintCheck wired into ./gradlew check
  4. .editorconfig is the only config surface
  5. Format fixes auto-correctable rules only

basics

~10 s

ktlint is a tool that checks and fixes Kotlin code style. ktlintCheck only reports problems and fails the build; ktlintFormat automatically rewrites your files to fix the fixable ones.

solid answer

~40 s

ktlint is an anti-bikeshedding linter and formatter that enforces the official Kotlin coding style with almost no configuration. Via the JLLeitschuh Gradle plugin it adds two key tasks: ktlintCheck inspects sources (main and test source sets) and fails the build on violations, printing file:line messages; it is the one wired into CI and into ./gradlew check. ktlintFormat runs the same rules but auto-corrects every violation a rule can fix in place, leaving only the non-auto-fixable ones to report. Typical workflow: run ktlintFormat locally to clean up, commit, and let ktlintCheck gate CI. ktlint can also install a Git pre-commit hook. The philosophy is 'no debates about style' — rules are mostly fixed, with a small set of knobs in .editorconfig.

code

kotlin · 8 lines
kotlin
plugins {
    id("org.jlleitschuh.gradle.ktlint") version "12.1.1"
}

// .editorconfig
// [*.{kt,kts}]
// ktlint_code_style = ktlint_official
// max_line_length = 120

go deeper

for a junior

Knows ktlint formats/lints Kotlin and that check reports while format fixes.

for a middle

Explains the anti-bikeshedding philosophy, .editorconfig config surface, and the local-format / CI-check workflow.

for a senior

Articulates why CI uses check (read-only/deterministic), how tasks attach to source sets and the check lifecycle, and the limits of auto-correct.

for a principal

Frames ktlint within a layered quality gate (format vs lint vs smell detection), reproducibility across machines, and team adoption/onboarding strategy.

## What ktlint is **ktlint** is a linter *and* formatter for Kotlin. "Linter" = a tool that scans source code and reports rule violations; "formatter" = a tool that rewrites code to a canonical layout. ktlint markets itself as **anti-bikeshedding**: it ships an opinionated rule set based on the official *Kotlin Coding Conventions* and the *Android Kotlin Style Guide*, so teams stop arguing about indentation, import order, and spacing. ## The two Gradle tasks When you apply the community Gradle plugin (`org.jlleitschuh.gradle.ktlint`), it registers tasks per source set and two umbrella tasks: - **`ktlintCheck`** — runs all rules in *report-only* mode. It does **not** modify files. On any violation it fails the build and prints `path:line:col` messages. It is added as a dependency of the standard `check` task, so `./gradlew check` (and CI) runs it automatically. - **`ktlintFormat`** — runs the same rules but applies every **auto-correctable** fix directly to your `.kt`/`.kts` files. Rules that cannot be fixed mechanically (e.g. some naming issues) are still reported. ```kotlin // build.gradle.kts plugins { id("org.jlleitschuh.gradle.ktlint") version "<latest>" } ``` ```bash ./gradlew ktlintFormat # fix what can be fixed, in place ./gradlew ktlintCheck # verify, fails build on remaining violations ``` ## Where rules live The small amount of configuration ktlint exposes is read from **`.editorconfig`** (e.g. `max_line_length`, `ktlint_code_style`). There is no custom DSL for the rules themselves — that is deliberate. ## Typical workflow 1. Developer edits code. 2. Runs `ktlintFormat` (or a pre-commit hook / IDE save action) to auto-fix. 3. Commits. 4. CI runs `ktlintCheck` (via `check`) as a gate. Key keywords: `ktlintCheck`, `ktlintFormat`, `.editorconfig`, `check` task, auto-correct.

  • Why is ktlintCheck, not ktlintFormat, the task wired into CI?
    CI must be read-only and deterministic: it should fail on bad style, not silently mutate the checked-out sources. ktlintFormat changing files in CI would hide problems and produce no diff.
  • Does ktlintFormat fix every violation?
    No. It only applies fixes for rules that are auto-correctable. Non-auto-fixable violations (e.g. certain naming rules) are still reported and must be fixed by hand.

ktlintCheck is the exam grader; ktlintFormat is the proofreader that fixes your typos before grading.

saying these in an interview costs you the question

  • Thinking ktlintCheck rewrites files
  • Believing ktlint needs heavy per-rule config like Checkstyle
  • Saying ktlintFormat fixes 100% of all violations
  • Confusing ktlint (style/format) with detekt (smells/complexity)
  • Not knowing rules come from official Kotlin conventions

context

resolving links…

open as a page

How does ktlint use .editorconfig, and what are some rules you can tune there (e.g. code style, line length, import ordering)?

level: middleimportance: should knowfreq 55%

basics

~10 s

ktlint reads its limited settings from a .editorconfig file at the project root. There you set things like the code style flavor, max line length, indent size, and whether to allow certain rules.

open as a page

What are ktlint's standard and experimental rule sets, and how do you opt into experimental rules safely?

level: middleimportance: should knowfreq 40%

basics

~20 s

The standard rule set is the stable, default set of style rules. The experimental set holds newer rules that are off by default; you turn them on in .editorconfig when you want to try them.

open as a page

How do you integrate ktlint into a CI quality gate, and how does a baseline help you adopt it on an existing codebase?

level: seniorimportance: should knowfreq 35%

basics

~20 s

Run ktlintCheck in CI so the build fails on style violations. On a big legacy codebase, generate a baseline file that records existing violations so CI only fails on new ones, then fix the old ones gradually.

open as a page

ktlint and detekt overlap on formatting. How do you decide which owns formatting, and how do you prevent ktlint disagreeing with IntelliJ's reformatter?

level: seniorimportance: nice to knowfreq 25%

basics

~20 s

Let ktlint own formatting and let detekt focus on code smells and complexity. To avoid fights with IntelliJ, point both ktlint and the IDE at the same .editorconfig so they format code the same way.

open as a page