Where Do The Braces Go

It has always been frustrating to me that bracing styles for C/C++ and Java have fallen mostly into the two camps (most often referred to as K&R or emacs style):

K&R (OneTrueBraceStyle):

 if (something == true) {
do_this_about_it();
 } else {
do_this_instead();
 }

EmacsEditor:

 if (something == true) 
 {
do_this_about_it();
 } 
 else 
 {
do_this_instead();
 }

GNU coding standard (two spaces per indent, braces get one indent, enclosed statements get two indents):

 if (something == true) 
   {
     do_this_about_it();
   } 
 else 
   {
     do_this_instead();
   }

This one topic alone has probably derailed more CodingStandard efforts in otherwise viable project teams.

My personal favorite has been a modified form of the emacs style, but with the braces indented with the code block that they enclose. I have seen it in a few isolated software books, but it does not seem to be very mainstream, so we'll call it the "style without a name."

"Style without a name" (aka "Whitesmiths style"):

 if (something == true)
{
do_this_about_it()
}
 else
{
do_this_instead()
}

This was originally not my favorite indentation style, but despite my best efforts with smart auto-indent, Microsoft's Visual C++ IDE (Version 6) kept coercing me into using this style to the point where I realized resistance was futile and I just gave in. I would guess that legions of MS Visual C++ programmers around the world have done the same, so your "style without a name" may be much more mainstream than you think. -- NeilSwart

Instead of clunky {}'s distracting the eye, the code statements do their own alignment and visual grouping, and the braces are clearly associated, not with their outer construct, but with their enclosed code.

In fact, this question is neatly bypassed in PythonLanguage, which would look like:

 if (something == true):
do_this_about_it()
do_something_else()
 else:
do_this_instead()

although some believe SyntacticallySignificantWhitespaceConsideredHarmful. I think that being able to sidestep this question so neatly is easily worth whatever cost whitespace-based syntax may incur. -- PaulMcGuire

It seems to me that the only reason to argue about this stuff is if we're not willing to run all our code through a PrettyPrinter. Sometimes I want to lay out my code in such weird ways (to get various visual effects) that I'm not sure I could teach a pretty-printer to do it - but it would be interesting to see if it were possible. If it were, we could stop having all these silly arguments and just write the pretty-printers and parsers. (And once we're there, why restrict ourselves to plain text? But one step at a time. :) -- AdamSpitz

Agreed. The best approach I've found is to use a combination of IDEs and version control system with decently configurable code formatters. Folks fetch from version control in the standard format and reformat to their preference. When they check the code back in, the version control system reformats back to the standard. -- EricHodges

Has anyone noticed a problem using pretty printers along with ContinuousIntegration? I can see constant rechecking in of code if two people have different pretty printer configurations. I guess a solution would be to make a default setting that is used on all code before committing.

That's what I'm advocating above. More than that, integrate the reformatting into the check-in procedure. The last place I worked we configured CVS to do it automatically. We picked Sun's format for Java. The end result was that people drifted toward that format out of laziness. -- EH

I would draw a different conclusion. I believe this indicates that for most programmers, brace placement is not very important. It seems that the company above wasted quite a bit of time and effort to find a pretty printer, determine the pretty printer standards, and integrate it into the version control system. In the end, people used the format and the effort was wasted. Technology does not solve people issues. -- WayneMack

You weren't there. It was well worth the time investment. We talked about it as a group for 15 minutes, then one of our guys downloaded the code formatter and plugged it into CVS in about an hour. Technology made the people issues go away. For months folks were reformatting every time they fetched a file. It was well worth the time investment not to deal with people grumbling about bracket placement. I've worked places where a single style was dictated from above and the bitching was always much worse. I agree that a single style is a worthy goal, but I'd rather reach that goal through the path of least resistance. -- EH

Yes. :) There's a more general principle here. Something like, "OnceAndOnlyOnce reduces arguments." If your brace-placement decisions are hard to change, and people feel strongly about them (even if they shouldn't), they'll argue. This stuff is interesting to me because I think it's a case where technology does solve a people issue. -- AdamSpitz

I had this same idea, but ran afoul of C++ parsing being non-deterministic. I was all set to have a prettyprinter convert all code on checkin to a standard format, and allow developers to reformat to their preferred on check-out, but none of the prettyprinters could handle some of our code consistently. I ran across one macro+template that would alternate between 2 forms. -- PeteHardie

Anyone care to recommend a C++ PrettyPrinter?

Artistic Style is a reindenter and reformatter of C++, C and Java source code. It is available from http://astyle.sourceforge.net/

I think we are attacking the wrong problem. I have usually found that with decently laid out and partitioned code, I can readily adapt to whatever brace style is used. The times where I have had to print out the source and match up braces with colored pens, changing the brace placement to my preferred style provided little help. What was needed was to segment the original method to a manageable size. Argue about brace placement over pizza and beer, but during work hours, gravitate to your own preference and let others do likewise. There are far more important issues to address. -- WayneMack

You are quite right, of course. However, I have been at plenty of clients' places where the indigs are likely to get into fist fights over the placement of braces. Therefore, a coding standard is necessary to keep such squabbling down. The other side of it is what Eric said about using indent or something to reformat the source when you check it out and then reformatting it back when you check it back in. I have always thought that was the most graceful solution. -- MartySchrader

Just my preference but

  statement
  {
statements...
  }

Seems most symmetrical you can quickly visually balance nesting by seeing that top and bottom braces line up. Also I like using 2 space indents - tabs cause the code to quickly start running off/wrapping inside the page. I like to type both braces in a block before starting on the middle code (I arrow back up/space right from the closing "}") it provides a sort of frame to "work inside". I envisage the current block like a metalworker with a (yet to be created) subassembly in a "vice" the "{}" are like clamps.

If code nests so deeply it wraps, it may be time to consider the ExtractMethod refactoring.

I like the similar symmetry in the above style-without-a-name. In this style, the braces go with the enclosed code. This way, the indentation looks the same whether you have a single unbraced statement or a block enclosed in braces. I also like your suggestion of putting the braces first, then going back and filling in the body. The VAX Language-Sensitive-Editor was able to do this auto-expansion, um, automatically. -- PaulMcGuire

My objection to the K&R style is that I can't easily grab the braces with the enclosed code when I copy & paste during a refactoring. I do fine with the others cited here, including the python. -- TomStambaugh

That sounds like an editor problem. In Emacs, you only have to double-click one of the braces. Perhaps your editor can do something similar, or can be taught to do it.

It has occurred to me that it would help if programmer for languages using braces had a notation for describing the different brace styles succinctly. My specific proposal is for a series of letter-number codes for each of the possible brace locations and indent levels. The first code would be the location of the leading brace and it's indentation (with the letter code in upper case), the second the code indentation, the third the position and indentation of the trailing brace (with the letter in lowercase), the fourth the handling of braces around else statements (and the spacing around the code body in the case of cuddled elses), and the fifth for the handling of single expressions (and the spacing around the code body for in-line blocks).

The letter abbreviations would be T (terminal, for the lead brace at the end of the expression), S (successive, for the lead brace on the line following the expression), C (cuddled, for 'cuddled' elses), U (uncuddled), L (linear, for a single-statement body that has both braces inline with the statement), N (non-linear, for applying the normal brace rules to single statement blocks), and B (bare, for single expressions with no braces).

For example, 1TBS as it's usually described would be T1:8:s0:C0:B. Similarly, GNU style would be S3:8:s3:U:N, and Allman style would be S0:8:s0:U:B. Since the most common cases do not use cuddled braces, have the trailing brace on the line following the code body with no indentation, and (unfortunately) omit braces around single expressions, the latter could be abbreviated to S0:8.

While this is cryptically terse, it does cover most of the common variations on brace style as I know them. Any comments or alternatives? -- JayOsako

Why should it be a question? Coding style should not be merged into syntax. It is significant that in Java and C/C++, unlike Python, you can choose the style. Many would argue that the braces don't confuse the eye, but make code more readable.

This is a question of form versus function, really, and should be treated as such. Please, let's not have PersonalChoiceElevatedToMoralImperative when it comes to source code layout, shall we?

Discussion of code storage and representation moved to CodeInaNewFormDiscussion.

See: CodingStyle

CategoryCodingIssues, CategoryCee