• Create Account

# Coding Style: Curly Braces

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

73 replies to this topic

### #41mhagain  Crossbones+   -  Reputation: 11892

Like
0Likes
Like

Posted 18 April 2013 - 04:57 AM

It seems to me that the main reason being put forward for preferring K&R (or similar) is saving space, but don't you think that this is a case of seriously getting things entirely the wrong way around?  The purpose of a coding style is not to save space or to look pretty, it's to make code easier to read (because reading code is harder than writing code), to make wrong code look wrong and to make right code look right.

If we can all agree, or mostly agree, that a certain style is harder to read or fails in the other main criteria, then we should by definition also all agree (or mostly agree) that any other advantages that style may have are of reduced (or no) importance.  If a given style takes 50% longer for a person to read and parse then that's time wasted for that person (and why obsess over saving a few blank lines if it comes at the cost of wasting someone's time?)  If a given style makes right code look wrong (or worse - wrong code look right) then that style is obviously at best flawed, at worst completely broken.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

### #42L. Spiro  Crossbones+   -  Reputation: 24023

Like
0Likes
Like

Posted 18 April 2013 - 05:30 AM

It seems to me that the main reason being put forward for preferring K&R (or similar) is saving space, but don't you think that this is a case of seriously getting things entirely the wrong way around?  The purpose of a coding style is not to save space or to look pretty, it's to make code easier to read (because reading code is harder than writing code), to make wrong code look wrong and to make right code look right.

See my previous example.

	LSUINT32 LSE_CALL CTime::GetConstantStepUpdateTimesFromTicks( LSUINT64 _ui64Ticks, LSUINT32 &_ui32UnitsToNextUpdate ) {
LSUINT64 ui64TimeNow = GetRealTime();
LSUINT64 ui64Dif = ui64TimeNow - m_ui64LastRealTime;

LSUINT32 ui32Count = static_cast<LSUINT32>(ui64Dif / _ui64Ticks);
m_ui64LastRealTime += ui32Count * _ui64Ticks;

// Determine how far this update lands between two other updates at the same fixed interval,
//	in units of 1 1,000th.
_ui32UnitsToNextUpdate = static_cast<LSUINT32>(((ui64Dif % _ui64Ticks) * 1000ULL) / _ui64Ticks);

return ui32Count;
}

If it were easier to read to put a blank line I would put one there. While keeping the brace on the same line as the function declaration.
It isn’t truly about saving space; that is just a simplification. It’s about deciding where blank lines go based on actual considerations for the code at hand rather than just following a “rule” (note that it is not meant to be such a rule but many make it out as such just as many over-simplify K&R as aiming to save space) which may or may not be appropriate for any given code block.

Again, strategically placed blank lines certainly do improve readability, but there is no rule or even a remote human consensus that blank (or lines containing only opening braces) improve readability in all cases after function headers, if’s, else’s, while’s, for’s, etc.

I personally believe that a blank line after a namespace declaration is universally easier to read.
So I put a blank line there. You could instead choose to put an opening brace on its own line there, but that is nothing but personal preference.

L. Spiro

### #43mhagain  Crossbones+   -  Reputation: 11892

Like
0Likes
Like

Posted 18 April 2013 - 05:57 AM

On the other hand, you've got this:

if ((a || b) && (c || d) && (e || f)) {
DoSomething ();
DoSomethingElse ();
}


Versus this:

if ((a || b) && (c || d) && (e || f))
DoSomething ();
DoSomethingElse ();
}


The second one here is wrong (and won't even compile, but that's by the by for now) but the wrongness doesn't jump out at you like it should.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

### #44Brother Bob  Moderators   -  Reputation: 9940

Like
0Likes
Like

Posted 18 April 2013 - 06:12 AM

if ((a || b) && (c || d) && (e || f))
DoSomething ();
DoSomethingElse ();
}


The second one here is wrong (and won't even compile, but that's by the by for now) but the wrongness doesn't jump out at you like it should.

It does jump on you immediately when the editor automatically indents the code.

    if ((a || b) && (c || d) && (e || f))
DoSomething ();
DoSomethingElse ();
}


### #45Azaral  Members   -  Reputation: 467

Like
0Likes
Like

Posted 18 April 2013 - 06:14 AM

On the other hand, you've got this:

if ((a || b) && (c || d) && (e || f)) {
DoSomething ();
DoSomethingElse ();
}


Versus this:

if ((a || b) && (c || d) && (e || f))
DoSomething ();
DoSomethingElse ();
}


The second one here is wrong (and won't even compile, but that's by the by for now) but the wrongness doesn't jump out at you like it should.

What would be even worse is if you have an open bracket somewhere before that and you are missing ITS' closing bracket. That errant closing bracket for that if statement would then take the place of the missing closing bracket for the previous one. Probably not terribly likely to happen, but if it did I bet it would be a pain to find.

### #46L. Spiro  Crossbones+   -  Reputation: 24023

Like
0Likes
Like

Posted 18 April 2013 - 06:45 AM

On the other hand, you've got this:

if ((a || b) && (c || d) && (e || f)) {
DoSomething ();
DoSomethingElse ();
}


Versus this:

if ((a || b) && (c || d) && (e || f))
DoSomething ();
DoSomethingElse ();
}


The second one here is wrong (and won't even compile, but that's by the by for now) but the wrongness doesn't jump out at you like it should.

Basically, both sides can point out rare edge cases, which is why the debate never ends.

Every style has edge cases. You get around them by coding right.
For example, C++ makes it easy to leak memory. To “code right” I either added the new and then immediately add the delete when I was young, or use RAII as I grew more experienced.
Likewise, I never miss braces because both the opening and closing brace are added together, before the body of the block is added.
I can see fairly easily then if I missed something. Such a mistake is actually glaringly obvious, and similar edge cases exist in all styles.

It’s really not related to formatting any more than writing a delete for every new as a pair is. Safe coding practices prevent this type of issue 99.9% of the time (and I can personally say I have never fallen prey to the example you provided; the only time in any style I have ever gotten mismatched braces was during refactors of heavily nested code, and while they were nasty, they would have popped up regardless of the style I chose).

L. Spiro

### #47slicer4ever  Crossbones+   -  Reputation: 5890

Like
0Likes
Like

Posted 18 April 2013 - 07:47 AM

On the other hand, you've got this:

if ((a || b) && (c || d) && (e || f)) {
DoSomething ();
DoSomethingElse ();
}


Versus this:

if ((a || b) && (c || d) && (e || f))
DoSomething ();
DoSomethingElse ();
}


The second one here is wrong (and won't even compile, but that's by the by for now) but the wrongness doesn't jump out at you like it should.

I've programmed in that style for a long time, it jumped out to me immediately, without any need for an editor to format it and before reading your last sentence pointing it out.  I understand the point you are trying to make, but having coded like that for a long time, such mistakes very rarity occur, and when they do, i'm not digging through a ton of code to find it, it's generally pretty quick and easy to discover.

Edited by slicer4ever, 18 April 2013 - 07:51 AM.

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

### #48l0calh05t  Members   -  Reputation: 1484

Like
0Likes
Like

Posted 18 April 2013 - 08:19 AM

It's obviously personal preference, but I very much prefer the first type (and leave away braces for single line statements... when I'm feeling evil that might include using a comma operator) because I find it much more readable and despise the javaesque second style.

Addendum: If speed doesn't matter, I'll much rather choose the python no-braces style (tabs only for indents!), though this practically enforces the second brace style for implicit line continuations due to parentheses, braces and brackets.

Edited by l0calh05t, 18 April 2013 - 08:25 AM.

### #49Bearhugger  Members   -  Reputation: 1272

Like
1Likes
Like

Posted 18 April 2013 - 08:39 AM

Both coding styles are fine and I would be fine using either. The only style I cannot stand is the GNU style of having half-indented braces. Very annoying to maintain, and if a real TAB slips through the code it's going to look real ugly with different tab settings.

Coding style is a programmer's signature. If you get to call the coding style to be used (or if it's your own personal project) pick a style you like and stick with it, consistency is more important here.

That being said, personally, I have a preference for putting my opening braces on their own line because it makes the blocks pop out more. I already put a lot of white lines in my code to separate the logical "sub-tasks" of a function, and a condition block of a few lines is definitely a sub-task that I would white-line anyway, so putting the brace on its own line feels more consistent and natural with my coding style.

It also serves to separate the condition from the blocks. For short conditions this is a non-issue, but for long conditions that span on multiple lines it becomes harder to quickly spot where the condition begins without that empty white line.

### #50MichaBen  Members   -  Reputation: 481

Like
0Likes
Like

Posted 18 April 2013 - 10:56 AM

if ((a || b) && (c || d) && (e || f))
DoSomething ();
DoSomethingElse ();
}


The second one here is wrong (and won't even compile, but that's by the by for now) but the wrongness doesn't jump out at you like it should.

Then again, you can make the same example like this:

if ((a || b) && (c || d) && (e || f));
{
DoSomething();
DoSomethingElse();
}

And this will not even generate a compiler error, maybe a warning. Truth is I don't think a bracket style will prevent human errors in the code, as no matter where you place them, a single mistyped character can break them.

Personally I prefer to use indention over brackets to see the structure of a code, it's must faster to scan code by indention level then by looking for the tiny brackets. Also modern IDEs are more then capable of visualizing scopes for you, for example in QtCreator:

### #51Khatharr  Crossbones+   -  Reputation: 6814

Like
0Likes
Like

Posted 18 April 2013 - 02:09 PM

Just a minute. I'm working on a solution for this.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

### #52mhagain  Crossbones+   -  Reputation: 11892

Like
0Likes
Like

Posted 18 April 2013 - 03:32 PM

Oh, no need.  We're having quite a civilized discussion here.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

### #53japro  Members   -  Reputation: 887

Like
0Likes
Like

Posted 18 April 2013 - 03:42 PM

Oh, no need.  We're having quite a civilized discussion here.

Well that is exactly the problem which he is trying to solve, right? FIGHT! WOHOOOO!

### #540r0d  Members   -  Reputation: 1511

Like
0Likes
Like

Posted 18 April 2013 - 07:39 PM

The reason this style is bad is because it's inconsistent and doesnt align the matching braces.  The opening brace is at the end of the first line of the code block, while the closing grace is inexplicably on its own line after the code block.  No consistency whatsoever.  Since you're aligning the end-brace with code instead of an open-brace, that open brace might not even be there and you'd never notice until the compile fails, which might be a significant amount of time wasted on big projects.

It's not bad. It's just not the style you use. The end brace matches the block owning statement. It reads very naturally to people who prefer that style.

And how exactly do you know what style I use?

I tried to make an argument based on logic, which if you actually read what I wrote, is why I gave concrete reasons for my claim.  I didnt just say "this style is bad, period".  Now, you can disagree with me, but please stop implying that what I'm saying is just because I'm biased.  That's just disrespectful.  Also, trying to tell me what I do or dont do is disrespectful.   You have no idea what style I use, or have used in the past, or will use in the future.

Yes, I understand that a certain style is easier to read for people who are used to that style.  I probably even said something like that in a previous post.  But I'm not arguing that you should change your style, I'm arguing for what style is technically better, so that people starting out will adopt that style.  A lot of people seem to take criticism of their personally preferred style personally, even if it's not intended as personal.

### #55Vortez  Crossbones+   -  Reputation: 2709

Like
0Likes
Like

Posted 18 April 2013 - 07:41 PM

Personally, i prefer this:

if(something){

...

} else {

...

}

It's more compact and i guess im used to it.

Also, i hate spaces between the ) and { , after the ( and before the )... it's rather pointless...

i soooo hate this freaking new tendency it make me want to stab every programmers who does it when i download code rofl...

... and yes, i love triple dots ^o^

Edited by Vortez, 18 April 2013 - 07:48 PM.

### #560r0d  Members   -  Reputation: 1511

Like
0Likes
Like

Posted 18 April 2013 - 07:59 PM

Consistency has to do with picking one style and sticking to it throughout the code base. It has nothing to do with braces being on the same indentation level.

Consistency also has to do with how you format your code.  If you put your braces in one place part of the time, and in another the rest of the time, then you're not being consistent.  Alignment is part of that because it creates a pattern, which is what I was trying to explain above... before people starting getting offended by me criticizing their "preferred" style.  Patterns are about consistency.  Yes, putting the braces in different parts of the code based on whether they are an opening or closing brace is also a pattern, but it's a more difficult pattern to spot.

I am offended that you use a style other than my own so let me twist your logic and write a totally out-of-context example:

if(f1()) {
if(f2()) {
if(f3()) {
/*...*/ } } }

Let me try to offend you even more by throwing all logic out the window and pretend the concept of indentation levels just doesn’t exist, even though I use them myself when scanning for matching braces:if(f1()) { if(f2()) { if(f3()) { /*...*/ } } }

I'm not offended by others making arguments for their preferred style, but apparently you are.  What does offend me is when someone implies that I'm being disingenuous in my arguments, and that what I'm saying is simply based on my bias.  In fact, I'm starting to see a pattern here.  I post an argument for why a certain style is technically better, and then all those who dont use that style rush to accuse me of being biased, and hence my argument isnt valid.  Nice!

Careful, someone might misunderstand that you are close-minded and stuck in your own ways, justifying them as “the best” based solely on the fact that it is what you prefer.

Of course, we all know better than that, right?

So I'm not just biased and disingenuous, I'm also closed-minded?  So many ad hominem attacks...  my post must have really hit a nerve.

Edited by 0r0d, 18 April 2013 - 08:00 PM.

### #57Cornstalks  Crossbones+   -  Reputation: 7022

Like
0Likes
Like

Posted 18 April 2013 - 08:38 PM

#lang racket

{define {foo bar}
{if {= 5 bar}
{display "It was 5\n"}
{if {not {= 42 bar}}
{display "It was something else\n"}

{foo 15}


[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

### #58Khatharr  Crossbones+   -  Reputation: 6814

Like
0Likes
Like

Posted 18 April 2013 - 09:29 PM

words

lol

Get in the dome.
void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

### #59L. Spiro  Crossbones+   -  Reputation: 24023

Like
1Likes
Like

Posted 19 April 2013 - 05:22 PM

Consistency also has to do with how you format your code.  If you put your braces in one place part of the time, and in another the rest of the time, then you're not being consistent.

Luckily, I always put opening braces at the end of the line and closing braces on their own line, making me quite consistent.

before people starting getting offended by me criticizing their "preferred" style.

Basically I can just stop here since you completely missed the point.

No one really cares enough to be offended, and many people are on your side.
So why were you singled out?
Because those people took an “it is my opinion” approach while you simply stated “X style is best” and “Y style is bad”.

This style is the best one.

The reason this style is bad

See?
All styles are a matter of opinion, so stop stating things as a matter of fact, or I will single you out harder next time. Trust me, I have been holding back in lieu of happy days and things going my way—getting married, getting a raise, getting back my motivation for my job (overcoming the phil67rpg disease) and technical work and my book, etc.

L. Spiro

### #60slicer4ever  Crossbones+   -  Reputation: 5890

Like
0Likes
Like

Posted 19 April 2013 - 05:26 PM

#lang racket

{define {foo bar}
{if {= 5 bar}
{display "It was 5\n"}
{if {not {= 42 bar}}
{display "It was something else\n"}

{foo 15}


o man, that's just insane.  is that actual regular syntax, or are you intentionally making it weird?

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS