I also never use non-braced blocks. They only cause confusion and leave the potential for future problems, especially when adding debug code to print values or just later updating code to do more than a single statement of work.

I prefer to keep my opening braces on the same line. It feels cleaner and it reduces the use of vertical real-estate.

I personally don’t understand the main reason people put them on their own lines, which is that they are easier to pair up with the closing brace.

When I am scanning up from a closing brace to its opening brace, I go by indentation level and nothing else, so it doesn’t matter if there is specifically an opening brace at the same level as the closing brace or if it is an if, while, for, function declaration, etc.

Scanning only based on indentation levels keeps things simple and it means that code where braces are on their own lines is just as easy to read for me as any other style.

It is a huge problem when trying to read code that has not been indented consistently, but we can all agree that is a no-no. Regardless of your bracing style, proper indentation is necessary.

But in practice I use whichever style is necessary.

In my own works, it is necessary (by the law of satisfying one’s own taste) to keep them on the same lines as the if/while/etc.

At the office, the general style is to put them on their own lines. They aren’t so picky on that but I do it just to keep the code as consistent as possible, because that matters much more than which brace style you use.

Yeah. Indentation is the main thing. Anime-Planet changed the format of a table in their user-page anime listing and I spent an hour making a 5-minute fix to a greasemonkey script last night because the html is indented using what appears to be the shotgun whitespace method. Finally I just copied out the page source into SciTE and corrected the indentation and everything became clear....

Well...

As clear as JS DOM gets, anyway.

Edited by Khatharr, 16 April 2013 - 11:27 PM.

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.

But during university I was taught that I should always use curly braces and I should always comment everything - my lecturer was pretty strict with coding styles and marked us on the style instead of the code itself. Since leaving my coding style has changed from above to..

// Used to check if x is equal to 0
if (x == 0)
{
x = 5; // give x the value of 5
}
else // if x is not equal to 0 then do this
{
x = 4; // give x the value of 4
}

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)

Easy there, trigger.

EDIT:

By the way, I've never asked anyone this because I've rarely had anyone else read my code, but I wonder if this habit I have is a case of "overcommenting." Basically, I keep the opening brace on the same line, and I always comment the closing brace, even if it's really really obvious. It helps me with re-reading my code, but I do sometimes wonder if another programmer might think I'm overdoing it haha. For example:

// Used to check if x is equal to 0
if (x == 0)
{
x = 5; // give x the value of 5
}
else // if x is not equal to 0 then do this
{
x = 4; // give x the value of 4
}

The only comment I want in that code is one explaining what `x' means, and why it makes sense that up to that point in the code values like 0 or something else made sense, and after that point in the code 4 and 5 make sense. Separating x into two variables (one for whatever it represented up to that point in the code and one for whatever it represented after that point in the code) and giving them good names would result in code that is much more readable than that horrible thing you just posted.

By the way, I've never asked anyone this because I've rarely had anyone else read my code, but I wonder if this habit I have is a case of "overcommenting." Basically, I keep the opening brace on the same line, and I always comment the closing brace, even if it's really really obvious. It helps me with re-reading my code, but I do sometimes wonder if another programmer might think I'm overdoing it haha. For example:

I actually started doing that recently because it really helps clear up the end of a 4- or 5-level nested loop if you want to add to it later. After using lisp in college, I made a habit of always writing my opening and closing brace/parens IMMEDIATELY, and then adding the content inside. This leads to chains of closing braces at the end of some of my more workhorse functions or complex algorithms and it's really nice to have the tags via comments to see where you want to jump in to do something "inside loop 2 but post switch case".

Also, in general to the thread, I ALWAYS brace my conditionals, even if they're on one line. I've had too many stealth bugs creep in because I had skipped braces on a one-line if statement and added a second instruction.

By the way, I've never asked anyone this because I've rarely had anyone else read my code, but I wonder if this habit I have is a case of "overcommenting." Basically, I keep the opening brace on the same line, and I always comment the closing brace, even if it's really really obvious. It helps me with re-reading my code, but I do sometimes wonder if another programmer might think I'm overdoing it haha. For example:

I actually started doing that recently because it really helps clear up the end of a 4- or 5-level nested loop if you want to add to it later. After using lisp in college, I made a habit of always writing my opening and closing brace/parens IMMEDIATELY, and then adding the content inside. This leads to chains of closing braces at the end of some of my more workhorse functions or complex algorithms and it's really nice to have the tags via comments to see where you want to jump in to do something "inside loop 2 but post switch case".

Also, in general to the thread, I ALWAYS brace my conditionals, even if they're on one line. I've had too many stealth bugs creep in because I had skipped braces on a one-line if statement and added a second instruction.

I too automatically create the open and closed braces for bodies of code and then go back in and put the code in the body.

I don't think putting a comment at the end of braces is a bad idea at all, especially if you have a lot of nesting and things going on. Whatever helps you and others understand your code easier is not a waste of time in my opinion as long as you don't over do it.

To me, this is the clearest way. Why waste a line, when it's clear that if you have proper indentation, the close bracket will always align with the statement that opens it?

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 even consistent with what you claim to be the reason for using it... namely because you dont want to "waste a line". I'm not sure why you think that packing your code together as much as possible is desirable (it's not), but if that's the case then why put the closing brace on a separate line? Why is "wasting" that line acceptable? By your logic, this is the code you should be writing:

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

No "wasted" lines there, and the brace placement is consistent... always at the end of the first/last line. And, of course if you really dont want to waste lines, then this is what you should be doing:

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

There you go, I just saved you 86% of the lines in that code block and made the brace placement perfectly consistent. You dont have to thank me.

Now, for those of us that dont want to pack code into an indecipherable brick, having braces on their own lines gives a natural break to separate sections of code for better readability, and has the advantage that braces are always aligned with each other, making the pattern easy to spot from a mile away. For example:

Here your brain can use its full pattern-matching abilities to easily spot discrepancies as quickly as possible. Finding bugs in code like this becomes extremely easy because you're not fighting your brain and intentionally obfuscating the code, you're actually using the code formatting to help in finding errors.

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.

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.

To me, this is the clearest way. Why waste a line, when it's clear that if you have proper indentation, the close bracket will always align with the statement that opens it?

The reason this style is bad is because it's inconsistent […] 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.

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.

The reason this style is bad is because [it] doesnt align the matching braces.

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.
So, when combined with the following quote of yours:

Now, for those of us that dont want to pack code into an indecipherable brick, having braces on their own lines gives a natural break to separate sections of code for better readability, and has the advantage that braces are always aligned with each other, making the pattern easy to spot from a mile away.

…the other side could question why you get so tripped up over such a small detail. Training yourself to spot specifically the opening brace rather than just anything on the same indentation level seems counter-intuitive and self-limiting. After all, you wouldn’t spot the opening brace unless it was on the same indentation level as the closing brace, so you wouldn’t spot that any faster than the other side would spot the if, else, while, for, etc. In fact it takes you more effort and time since you are apparently looking for one specific character, when the other side is looking for anything on the same indentation level. Once the other side finds anything on the same indentation level, they immediately say, “Ah, found it,” whereas you say, “Ah, okay is it an opening brace? Okay found it.”

The other side might then say that if you claim to spot things just as quickly as they do, then you aren’t truly looking for specifically an opening brace; you are going entirely by indentation level, since it is matter-of-fact that checking for specific characters is an extra step that can’t be done in the same amount of time by the same processor.
So then the other side would question why the brace needs to use an extra line on its own if it is not actually helping you align things with closing braces. Then it becomes quite obvious that you can’t actually say it has any justifiable purpose, but rather just that you prefer it to be on the same level as the closing brace, as a matter of your own personal taste and nothing more.

This gives the other side a legitimate claim to it being a waste of space. By their logic, it serves nothing more than to placate your personal taste, but with the downside of moving a few lines of code off the bottom of the screen. That doesn’t mean they want the code as compact as possible, but that they prefer to choose where to compact it or where to not.

Blank lines were added to make logical separations between segments of code, and a 2-line comment added for clarity on the return.
The other side won’t see a purpose in adding an extra line after the function declaration just for the brace because it doesn’t improve readability in any way—blank lines were added in strategic places rather than religiously at the start of the function, and it is very clear where the function body begins based on indentation levels alone.

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()) { /*...*/ } } }

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.