Feature Request: Remove Curly Brackets

[arocnies]

You could change the braces to the same color as your background :

Settings | Editor | Color Scheme | Language Defaults | Braces And Operators | Braces then check the foreground box (and make sure it’s the same as the background).

Before:

After:

[alexb]

This is crazy too.
I guess this will confuse me alot

[qualityking]

I hate Python because it doesn’t have curly braces, and indentation sucks!
I would also suggest people who are some how trying to convert code to an english literature to change their profession or change technology like Python or VB.net

[alexb]

Yeah Python is not that great. Agree with you. But what do you think about Ruby?

[medium]

Besides all the mentioned concerns I want to add that at least I find curly braces easier to spot in the code. Most code consists of text and curly braces make a block more visible to me.

{ Maybe I’ve seen to many curly braces in my life, but I find this sign somehow beautiful }

[alexb]

Depends on the code. If you have a lot of functions and blocks, so the curly braces are everywhere.

[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.

[dalewking]

@alexb

@dalewking I really forgot an example with a return type. Well noticed. Ok, maybe it would look like this:

fun getName(): String?
  return name
end 

And if only all functions had no parameters and very simple return types then that wouldn’t be a problem. But in reality functions can take many complex parameters and have complex return types that can span an entire line by themselves.

I am not opposed to the concept of alternatives to braces but to me to be viable there needs to be a replacement for the opening brace as well, something like:

fun getName(): String?
begin
    return name
end 

but I find that less readable than:

fun getName(): String?
{
   return name
} 

because the braces stand out better

[alexb]

@dalewking

I am not opposed to the concept of alternatives to braces but to me to be viable there needs to be a replacement for the opening brace as well, something like:

fun getName(): String?
begin
    return name
end 

but I find that less readable than:

fun getName(): String?
{
   return name
} 

because the braces stand out better

Agree with you, that the second example is better readable than the first one. But I found it unnecessary to define a replacement for the opening-brace like ‘end’ because the end of function-signature defines the start of the function-body. Well if the function is simple. If not, there would be a keyword like ‘begin’ to define the start of the function-body. I don’t know if developers would complain that this would be too confusing or not. But on the other side, optional and alternative ways are always available. For example you can define directly a constructor to the class-name in Kotlin and remove the ‘constructor’-keyword if you want to.

I think placing the opening-brace in the same line is a modern thing. Back then they did it on the next line. So I have the feeling, everything is supposed to be more compact with the result that it is less readable. And it would be more innovative if languages would remove needless things instead of just shifting them.

[arocnies]

This was a really fun thread for a bit . I knew I’d said too much about braces style (I almost edited it out too).

@dalewking Thanks for filling in the other side of things. I still disagree though.
I’d rather not continue the braces discussion here. Even though I would probably enjoy sitting down and arguing braces style with you, I’m far more interested to discuss other Kotlin topics.

I guess I’m trying to say: That’s cool. I still think I’m right.

I’m always interested to see what you, Wasabi, Medium, and a few others post and I’d much rather read up on more exciting topics than tying you up in the braces debate

---

Just saw the new Jurrasic World movie, I think Jeff Goldblum was speaking on the braces debate when he said:

They were here before us, and if we’re not careful…they’ll be here after.

[Wasabi375]

I think there is one argument for braces not yet mentioned here. Well kind of. Dalewking already said that they stand out better but I think this is even more important if you have to read code in an editor without syntax highlighting. Yes in an optimal world this would never happen, but in reality it is sometimes practical to just open a file in a simple text editor instead of waiting half a minute for an IDE to start.
In that case braces are far superior to begin-end blocks as the keywords don’t stand out at all while special characters do. I guess this is also the reason why older languages started to use braces instead of begin-end.
Even though this situation is not common I think it is still important that languages are as readable as possible without special tooling.

---

@arocnies

Just saw the new Jurrasic World movie, I think Jeff Goldblum was speaking on the braces debate when he said:

They were here before us, and if we’re not careful…they’ll be here after.

I could say the same about Jurrasic Park movies (even if they call them Jurrasic World now) Although if they keep the quality of the first movie I won’t complain

[tieskedh]

First, I prefer braces far more.
But I’m not so sure about braces being far more superior.
First of all, the indentation should help with standing out.
Second, when you replace end with, but end and endif that gives way more information then a closing bracket.

[joffrey.bion]

@dalewking

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.

You are perfectly right that the brace-at-end-of-line philosophy is incompatible with conditions spanning multiple lines. However, I believe the problem here is not the philosophy, but rather the long condition!

Conditions should either be very short, or be extracted to a method so that the if statement reads like well written prose. That’s why I don’t need a (nearly) blank line because my conditions (and code in general) never wrap, and indentation always clearly delimit a block. Continuation indents are almost inexistent in the code style I try to follow.

@dalewking

And if only all functions had no parameters and very simple return types then that wouldn’t be a problem. But in reality functions can take many complex parameters and have complex return types that can span an entire line by themselves.

Well again, if the return type spans multiple lines, then maybe that is not readable enough to start with. We should either create a typealias or new type to solve this first problem, before putting the non-readability blame on wrapping styles.

@dalewking

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.

Now this part makes sense, although I believe that the body shouldn’t be long enough to need a “frame”.

To summarize, my coding style is to extract many code blocks as methods so that the code really reads well and all methods are short. In this style, there are many methods and blocks, and having a blank line is:

1. unnecessary, because blocks are short enough not to need a frame
2. harmful, because it means a lot more whitespace is added (compared to a style which prefers long conditions and blocks) and thus less lines of code are displayed on the screen, making it harder to browse

What’s your opinion about this?