Skip to content

ktlint

This guide explains how to run ktlint with CloudAEye.

Overview

ktlint is a streamlined, no-frills linter and formatter for Kotlin, developed by Pinterest.

Why Use ktlint?

  • Zero configuration by default: It works out-of-the-box, enforcing Kotlin’s standard style without requiring a config file.
  • Built-in formatting: ktlint can automatically format your Kotlin (.kt and .kts) code, reducing manual style debates.
  • editorconfig support: Rules can be customized via .editorconfig for per-project styling.
  • Multiple output formats: Includes built-in reporters for plain text, JSON, HTML, and Checkstyle.
  • Extensible: You can add custom rule sets and reporters to tailor linting to your team’s needs
  • Easy to run: Distributed as a single executable JAR, making it simple to run from the command line, CI, or as part of your build.

ktlint is ideal if you want a consistent, lightweight, and automated way to enforce code style and formatting in Kotlin projects.

Prerequisites

Step 1: Register

Sign up with CloudAEye SaaS.

Step 2: Install GitHub App

Integrate with GitHub by installing the GitHub app.

Step 3: Connect Github Repositorie

Connect the repositories where you would like to use CloudAEye Code Review features.

Step 4: Configure the Linter

Configure the desired linter.

Configuration

If your repository already has ktlint configured, CloudAEye will automatically use that setup. You may also enter your desired configuration.

Use repo config

CloudAEye automatically reads your repository’s existing ktlint configuration and uses it as is. No additional setup is needed.

Common ktlint Configuration File Locations & Formats

Ktlint follows a minimal-configuration philosophy, but it does support custom configuration when you need to override defaults. Configuration is typically defined in the following places:

.editorconfig (Primary configuration file)

Ktlint reads most of its settings from a project’s .editorconfig file. This is the recommended and standard way to configure formatting rules, indentation, line length, and rule overrides.

Manual

You may enter the ktlint configuration you would like to use.

Create or update a file named .editorconfig at the root of your repository:


root = true

[*]
charset = utf-8
indent_style = space
indent_size = 4
insert_final_newline = true
max_line_length = 120

# ktlint recommended settings
ktlint_disabled_rules = no-wildcard-imports
ktlint_code_style = ktlint_official

# Optional: enable these for stricter checks
ktlint_function_naming_ignore_when_annotated = Test
ktlint_android = false

Best-Practice Guidelines

1. Use ktlint_official as the base style

This aligns with ktlint’s official formatting rules and avoids custom rule drift.

ktlint_code_style = ktlint_official

2. Allow wildcard imports (optional but common)

Many teams find wildcard imports acceptable—especially for testing and DI frameworks.

ktlint_disabled_rules = no-wildcard-imports

3. Set a reasonable line length

120 characters is a balanced choice for readability without forcing excessive wrapping.

max_line_length = 120

4. Use consistent indentation

4 spaces is the Kotlin community norm.


indent_style = space
indent_size = 4

5. Require a final newline

Helps diff cleanliness and Unix tooling compatibility.

insert_final_newline = true

6. Use reporter formats for CI

In your CI, run ktlint with both human-friendly and machine-readable output:

ktlint --reporter=plain --reporter=checkstyle,output=ktlint-report.xml

7. Keep .editorconfig as the single source of truth

ktlint intentionally avoids its own config file to reduce complexity. Use .editorconfig for all formatting rules.

File Extensions

ktlint will run on files that use any of the following extensions:

.kt, .kts

References