The last thing you want to spend time on during a code review is a discussion on formatting. Discussing formatting is a classic example of Bikeshedding. Although formatting is essential, the rules should be set once and automated as much as possible so people don’t have to waste time discussing them. Developers should spend time on what is important, which is the functionality of the software system.

I have been using ktlint for both linting and formatting Kotlin code (🐛 Difference between Linting and Formatting). While the tool is very useful, there’s something that is bugging me: ktlint doesn’t automatically format all code that doesn’t conform to the linting rules. The easiest example is that there is a maximum line length, but running the formatter doesn’t split lines.

Having worked with đŸ§č Clang Format before, which is an amazing auto formatter for C-style languages, this feels odd. It is perfectly possible to split lines according to some maximum line length, although that is not necessarily an easy problem.

Different formatters for Kotlin

Besides ktlint, there are other formatters such as ktfmt, kotlin-auto-formatter and the IntelliJ auto-formatter.

Some of the options have some downsides in my opinion:

  • ktlint: as mentioned before, it doesn’t automatically wrap lines
  • kotlin-auto-formatter: doesn’t seem to be well maintained (at the time of writing, the last commit was 14 months ago)
  • IntelliJ auto-formatter: formatting shouldn’t depend on an IDE and should be applied through the CLI, which enables tools such as CI checks.

This leaves us with ktfmt, which according to kotlin-auto-formatter doesn’t conform to the Kotlin coding conventions. Kotlin is a very opinionated language in its conventions. It is a clear downside that ktfmt doesn’t conform and on top of that, it offers virtually 0 configuration. The reason for this is that it builds on top of google-java-format. But all in all, it does look like something worth investigating further.

In the context of this article, I did a deep dive into the documentation of google-java-format. From the documentation, I learned about 🔖 The Rectangle Rule in Code Readability and wrote down a couple of learnings from code formatting that can be applied to the entire discipline of software engineering.

Conclusion

There are different formatters in the Kotlin ecosystem, each having its pros and cons. I prefer ktfmt, which is based on google-java-format. It’s interesting to see how complex a relatively easy problem like formatting becomes once you dig deeper, but some learnings can be applied to all of Software Engineering.