Coding Style: Curly Braces

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

I 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
     } 
}



Though I do a lot of times see the style of:


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

I myself always seem to have "trouble" reading that if their is a lot going on. I'm sure it is mostly because I am still learning of course and developing my own styles that I am just not used to reading it like that.

I tend to use the first one because for me it helps me see and visualize the scope a lot better. I feel just by taking a quick glance at it I can tell you which scope I am in and have no problem.

What style do you tend to use and like better? What are you reasons you chose that specific style for curly braces?

Advertisement

I prefer the first one as well. Like you said, I think it's much easier to quickly visualize how blocks are nested. I tend to use curly braces even for one line blocks just because I find it easier to read. The biggest counter-argument I've heard is that you can fit more lines of code on your screen using the latter.

However, as you seem to be aware, it's a highly subjective topic that will cause a flame war as often as not. Here's the most "objective" answer you're going to get:

If you're programming by yourself, use whatever is easiest for you to read.

If you're creating something new that involves other people, agree on a set of standards when you're planning the project and stick to them.

If you're working with an existing code base, adapt to the existing code standards for that project.

If you are working with other people in a project, do what they do. That's really the only rule we follow in my company, and over time we have developed a pretty uniform style of code formatting, without ever having to argue over any of this.

In the specific case of curly braces, we use the latter style, which I prefer because I value vertical real estate in programming. But either one is fine.
If I have code on multiple lines, I always use braces. But if the code can comfortably fit on one line, then I use no braces (and only one line). For example:
// The following comfortably fits in one line, so I put it on one line with no braces:
if (x < 0) x = 0;
else if (x > 100) x = 100;

// The following doesn't comfortably fit on one line, so it goes on multiple lines with braces:
if (someObject.getPosition().x < 0)
{
    someObject.setPosition(0, someObject.getPosition().y);
}
else if (someObject.getPosition().x > 100)
{
    someObject.setPosition(100, someObject.getPosition().y);
}
I also put braces on their own line.

But I don't get too religious about it, and if I'm working on a project that uses a different convention I'm fine doing it (like K&R style). I like the vertical real estate that putting braces on the same line as the code saves, but I also like the spacing/formatting that putting braces on their on line gives, which is why I think I can easily switch between styles depending on the conventions of each project. I've learned to find the positives in various styles, and if I'm working on a project where I can't set the coding conventions, I focus on the positives of the chosen style which has helped me get over the religiosity of braces.
[size=2][ 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 ]

The first style is my personal preference aswell. And for the reason you mentioned, it makes everything a bit clearer, adds that extra spacing between lines, and allows quick identification of which braces are paired, and where nesting occurs.

I did dabble in the second type, when I thought less lines = the way to go! But after a while it became a slight headache. Again, it's personal preference to the coder and one persons style may not suit another. But, think about people reading it later, I want them to be able to read it as clearly and concisely as possible.

There is also the usage of no braces being used. This occurs if an 'if' statement is only intended to trigger 1 function.


if(someClauseIsTrue)
      fireThisFunction();

I also used to do this, but again, it becomes a bit of a headache when you quickly skim it.

Regards,

Stitchs.

personally i prefer the second approach, i don't really see the point in putting the initial brace on its own line when the indentation makes everything clear anyway. (Python does just fine without any braces at all, in-fact i wouldn't mind if C++ ditched the braces completely in the next version of the standard and switched to using indentation to set the scope)
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
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 used to code like this

void MyFunc()

{

int x = 2;

}

But then I read a book called Code Complete 2nd ed. And it gave a great explaination why that style is bad and the other 2 styles that are good. So now I code like this

void MyFunc()

{

int x = 2;

}

This style really pays off in complex nested loops and if statements, because you look straight down the braces and everything at that tab depth belongs to the line above, no question about it. The first style breaks down and gets very confusing within complex code.

The other style the book said was good was

void MyFunc() {

int myInt = 2;

}

After comparing the 2 the straight line block of the 1st suggested method is much easier to read. And thats what it is really about, making sure that your blocks are clearly defined so your brain can easily figure out the scopes and owner of blocks.

If this post or signature was helpful and/or constructive please give rep.

// C++ Video tutorials

http://www.youtube.com/watch?v=Wo60USYV9Ik

// Easy to learn 2D Game Library c++

SFML2.2 Download http://www.sfml-dev.org/download.php

SFML2.2 Tutorials http://www.sfml-dev.org/tutorials/2.2/

// Excellent 2d physics library Box2D

http://box2d.org/about/

// SFML 2 book

http://www.amazon.com/gp/product/1849696845/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1849696845&linkCode=as2&tag=gamer2creator-20

If I have code on multiple lines, I always use braces. But if the code can comfortably fit on one line, then I use no braces (and only one line). For example:


// The following comfortably fits in one line, so I put it on one line with no braces:
if (x < 0) x = 0;
else if (x > 100) x = 100;

// The following doesn't comfortably fit on one line, so it goes on multiple lines with braces:
if (someObject.getPosition().x < 0)
{
    someObject.setPosition(0, someObject.getPosition().y);
}
else if (someObject.getPosition().x > 100)
{
    someObject.setPosition(100, someObject.getPosition().y);
}
I also put braces on their own line.

But I don't get too religious about it, and if I'm working on a project that uses a different convention I'm fine doing it (like K&R style). I like the vertical real estate that putting braces on the same line as the code saves, but I also like the spacing/formatting that putting braces on their on line gives, which is why I think I can easily switch between styles depending on the conventions of each project. I've learned to find the positives in various styles, and if I'm working on a project where I can't set the coding conventions, I focus on the positives of the chosen style which has helped me get over the religiosity of braces.

I have noticed I too seem to use only one line if it can easily fit on one line and be easily read.

Thanks for the reply everyone. I know I just need to use what I like for personal projects find a consistent convention when working with teams. Just interested what people used for their convention for curly braces since I see a lot of different styles for them. Not meaning to start flame war.

@EddieV223: huh.png

Either my humor-detector broke again (very likely!), or you misread the book.

Code Complete 2nd Edition says your first method is the good one, and the other two are bad, and explains why.

*pulls down the book to double-check*

Huh, I'm mistaken - It does seem to say that (page 742).

I'll have to reread the book soon - it's been several years.

This topic is closed to new replies.

Advertisement