1. Overview

Ktlint is a linting tool used for formatting code written in Kotlin. It ensures our code is clean by following a standard style guide. In general, Ktlint checks the code styling we’ve used to write our code and formats it to make it better for readability.

In this tutorial, we’ll learn how to format code using Ktlint in our Kotlin projects.

2. Benefits of Using Ktlint

Ktlint ensures consistent code style across our entire project, making our code easier to read and understand. This is helpful since there is collaboration among developers working on the same project reducing the learning curve.

Since Ktlint automatically styles our code, it helps maintain a higher level of code quality.

It ensures reduced code review effort because it automatically checks and fixes code styles that go against the style guidelines.

Ktlint also saves us time since we no longer have to manually format or even fix the style issues that may occur while writing code.

3. Adding Ktlint to a Kotlin Project

Now that we’ve seen what we can do with Ktlint and the benefits of using this tool, let’s also discuss how we can integrate it into our project.

We’ll add Ktlint by using the Ktlint Gradle Plugin. Essentially, this plugin is a separate third-party plugin from the basic Ktlint tool. It’s helpful in this process since it’s easier to work with and provides us with commands to run Ktlint.

Let’s check the guidelines and steps involved in adding Ktlint:

  • Add the Ktlint Gradle Plugin
  • Apply the Ktlint Gradle Plugin to our subprojects
  • Verify added Gradle tasks

3.1. Add the Ktlint Gradle Plugin

In this step, we usually add the plugin to the root-level build.gradle of our project. If our Gradle version supports using the plugin DSL, this is how we add the plugin:

plugins {
    id "org.jlleitschuh.gradle.ktlint" version "7.1.0"
}

In this case, we’re using version 7.1.0, which we can replace with our desired version.

However, if our Gradle version doesn’t support using the plugin DSL, this is how we add the plugin:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "org.jlleitschuh.gradle:ktlint-gradle:7.1.0"
  }
}

3.2. Apply the Ktlint-Gradle Plugin to Our Subprojects

Now, let’s apply the plugin to the various modules within our project. This step is usually applicable when our project has multiple modules and not a single one.

We add the plugin inside the allprojects{} block in our build.gradle file:

allprojects {
    apply plugin: "org.jlleitschuh.gradle.ktlint"
}

3.3. Verify Added Gradle Tasks

In this final step, we verify that our Ktlint Gradle tasks have been added to our project and are now available for use.

To showcase an instance where our code violates our guidelines, we’ll add a comment line in a Kotlin file. The comment doesn’t have a space after comment symbols //:

//comment, testing Ktlint

Let’s run the gradlew ktlintCheck command:

./gradlew ktlintCheck

This command runs through our entire project and reports any errors that violate our coding style:

> Task :presentation:ktlintMainSourceSetCheck FAILED
/Users/kanake/Desktop/Cocktails/presentation/src/main/java/com/example/presentation/views/CockTailsActivity.kt:13:9 Missing space after //

FAILURE: Build failed with an exception.

It’s worth noting that Ktlint was able to determine the specific file and also the part where the code violation occurred.

Let’s see how to fix the errors:

./gradlew ktlintFormat

This command auto-fixes any errors found in our project. At the same time, if it can’t fix our errors automatically, it reports them back to us on our terminal.

After running the command, this is how our comment line looks like:

// comment, testing Ktlint

Our terminal will finally show a build successful message.

4. Conclusion

In this article, we discussed Ktlint, a linting tool to ensure we keep a standard style guide while writing our code. It also aids in formatting issues found in our code by trying to fix them for us automatically.

As always, the source code for this article is available over on GitHub.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.