Coding Style: Curly Braces

Started by
72 comments, last by kunos 10 years, 12 months ago

My method is similar to the one CornStalks mentioned, with minor differences.

For simple single-line statements, I'd go without brackets:

if(...) //simple single-line statement
if(...) //simple single-line statement
But if they are chained ('else-if' or 'else'), I make the entire chain use brackets:
if(...)
{
    //...more complex statements....
}
else if(...)
{
    //...more complex statements....
}
If an 'if' is stand-alone, but is multi-lined, or even single-lined but cluttered, I'll fully brace it.
Or, even if the statement itself is simple, but the conditional is more complex, I'd brace it.
if(x == foo && y == (N - 7)
|| z == PI)
{
    //Fully braced, because of non-simple conditional.
}


I'd say always use brackets and on new lines, you never know when you want to extend an if or else clause in the future with additional code. If it is a simple statement use a ternary operator for it, if you really wanna keep it on one line.

Btw here is the insomniac coding guide line and this is or something very similar (mostly comes down to camel casing on members and local variable declarations that's different) is used in a few places: http://www.insomniacgames.com/core-coding-standard/

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max, Watch Dogs: Legion

Advertisement

I personally find the second style incredibly difficult to read at more than 1 indentation level because when identifying blocks of code I visually match the opening and closing brace; having them lined up in the same column is essential to me.

I value that over vertical real-estate any day; plus with Visual Studio you can auto-hide all the little pop-up panels anyway, which - when coupled with the fact that larger monitors are quite cheap these days - somewhat lessens the arguments in favour of the second.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.


if( sOpinionQuery == "curly_braces_style_preference" )
{
	gamedev.curThread.post( this );
	gamedev.curThread.value += 0.02; // my two cents.
	gamedev.desiredFeatures += "forum polls";
}
else
	OneLiner();

I personally find inline braces really hard to read when there's more than a few lines of code. I'ts much easier to identify code blocks when the braces match virtically.

The first style is much easier to read. I use curly braces anytime there is a block of code inside of something. I find the second way VERY difficult to read. The curly braces inline with the thing they are forming the body of, and everything inside that body is indented.

if( a == b )
{
     if( a == c )
     {
          if( a == d )
          {
                do stuff
          }
     }
}

guess this is just a question out of interest in what people prefer to read and/or write code (we all want to read code that looks exactly like our style I'm sure).

Curly Braces. When do you use them? I know a lot of our personal coding styles can come from the places you learned from then we develop our own style later on. Maybe the curly braces is just something people use a certain way because it's how they were always taught so they always saw code that way.

I myself always tend to do the following:


void SomeFunction(int x)
{
     if(x > 10)
     {
          // Do something
     } 
}

This style is the best one. The reasons are that it's self-consistent and aligns the braces with each other. If you're missing a brace it's easy to scroll down and see where it's missing. The human brain is great at pattern matching. Anything that helps the brain do its thing will help your productivity. Aligning and matching things that go together helps this.

This applies to braces, but also to any code formatting and alignment. Group similar things together and without even trying your brain will spot whatever is out of place... which many times will be a bug.

Another example:


void SomeFunction(int x)
{
	if	(x > 40) { /* ... */ }
	else if	(x > 30) { /* ... */ }
	else if	(x > 20) { /* ... */ }
	else if	(x > 10) { /* ... */ }
	else		 { /* ... */ }
}

What about using the best of both worlds?


int  doSomething(int x)
{     int y;
      // ... do complex operation
      return y;
}

      

Using the first style makes you a better coder since less code fits on the screen so you have to write more concise code and break functions into pieces earler :p

(I prefer the first style mainly out of habit but always adapt to existing codebases)

What about using the best of both worlds?


int  doSomething(int x)
{     int y;
      // ... do complex operation
      return y;
}

      

This can be tedious to format if you don't have smart tabbing functionality (though I agree this is a weak argument). But it just looks so wroooooooooooong...

Personally I've always used the first style because it is much more consistent to me, and clearly delimits scopes. Sure, it might take up a few more lines of code, but the curly braces are neatly on the same indentation level, rather than having one of the curly braces placed at the end of an arbitrarily long statement.

I also like the Python way - do away with curly braces altogether - though it brings its own set of issues (is this a tab or a space?)

This is kind of a subjective opinion, though, and it's best to go with what is already being used in the codebase since having two or more different coding styles competing with each other can be very frustrating. Though if you are starting a new project, you should definitely use the first style the style you and your team prefer.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

Personally I prefer the second style because it's the style I was trained with and I always feel 'jarred' when I see a whole line used up by an open brace. It just makes me want to scream 'Mottainaiiiiiiiiiiiiiiiiiiiii!'

That said, when alone you do what you want. When you work with others do what they do.

Actually, though. I do have one 'odd' habit that would probably get me smacked by some people.


if(condition) {
 //dostuff on more
 //than one line
}

vs

if(condition) {/*dostuff in one line*/}

I never use 'braceless' blocks. To me it's just begging for trouble. On the other hand, I'll use that second style there so long as it doesn't make the longer than about 60 characters.

Oh, that's another thing. I'll break up compound statements to try to keep every line shorter than a certain length so that I don't have to mess with horizontal scrolling.

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.

This topic is closed to new replies.

Advertisement