skip to content

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…