• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Chad Smith

Coding Style: Curly Braces

73 posts in this topic

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

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites
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}
0

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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?

0

Share this post


Link to post
Share on other sites

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?

1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites


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
1

Share this post


Link to post
Share on other sites

There aren't many studies (or none at all) on code style nor even project management styles (agile, xtreme programming, etc) as far as I know...

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites

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 :)!

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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.

0

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  
Followers 0