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.
Co-founder and CEO of SourceLevel. Previously co-founder of Plataformatec.
Loves to talk about software engineering, Elixir, coffee, mechanical keyboards, multitools and his 3 big dogs.
5 thoughts on “ktlint or detekt, which linter to choose?”
Comments are closed.
Thank you for this explanation. What about Spotless? Where does that fit in equation…
Sorry taking so long to reply you.
We have another post that a mention spotless. Basically spotless makes more delightful when you have more tools (linters) to be handled by gradle. Spotless integrates just fine with ktlint.
More about spotless and ktlint here https://sourcelevel.io/blog/step-by-step-how-to-setup-ktlint-with-spotless
Does ktlint really follow the official style? I doubt it. ktlint and IntelliJ IDEA disagree on a few things. Here are some examples: Indentation of constructor arguments (IntelliJ IDEA: 8 spaces, ktlint: 4 spaces) or sequence of imports (IntelliJ IDEA: kotlin imports last, ktlint: kotlin imports sorted alphabetically). The claim that ktlint follows the official style doesn’t withstand scrutiny, it seems.
IntelliJ IDEA does not own Kotlin or it’s official style guide. Here is what ktlint says:
> While this might sound extreme, keep in mind that ktlint tries to capture (reflect) official code style* from kotlinlang.org and Android Kotlin Style Guide
The star there is to point out that ktlint is even stricter than the official guidelines, (smaller number of allowed blank lines and no wild-card import).
So although ktlint is not strictly following the official guidelines, your arguments to reach that conclusion is not correct since IntelliJ IDEA isn’t following it either and arguably much worse 🙂