Should you place curly braces on the same line as the statement (cuddle), or on the next line? It's a debate that has raged for years, and is unlikely to be resolved until curly braces in code become obsolete. Despite that, I thought I would share my opinion on the topic.

First though, let's look at both sides of the argument. I will try to represent this as fairly as possible, despite my own bias. I've numbered the arguments, so it's easier to reference them in the comments.

Same line (cuddled) 

function foo() {
   // same line example.
   if (a == b) {
      ...
    } else {
      ...
    }
}
Arguments in favour of same line formatting:
  1. More readable because it reserves vertical whitespace for the developer to visually segment logical code blocks.
  2. Code is more vertically compact, which allows you to view more lines of code at once.
  3. Reinforces the logical meaning of the code, by associating the brace with the statement it opens.

Next line 

function foo()
{
   // next line example.
   if (a == b)
   {
      ...
    }
   else
   {
      ...
    }
}
Arguments in favour of next line formatting:
  1. More readable because it's easier to identify the start of code blocks, and easier to line up start and end braces.
  2. Reinforces the lexical and logical meaning of the code, by more clearly identifying a code block.
  3. Separates multiline statement declarations (ex. function declarations with a large number of parameters) from the code within the block.

My take

I'm personally a firm believer in the cuddled approach (I'm a cuddly guy - ask my wife), for all three of the reasons stated above. I like being able to see more lines of code (#2, particularly when editing on a laptop), I would rather break my own code into logical groupings with white space than litter it with breaks based on a rigid standard (#1), and I think that the statement is a critical part of the block which should be directly associated with it (#3 & #5). I also believe that wherever possible grammar for code should parallel grammar for writing, and I see the opening brace as being similar to a colon preceding a bulleted list. In essence it is saying, I am ending my qualifying statement, and what follows is the list of things it applies to. You wouldn't put the colon on the next line, or as the first item of a list.

I don't agree with the argument that it's easier to see blocks with braces on the next line (#4) - if you can't pick out the start and end of an indented block of code, you need to increase your editor's font size. Some people argue that the benefit is that if a developer doesn't indent correctly you can still match braces, but where's the guarantee that a developer that can't indent correctly will adhere to your brace standard correctly. Not to mention that most code editors include brace matching and code folding.

There also seems to be a lot of inconsistency in how next line formatting should work. Some developers indent the braces (which is heinous), some don't. I've seen a number of developers use next line for most things, but break the standard for things like else and do/while statements, using something like this: 

do
{
   ...
} while (true);
When they should really be using this: 
do
{
   ...
}
while (true);
The former example doesn't violate the idea of making it easier to visually pair braces (#4), but it does fly in the face of the idea that a code block is a self contained entity (#5). A major argument in favour of cuddled braces is associating the statement with the block, which should be equally valid whether the statement is before or after the block.

I have yet to see a developer that adheres to same line formatting for braces invent exceptions to the standard. While I'm sure there are some that do, it's a whole lot rarer, and more difficult.

On the flip side, Adobe has chosen to adopt next line formatting for curly braces for whatever reason. This means that if you use next line formatting, your code will adhere to Adobe's internal standards. FlexBuilder also seems to only support next line formatting for its auto generated code, which really pisses me off (anyone who knows how to fix this, please comment!).

At the end of the day, the most important thing is that you are consistent. If you have to swallow your pride and adopt a standard that you don't agree with to mirror the standards of an existing codebase or company standard, just do it!

Feel free to post your preference, and reasoning in the comments below.

I think I might write a few other articles detailing my thoughts on frequently debated code standards (single or double quotes, single line if statements, tabs or spaces, etc).