Feature Request: Remove Curly Brackets

[dalewking]

@arocnies

I find code much easier to read when the brace is on the same line–hear me out because this was not my opinion before I started using Kotlin.

I used to think there it was all preference, and I used to strictly prefer the opening brace on its own line. When I started coding in Kotlin I quickly found myself switching to the same-line style. It appeared cleaner when coding in Kotlin. For Java, I continued to use next-line awhile until I finally had to admit I had become a filthy same-liner and no longer preferred next-line.

It’s not just preference.

I have written about this so many times (feel free to look for posts on the google groups of mine from the early 2000s), so let me give you the tl;dr version.

• I agree it isn’t preference and your preference is immaterial. Readability is objective and can be measured.
• How would you measure it? Test a bunch of programmers with samples of both styles and measure the speed and accuracy of their interpreting the code and see which style leads to faster and more accurate interpretation of code on average.
• Has it been measured? No, but we can do some simple reasoning about what the results would be.
• What is the point of either style? The point is to give visual clues that at a glance you can see control flow structure of the code.
• The thing before the brace and after the brace are fundamentally different and do not represent just 2 sequential statements that are always executed one after the other. E.g. the code within the if may not get executed at all so we want to make it very clear visually that we are not dealing with just 2 sequential statements.
• So the more you distinguish for example the if condition and code within the if the more clues you are providing to the reader of the code (within reason)/
• One side basically thinks you only ned to distinguish it by indentation (since the brace is hidden way at the end of the line and not easy to spot.
• One problem with that philosophy is that if conditions often span multiple lines and normal statements also span multiple lines so don’t look that different.
• I believe it is actually more about the whitespace separation by putting a nearly blank line. Have you every had a complicated if conditional or method declaration and put a blank line to separate it from the body even though you follow the hidden brace style? If so then you agree that vertical whitespace separation makes it easier to distinguish. I know I have seen a lot of code that does this and I basically say then that they are hypocrites.
• In addition to the vertical space separation the brace on that line makes it very easy to find where the body begins. it forms a frame around the body.
• So since the brace on its own line style makes it easier to distinguish the body from the if, for, method declaration, etc., it is hard to argue that making it more clear does not make it more readable.
• I don’t just stop there and my style is that any control flow statement (for example the if itself) has a blank line before it (unless the line before it is a brace on its own line) to distinguish that it is not the same as the statement before. Similarly the closing brace should always have a blank line after it (unless the next line is another closing brace).

@arocnies

Trailing closures mix beautifully with the same-line style:

fun doTheThing() = things.forEach {
    ... // Can't place that brace here.
}

Which I complained about 2 years ago in my third post on these forums. That is why I write that as

fun doTheThing() = things.forEach()
{
    ...
}

Which, until the current version of Kotlin (1.2.50), generated a lint warning about unnecessary parentheses but is now fixed thanks to my bug report about it.