Mandatory use of braces

Question

As part of a code standards document I wrote awhile back, I enforce \"you must always use braces for loops and/or conditional code blocks, even (especially) if they\'re only one

Answer 1

Wow. NO ONE is aware of the dangling else problem? This is essentially THE reason for always using braces.

In a nutshell, you can have nasty ambiguous logic with else statements, especially when they're nested. Different compilers resolve the ambiguity in their own ways. It can be a huge problem to leave off braces if you don't know what you're doing.

Aesthetics and readability has nothing to do it.

Answer 2

Depending on the language, having braces for a single lined conditional statement or loop statement is not mandatory. In fact, I would remove them to have fewer lines of code.

C++:

Version 1:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 ) throw InvalidOperation();
   return a/b;
}

Version 2:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 )
   { 
      throw InvalidOperation();
   }
   return a/b;
}

C#:

Version 1:

foreach(string s in myList)
   Console.WriteLine(s);

Version2:

foreach(string s in myList)
{
   Console.WriteLine(s);
}

Depending on your perspective, version 1 or version 2 will be more readable. The answer is rather subjective.

Answer 3

I see this rule as overkill. Draconian standards don't make good programmers, they just decrease the odds that a slob is going to make a mess.

The examples you give are valid, but they have better solutions than forcing braces:

When you don't brace a single-line, and then someone comments it out, you're in trouble.

Two practices solve this better, pick one:

1) Comment out the if, while, etc. before the one-liner with the one-liner. I.e. treat

if(foo)
    bar();

like any other multi-line statement (e.g. an assignment with multiple lines, or a multiple-line function call):

//if(foo)
//    bar();

2) Prefix the // with a ;:

if(foo)
;//    bar();

If you don't brace a single-line, and the indentation doesn't display the same on someone else's machine... you're in trouble.

No, you're not; the code works the same but it's harder to read. Fix your indentation. Pick tabs or spaces and stick with them. Do not mix tabs and spaces for indentation. Many text editors will automatically fix this for you.

Write some Python code. That will fix at least some bad indentation habits.

Also, structures like } else { look like a nethack version of a TIE fighter to me.

are there good reasons why this would be a mistaken or otherwise unreasonable standard? There's been some discussion on it, but no one can offer me a better counterargument than "it feels ugly".

Redundant braces (and parentheses) are visual clutter. Visual clutter makes code harder to read. The harder code is to read, the easier it is to hide bugs.

int x = 0;
while(x < 10);
{
    printf("Count: %d\n", ++x);
}

Forcing braces doesn't help find the bug in the above code.

P.S. I'm a subscriber to the "every rule should say why" school, or as the Dalai Lama put it, "Know the rules so that you may properly break them."

Answer 4

If you have the time to read through all of this, then you have the time to add extra braces.

Answer 5

The best counter argument I can offer is that the extra line(s) taken up by the space reduce the amount of code you can see at one time, and the amount of code you can see at one time is a big factor in how easy it is to spot errors. I agree with the reasons you've given for including braces, but in many years of C++ I can only think of one occasion when I made a mistake as a result and it was in a place where I had no good reason for skipping the braces anyway. Unfortunately I couldn't tell you if seeing those extra lines of code ever helped in practice or not.

I'm perhaps more biased because I like the symmetry of matching braces at the same indentation level (and the implied grouping of the contained statements as one block of execution) - which means that adding braces all the time adds a lot of lines to the project.

Answer 6

I don't buy into your argument. Personally, I don't know anyone who's ever "accidentally" added a second line under an if. I would understand saying that nested if statements should have braces to avoid a dangling else, but as I see it you're enforcing a style due to a fear that, IMO, is misplaced.