TLDR: Use Detekt, configuration is easy and you’ll get the static analysis benefits as well. If you are willing to change your project to match ktlint’s style it is a great choice, and avoids bikeshedding.
To lint or not to lint??
Whether you choose to a linter or not can depend on your team and project. However it isn’t uncommon to find that a development team needs to define the style of the coding. Whether this is the number of tabs, which line braces are put on, etc etc. Put a couple of developers in a room and they will either be arguing of Vi vs Emacs or coding style.
Kotlin options
If you are a Kotlin Android developer the main choice of linter seems to be: the built in linter, ktlint or detekt. With each of there are pros and cons:
Built In linter:
Pros:
- Built in.
Picks up a number of Android specific issues.
Cons:
- Doesn’t know much about Kotlin
ktlint:
Pros:
- Opinionated
- No bikeshedding
- Good Kotlin Linter
- Often Updated
Cons:
- Opinionated
- No configuration
detekt:
Pros:
- Good Kotlin Linter
- Configurable
- Often Updated
- Static analysis as well as linting
- Good out of the box options
Cons:
- A lot of configurations options
The built in linter is great at picking up issues with an Android project (eg issues in layout files etc) and good companion to either ktlint or detekt. Ktlint and detekt will pick up many issues in your Kotlin code that the built in linter won’t.
A linter (and its configuration) is the codification of a teams development style. Bikeshedding can easily consume a development team. In my opinion the coding style should match that of the default or your tools and or documentation, unless you have a really good reason.
Standard tooling and style brings me to my main complaint about ktlint. As an anti bikeshedding tool they define a reasonable set of default style which cannot be changed. A few editor styles will be observed such as number of spaces per tab, however everything else is locked down. Android studio, child of Jetbrains and the creators of Kotlin will automatically change a number of imports from the same library into a wildcard import. Ktlint has determined this is an error, while this is a configurable option in Android Studio it is quite an annoyance that this will trip up developers until this option is changed. While it is possible that wildcard imports are hiding unused imports it is noted that there are many wildcard imports in the Kotlin source (see for more info).
Detekt starts out with a reasonable set of defaults for an Android project. Wildcard card import is a setting that is detected by default, but to change the setting it is a simple matter of running:
./gradlew detektGenerateConfig
This will create a detekt.yml file in your project with the detekt options listed. Change the detekt.yml file to meet the needs of your team and you are up and running. In my experimenting ktlint and detekt find pretty much the same issues.
Detekt will give you the same listing results as ktlint, and allow you to match the way your team works. Static analysis is an added bonus. If you have a team who argues endlessly about coding style then ktlint might be an advantage.
Leave a Reply