What is the difference between K&R and One True Brace Style (1TBS) styles?

Question

I have read the Wikipedia article on Indent Styles, but I still don't understand. What is the difference between K&R and 1TBS?

Answer 1

The biggest difference between K&R and the One True Brace Style (1TBS) is that in the 1TBS, all if, else, while, and for statements have opening and closing braces, even if they aren't necessary. The purpose is to make it easy to insert new statements and know exactly how they will be grouped.

As an example:

K&R:

int i;
for (i = 0; i < 10; i++)
  printf("Hi.");

1TBS:

int i;
for (i = 0; i < 10; i++) {
  printf("Hi");
}

Answer 2

K&R is like this:

if (x) 
    a();
else {
    b();
    c();
}

That is: braces used only where needed, opening brace on same line as controlling statement, closing brace on its own line.

The "one true brace style" (1TBS or OTBS) turns a single controlled statement into a compound statement by enclosing it in braces:

if (x) {
    a();
} else {
    b();
    c();
}

Allman style goes a bit further than 1TBS, and forces vertical spacing by placing the opening brace on a line by itself as well:

if (x) 
{
    a();
}
else 
{
    b();
    c();
}

Edit:

I'm still trying to figure out exactly how it qualifies as "arrogant" to say "Dennis Ritchie was an extremely smart guy who not only invented a good language, but also came up with a really good brace style for it."

For those who insist that it's being arrogant anyway, here's a little challenge: go to Sourceforge, Github (etc.) and pick out projects using the K&R brace style. Go through their records of bugs and commits, and try to find a single bug that was caused by the brace style they used.

If you don't want to do that much work, try doing a simple statistical analysis. Compare projects using different brace styles, and see if you can show "bimodality" -- a statistically significant difference in bug counts (severity, etc.) that correlates with bracing style.

I did both of these a few years ago, and couldn't find a single bug that I could attribute to bracing styles, nor could I find anything approaching a statistically significant correlation between the two. On average, those using K&R bracing had slightly fewer bugs, but the difference was much too small to qualify as statistically significant.

Since it was brought up, I'll comment on the situation with multi-statement macros. A macro that includes multiple statements but doesn't surround them with braces itself, has a bug. My job is not to write code that covers up that bug. Quite the contrary, my job is to find and eradicate that bug as quickly as possible.

Writing code in the hope of its covering up bugs so they remain undiagnosed and un-fixed is downright evil. Call that arrogant if you like, but I do not see this as even close to negotiable. Bugs should be found and fixed, not covered up. The longer the exist, the more likely it is that they will become much more difficult and expensive to fix.

Answer 3

The problem, in general with KR brace style is in code refactoring. When moving code around it is easy to miss that there are no braces around something, move it incorrectly (or move something under it thinking it is conditionally executed) and then either scratch your head when something no longer works, or be unfortunate and be in a code area not well tested and the bug goes unnoticed until a black hat finds a way to exploit it. A quick trip into the debugger easily finds the problem if you notice it, but if you don't...