After reading up on different formatters and getting deeper into ktfmt, I ended up at the google-java-format FAQ. This document explains the reasoning behind the design decisions of the formatting tool. It’s interesting how complex the problem of formatting becomes. Intuitively it is easy to see what good formatting is versus bad formatting, but it’s difficult to codify.
The Rectangle Rule
An example of a rule that attempts to codify readability is The Rectangle Rule.
To quote the article:
Formatting for this sort of abstract readability is not easily mechanized; it’s loose, not strict. Without more precise “big rules” for readability, we can end up with lots of “little rules”—don’t ever break a line here; don’t break there unless you absolutely have to—and all these little rules can easily interact in complex and confusing ways. Alternatively, if we can find a few big rules that produce readability, or that at very least promote readability, we can simplify writing a formatter, by using the big rules to reduce the number of special little rules that we must add.
In the context of the original article about Kotlin formatters, this was a wild tangent, but it’s an interesting thought. The quote is specifically about formatting, but it applies to the entire software engineering discipline in my opinion. There is a tendency towards getting a product out there and incrementally improving without ever taking a step back and looking at the bigger picture. With this approach, you very easily end up in a system with many “little rules” that will interact in complex and confusing ways. This can result in an unmanageable amount of complexity.
It’s important that in this process of incremental changes, you don’t forget to go through a refactoring step and try to find the “big rules”. Developers should in my opinion refactor more because sometimes you can only find the big rules after implementing a bunch of little rules.