If you develop in Kotlin, you can find useful to rely on some tools like a lint. If you don’t know what it is, Wikipedia’s definition for lint is:

lint, or a linter, is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs.

In this blog post, I intend to present two of the most known linters in the Kotlin community: ktlint and detekt. The programming language itself has a built-in linter which has poor documentation. That’s why I am not considering this linter in this blog post.

Klint ships with a formatting tool. It means it indent and struct your code avoiding minor errors for you. On the other hand, detekt also checks for code smell and has a lot of configurations and different setups. Setting up detekt may be more complicated, but maybe a good option if you need custom checking.

A little bit about Gradle

Kotlin has inherited a lot of tools and helpers from Java. Gradle is one of them. It’s a tool for building, running, deploying, and testing your code. It has many uses such as exporting environment variables, configuring a particular environment for mobile testing or adding an extra step to the build pipeline.

You can write your scripts for Gradle in Groovy or Kotlin. It’s an excellent tool for running linters on your Continuous Integration / Continuous Deployment process.

What’s best, ktlint vs. detekt?

In my point of view, when we are coding, we tend to ignore code style. It sounds a minor issue, and thinking about it during development seems too much. It’s not.

It prevents undesired behaviors on your code, and everyone should value. Code style and consistency matter a lot!

Nevertheless, my opinion is that the code style is crucial. Plus, it doesn’t take much of time to configure a tool to check your code automatically. In terms of readiness, ktlint has no configuration file. Detekt, on the contrary, has many configuration options.

Ktlint gives you less stuff to discuss. It follows the official style. When you let the lint too open for configuration, people create their “official” style, as happened to eslint. Too many style guide versions can lead to inconsistency and counterproductive discussions.

For those that only need a linter that highlights errors and fixes code formatting automatically, ktlint is the best option. It performs both jobs very well, in an effortless and straightforward setup. So your team doesn’t have to worry about configuration or creating their style guide.