# Preferred curly brace placement and why.

## If given discretion, which would you use and why?

• Total voters
16
Gold Member
Assume you're not forced to use a particular method.

Method 1:

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

Method 2:

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

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

Last edited:

AlephZero
Homework Helper

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

DavidSnider
Gold Member
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.

Last edited:
jtbell
Mentor
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.

Gold Member

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
Homework Helper
The designers of Fortran 77 got this right IMO.
Code:
if (something) then
doThis
elseif (somethingElse) then
doThat
else
doTheOther
endif
No variations allowed, since the line breaks are part of the syntax.

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

Mark44
Mentor
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
Gold Member
2021 Award
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
Gold Member
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
Staff Emeritus
Gold Member
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

Code:
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.

Last edited:
Mark44
Mentor
Here is a very simple JavaScript example.
Style 1.
Code:
return
{
status: true
};

Style 2.
Code:
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
Gold Member
2021 Award
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
Homework Helper
(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
Code:
return { status: true };
or even leave out the { } unless Javascript insists on them.

Mark44
Mentor
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
Code:
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
Homework Helper
Gold Member
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