Preferred curly brace placement and why.

[Dembadon]

Assume you're not forced to use a particular method.

Method 1:

void foo( giveMeThis ) {
   if( something ) {
      doThis;
   } else {
      doThisOtherThing;
   }
}

Method 2:

void foo( giveMeThis )
{
   if( something )
   {
      doThis;
   }
   else
   {
      doThisOtherThing;
   }
}

If you selected 'other', please provide an example.

 

[AlephZero]

IMO, just learn to love whatever your favorite IDE (or the IDE your employer insists that you use) does for free, when it reformats your code.

 

[DrGreg]

Method 2, because it's easy to see if the braces are balanced or not.

 

[DavidSnider]

Method 1. It irks me to have an entire line of screen real estate taken up by a single curly brace for some reason. It's one less line and I have never had any problems with the readability of it.

BTW, Method 1 is known as "The One True Brace Style" and Method 2 is known as K&R style.

 

[jtbell]

Method 2, because it's easy to see if the braces are balanced or not.

Ditto. It also makes it easier to cut/copy and paste a whole block of code.

 

[Dembadon]

IMO, just learn to love whatever your favorite IDE (or the IDE your employer insists that you use) does for free, when it reformats your code.

A friend of mine loves to use Xcode, and it's autocomplete feature is set to use method 1 by default. However, I'm not really a big fan of method 1 because it can scrunch the code together when you have control structures with statements long enough such that they're pushed onto the next line. I've used Xcode before, and I got around this by simply turning off the autocomplete functionality for brace placement. I normally just use Text Wrangler for writing code and g++ to compile it. If I do use an IDE, it's usually Bloodshed's Dev-C++. It's free and works well enough for the things I've been needing to do in my courses.

One thing I've noticed with different IDEs is the way they choose to format indentation when opening a file. Most of them have an option to reformat the code using whatever tab setting you want, but if they don't, it can really make of mess of things.

Method 2, because it's easy to see if the braces are balanced or not.

I agree. I also like the visual separation it creates between structures and code blocks.

[...]

BTW, Method 1 is known as "The One True Brace Style" and Method 2 is known as K&R style.

I thought it was the other way around.

 

[AlephZero]

The designers of Fortran 77 got this right IMO.

if (something) then
    doThis
elseif (somethingElse) then
    doThat
else
   doTheOther
endif

No variations allowed, since the line breaks are part of the syntax.

 

[jtbell]

Not only do you get rid of the curly braces, you get rid of those pesky semicolons, too! :!)

 

[Mark44]

I prefer method 2, for the reasons that DrGreg and jtbell give.

However, method 1 is the preferred method in Javascript programming, which I am doing more of, lately. In Javascript, method 2 can lead to unexpected results, due to the quirky nature of this language. I can't think of an example off the top of my head, but I'll dig one up and post it later.

 

[phinds]

This is a theological arguement. Hard core C programmers who learned at the knee of K&R's white book will prefer #1 for no better reason than that that's the way the masters do it.

To try to resolve this among several dozen programmers who worked for me some years back, I took the issue to NON-programmers and without exception they said that method #1 is moronic (or words to that effect).

It made no difference. The K&R deciples remained unconvinced.

 

[DavidSnider]

Why would you take the issue to non-programmers? Isn't that kind of like asking non-pilots which instrument deck looks the best?

 

[Hurkyl]

I agree. I also like the visual separation it creates between structures and code blocks.

I sometimes use method 2 for this reason. However, I also use method 1 for this reason.

That is, I often don't want the separation. e.g. short loops, conditionals, and functions are often best read as one unit. Adding the spacing breaks apart the flow of the code. It also means that the breaks between units require dramatic formatting.

Even groups of functions should often be clustered. e.g. a block of code like

inline bool operator> (const type &x, const type &y) { return   y <  x ; }
inline bool operator<=(const type &x, const type &y) { return !(x >  y); }
inline bool operator>=(const type &x, const type &y) { return !(x <  y); }
inline bool operator!=(const type &x, const type &y) { return !(x == y); }

to define the other comparison operators on a class in terms of < and == already takes up more space than it really deserves. Aside from assuring you don't exceed 78 character lines, there is nothing to gain from "properly" formatting these.

 

[Mark44]

Here is a very simple JavaScript example.
Style 1.

return
{
   status: true
};

Style 2.

return {

   status: true
};

(This example appears in "JavaScript: The Good Parts," Douglas Crockford, O'Reilly|Yahoo! Press.

Style 1 causes the JavaScript interpreter to think that you forgot to put a ; on the line with the return statement, so to help you out, it adds one there. This means that what is actually returned is undefined, not an object with its status property set to true.

To prevent this behavior, include the right brace - { - on the same line with the return keyword.

 

[phinds]

Why would you take the issue to non-programmers? Isn't that kind of like asking non-pilots which instrument deck looks the best?

I was looking for a logical input, not a technical one, and it's what I got, but as I said, it didn't make any difference.

 

[AlephZero]

(This example appears in "JavaScript: The Good Parts," Douglas Crockford, O'Reilly|Yahoo! Press.

I don't know the book, but I'm surprised it's as long as 172 pages

But apart from showing how not to design a programming language, as Hurkyl said why wounldn't any sensible programmer write

return { status: true };

or even leave out the { } unless Javascript insists on them.

 

[Mark44]

I don't know the book, but I'm surprised it's as long as 172 pages

Crockford also includes the bad parts, and the really bad parts. What he presents in this book is a subset of JavaScript that is actually pretty reasonable.

But apart from showing how not to design a programming language, as Hurkyl said why wounldn't any sensible programmer write

return { status: true };

or even leave out the { } unless Javascript insists on them.

The braces indicate that what is being returned is an object.

 

[gabbagabbahey]

Personally, I prefer method 1 as I don't really like all the extra lines of code method 2 results in. However, as long as you are consistent within a given project, there should be no problems for another coder to understand what you are doing.

 

[Borg]

I prefer method one. Mostly because I consider two to be a waste of real estate on my screen. If my methods are so long that I can't see the alignments well, that tells me that I'm probably overcoding it.

I've been on projects where the code gets auto-formatted to method two when it's checked into the code repository. I would much rather see the people that implement that nonsense to focus on putting in proper error handling or commenting their code.

On a related note, if you want a good laugh on how not to code, check out the link below.

 

[cobalt124]

Always Method 2. I find it much easier to read, though the extra line count is annoying.