Sign in to follow this  
Chad Smith

Coding Style: Curly Braces

Recommended Posts

japro    887

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

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

Share this post


Link to post
Share on other sites
0r0d    1932

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.

Share this post


Link to post
Share on other sites
Vortez    2714

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

Share this post


Link to post
Share on other sites
0r0d    1932

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?  wink.png

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

Share this post


Link to post
Share on other sites
Cornstalks    7030
I wonder what this thread would be like if people were talking about Racket/Scheme instead:
#lang racket
 
{define {foo bar}
  {if {= 5 bar}
      {display "It was 5\n"}
      {if {not {= 42 bar}}
          {display "It was something else\n"}
          {display "It was The Answer\n"}}}}
 
{foo 15}

Share this post


Link to post
Share on other sites
L. Spiro    25622

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

Share this post


Link to post
Share on other sites
slicer4ever    6760

I wonder what this thread would be like if people were talking about Racket/Scheme instead:

#lang racket
 
{define {foo bar}
  {if {= 5 bar}
      {display "It was 5\n"}
      {if {not {= 42 bar}}
          {display "It was something else\n"}
          {display "It was The Answer\n"}}}}
 
{foo 15}

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

Share this post


Link to post
Share on other sites
Chad Smith    1343

Even though I said I have a hard time reading when the braces are on the same line in my original post when asking the question, I will say as long as the style STAYS consistent (and the style is actually possible for a human brain to read and understand in the first place lol) throughout the code base then I really don't have much problem reading it.  Much of a code style is how consistent it is.  Then again could it even be called a "style" if it is not consistent?

 

Cornstalks: don't know any languages in the Scheme family, though what the heck is defining a scope or what is a scope in that family of languages?

Share this post


Link to post
Share on other sites
_the_phantom_    11250

How is that bad? People tend to scan 90% by indentation levels, and since bad indentation will screw up anyone in either style it is always necessary for indentation to be consistent.

Really?
90%
Citation needed.

I know that my scanning method does braces matching to establish extent of code blocks rather than relying on indentation to delimit which is why when people include the opening brace on the same line as the function/if/whatever my parsing speed drops noticeably while I am forced to scan whole lines to find the expected token.

Also...
void function(type param)
{
    // here is some code
    // here is some code
    {
       // here is some code
       // here is some code
    }
    // here is some code
    // here is some code
    {
       // here is some code
       // here is some code
    }
}
... separate line braces is consistent, spacing and visually, with scope introduction which is an idiom I use often and in that compact form.

So... yeah... 90%? Really? I call Bullstat.

Share this post


Link to post
Share on other sites
L. Spiro    25622

Really?
90%
Citation needed.
[…]
I know that my scanning method does braces matching to establish extent of code blocks rather than relying on indentation to delimit which is why when people include the opening brace on the same line as the function/if/whatever my parsing speed drops noticeably

How much does your scanning speed drop when indentation levels are off?


L. Spiro Edited by L. Spiro

Share this post


Link to post
Share on other sites
Cornstalks    7030


I wonder what this thread would be like if people were talking about Racket/Scheme instead:

#lang racket
 
{define {foo bar}
  {if {= 5 bar}
      {display "It was 5\n"}
      {if {not {= 42 bar}}
          {display "It was something else\n"}
          {display "It was The Answer\n"}}}}
 
{foo 15}


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


A little bit of both. Racket has the "feature" that it doesn't care about what kind of braces you use so long as the opening and closing match (so [] and {} and () are all the same). That code would normally be written using parentheses instead of curly braces, but I used curly braces to make it relevant to the thread.

Cornstalks: don't know any languages in the Scheme family, though what the heck is defining a scope or what is a scope in that family of languages?

Uhhh... the braces (which in normal code would be parentheses). In Racket/Scheme, the parentheses go before the function name, not after (so in C it's foo(), but in Racket it's (foo)). I won't go into the syntax too much, but there's sane scoping. It's just a weird syntax.

Just to show you what kind of horrible stuff you can do, you could write a simple program to print out "hi" a bunch of times, and instead of using the idiomatic parans, you can use non-idiomatic stuff:
(define (<>) (display "hi\n") <>)
[[[{{[{[{[{{(((({({({(({[[{{{((((<>))))}}}]]}))})})}))))}}]}]}]}}]]]
; prints ~32 lines of "hi"
So yeah... I don't care what kind of indentation you use in your C-style code, so long as you're consistent. Edited by Cornstalks

Share this post


Link to post
Share on other sites
0r0d    1932

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.

You missed the point I was trying to make about consistency, but I'm not going to repeat myself.

 

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

Except I never claimed that what I was saying was a "fact".  I don't have to begin every sentence with "It is my opinion that" for a rational person to understand that what I say is by default an opinion, unless that sentence goes something like "It is a fact that...".  See the difference?

 

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

 

What I "see" is that you conveniently quoted me out of context, forgetting to include the parts of what I said where I give reasons and examples to back up my claims.

 

Yes, the preference for different styles is a matter of opinion, but I wasn't talking about that. 

 

BTW I also find it really funny that you go off and start lecturing me about people's opinions, and then threaten me if I dare to give my opinion again.  Wow, the hypocrisy.   I'm also unclear what exactly you're threatening me with?  Please feel free to elaborate.

Edited by 0r0d

Share this post


Link to post
Share on other sites
mhagain    13430

The more I see this the more I come to realise that what I actually scan by is neither the braces nor the indentation, but the (mostly) blank line before and after.  Am I a whitespace nazi?  Probably.  Do I care overly much?  No.  Why am I still talking about this?  Because it's quite interesting to read arguments from a perspective that's not my own.

 

What makes all of this really silly is that everyone can just run code through their favourite formatter and get it the way they want, then do the same again to put it back to another way.  The very existence of formatters makes any enforcement of styles/standards fairly redundant I'd think.

Share this post


Link to post
Share on other sites
SiCrane    11839
Well the problem with automatic formatters is that they often don't deal well with indentation that isn't specifically related to scopes and braces. For example code like:
if ( (a && b) ||
     (c && d) ) {
  e = really_long_line +
      something_else +
      something_else_entirely;
}
Sometimes they'll preserve the spacing in second, fourth and fifth lines, sometime they won't. For example, the MSVC IDE will assume that you wanted the additional spacing on a multiple of the tab stop (or at least I think that's the logic behind how it mangles my code). And there's very few things more annoying than seeing a commit where most of the changes are just whitespace differences like when something is run through a bad formatter and then back. While I wish we were at a point where tools made this a moot point, I still just suck it up and work with whatever style the file was originally in.

Share this post


Link to post
Share on other sites
superman3275    2061

For the first 1-2 years of programming, I leaned toward the first style. Now, after learning a fair amount of Java and many other languages, I prefer the second style.

 

Granted, this is a personal preference and neither is inherently better, so this post will probably turn into a flame war.

 

Cheers :)!

Share this post


Link to post
Share on other sites
Dwarf King    2126

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

 

Are you getting married? A great congratulation from me smile.png Always great to read some good news around the net. Oh back on topic...

 

Personally I prefer this style:

if(something)
{
    Something
}
else
{
  something
}

 

 

Like many other have showed. Good or bad style is not an issue for me. This style is just what makes my eyes happy smile.png

Edited by Dwarf King

Share this post


Link to post
Share on other sites
froop    642

I always used to use the first style and hated the second style. But at work we're using the second style and guess what, I got used to it within minutes and it makes absolutely no difference to me.

Share this post


Link to post
Share on other sites
Phil123    1276

I generally prefer things like this:

 

 

if (something)
    ;
else
    ;
 
if (something)
{
    if (somethingElse)
      ;
   else
      ;
}
 
for (int i = 0; i < someNumber; i++)
{
   if (something)
   {
      if (somethingElse)
         ;
      else
         ;
   }
}

 

But I would never:

 

 

if (something) {
    ;
}

 

As going back and checking to ensure all the braces are in their correct spot would be tiresome.  It's far easier to double check when they're all vertically lined up.  (Though this is my own preference.  If I got paid to do it in some weird way, then so be it).

Edited by Phil123

Share this post


Link to post
Share on other sites
Tom KQT    1704

I use both styles, but I am still consistent in it, although it may sound weird smile.png

I use the following only for class definitions, functions definitions, namespaces and these sorts of "top level" blocks:

void myFunction() 
{
   int a = 1;
}

And the following for if, for, while and other similar blocks:

if (a == b) {
   a++;
   b--;
}

And btw, for one-line if blocks i usually use this:

if (a == b)
   a++;
Edited by Tom KQT

Share this post


Link to post
Share on other sites
kunos    2254

I used to be pretty religious about this.. and I was following the style in the first example, I thought the code in the second style was impossible to follow quickly.

The I started to code in Go, that forces the second style on you, and after few days I was just as comfortable as I could.

So now my C++ code uses style 1 and my Go code uses style 2... style 2 generates a more "compact and intense" code imo... and I still stand that style 1 outlines the block logic better, but at the end of the day, it doesn't really matter.

 

I also enforce using curly brackets for 1 line blocks all the time.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this