Code Style and Formatting in Kotlin

What is Code Style?

Simply put code style is how your code looks. Here “your” means each individual writing code. To understand your style reflect back on the code you have written. If one has learned to code using an Integrated Development Environment(IDE) like IntelliJ, etc, your styling might be very similar to the defaults of the editor in the IDE. If one has used just a text editor the style would have evolved based on what one thinks is readable.

Code style consists of numerous small things grouped into one, based on the programing language. To list a few:

• Indentation — Tabs vs Spaces, number of tabs/or spaces.
• Naming — Class naming, variable naming, method naming, etc.
• Code wrapping — maximum number of characters in a line.
• Whitespaces — between methods/code blocks, end of file, etc.
• Code organization/grouping, etc.

Why is code style important?

Consistent styling throughout your code makes it easier to read. Easier to read code is easy to understand for all collaborators. Sticking to a consistent code style potentially reduces the risk of mistakes and makes it easier to collaborate.

Each programming language has its own styling guideline/convention. For example, Kotlin prefers camel casing in method names while python prefers snake case. Hence, there is no single guide applicable to all programming languages.

Code formatting in Kotlin

Kotlin has its own set of coding conventions or style guides, refer to the official style guide to learn more about the conventions. Kotlin is the primary language recommended by Google for Android application development and it has its own set of style guidelines, refer to the official style guide for Android development.

The style guide is quite exhaustive and it is difficult to maintain a consistent style across all collaborators, especially in large teams. While learning the style guidelines is important for developers it is difficult to review and maintain a consistent style via manual reviews. Instead, teams can use lint tools that help is highlighting the issues locally as well as on a CI(continuous integration) server.

In this article, we are going to look at one such tool i.e. ktlint.

What is ktlint?

Ktlint is a linter with a built-in formatter for Kotlin. This linter aims to capture the official Kotlin coding conventions and the Android Kotlin Style Guide. It provides a standard set of rules and also lets one customize by settings up custom rules.

anti-bikeshedding Kotlin linter with built-in formatter.

Ktlint provides two major features

• Providing linting information on the codebase i.e. points out the code rule violation or places where the standard/defined rules aren’t followed.
• A formatting tool fixes the lint issues in the code automatically.

Integrating ktlint

ktlint is distributed as an executable jar file. For Gradle projects, it is recommended to integrate it via plugins written on top of ktlint.

We are going to look at the integration of one such plugin i.e. jlleitschuh/ktlint-gradle.

The integration for this ktlint plugin is fairly straightforward. Just need to add the plugin to your project and apply it to all modules. To add the plugin go to the root level build.gradle(.kts) and add the plugin as shown below.

plugins {
    ...
    // replace version with the latest version.
    id("org.jlleitschuh.gradle.ktlint") version("11.2.0")
}

// apply the plugin to all sub-modules in the project.
subprojects {
    apply(plugin = "org.jlleitschuh.gradle.ktlint")
}

Once the plugin is installed, among other Gradle tasks you would find two important ktlint tasks namely ktlintCheck and ktlintFormat .

• ktlintCheck — This command checks violations in the code style or coding conventions in the project and outputs the results on the command line/terminal. You can run the command as shown below at the root level of your project to find all the violations.

./gradlew ktlintCheck

• ktlintFormat — This command fixes the violations reported by the lint check command. Some violations can not be fixed in a deterministic way, and need manual action. You can run the command as shown below at the root level of your project to fix all the violations.

./gradlew ktlintFormat

Alternatively, instead of Gradle integration, one can integrate the unofficial Android Studio or IntelliJ plugin to achieve the same results. Though it is better to integrate via Gradle Plugin as it enables us to run these lint checks on a CI server.

Customizing ktlint

Though ktlint follows the standard guidelines/conventions sometimes one would want to customize it further, i.e. have stricter checks or disable a few checks for whatever reason.

Ktlint uses a limited set of .editorconfig properties for additional configuration. A sensible default value is provided for each property when not explicitly defined. Properties can be overridden, provided they are specified under [*.{kt,kts}].

To customize create an .editorconfig file in the root level of your and the custom configuration like shown in the example below

[*.{kt,kts}]
insert_final_newline = false

Refer to the official documentation for details on how to configure and the name of specific rules.

Happy Coding…