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

  • I read somewhere that the style in K&R was governed by space considerations - i.e. to reduce the vertical space the code took up in the book. – ChrisF Aug 9 '11 at 14:14
  • @ChrisF it also reduces vertical space on the screen. When we had 80 col x 25 line terminals it was worth it! – Martin Beckett Aug 9 '11 at 15:37
  • 7
    Apple's "goto fail" is a great example of a serious bug that would surely have been prevented by using 1TBS: imperialviolet.org/2014/02/22/applebug.html – user126361 Apr 9 '14 at 5:31
  • 3
    Apple's bug could also have been prevented by putting the statement on a single line, proofreading, using a dead code checker, or using an indent-sensitive language. – Cees Timmerman May 3 '15 at 23:59
  • @CeesTimmerman, .. or having tests... – thoni56 Feb 9 '18 at 15:57

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:


int i;
for (i = 0; i < 10; i++)


int i;
for (i = 0; i < 10; i++) {

K&R is like this:

if (x) 
else {

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) {
} else {

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) 


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.

  • 1
    Deleted all the comments as they had descended in to bickering and noise. If you have a valid point then post it as an answer. If you want a discussion take it to chat – ChrisF Aug 9 '11 at 15:17
  • 8
    doesn't the 1tbs put the } and else on one line ? Saving vertical space while preserving the wondrous beautiful symmetry is the point ! – Martin Beckett Aug 9 '11 at 16:00
  • 4
    @Jerry - well any good holy war needs a few schisms ;-) – Martin Beckett Aug 9 '11 at 17:09
  • 6
    goto fail; goto fail; – Jamie Pate Apr 30 '14 at 17:58
  • 9
    Yes to follow up on @JamiePate's comment that is the Apple SSL bug which is analyzed here. There is an if statement with indented statements after it, thus appearing that they are both conditionally executed. But there are no braces! The second statement is really beyond the if and will always be executed, thus the bug. – Colin D Bennett Feb 27 '15 at 20:10

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

  • 2
    this seems to merely repeat point made and explained in prior answers – gnat Jun 5 '15 at 21:42
  • 1
    I don't think the other answers explain exactly how the problem arises in everyday code. They explain what OTB is, but not why it is actually important. Comments might address that, but not the answers. – Justin Swanhart Jun 7 '15 at 18:53

protected by gnat Jun 5 '15 at 21:41

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.