Why is it considered a bad practice to omit curly

Question

Why does everyone tell me writing code like this is a bad practice?

if (foo)
    Bar();

//or

for(int i = 0 i < count; i++)
    Bar(i);

My biggest argument for omitting the curly braces is that it can sometimes be twice as many lines with them. For example, here is some code to paint a glow effect for a label in C#.

using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
    for (int x = 0; x <= GlowAmount; x++)
    {
        for (int y = 0; y <= GlowAmount; y++)
        {
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
        }
     }
 }
 //versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
    for (int x = 0; x <= GlowAmount; x++)
        for (int y = 0; y <= GlowAmount; y++)
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));

You can also get the added benefit of chaining usings together without having to indent a million times.

using (Graphics g = Graphics.FromImage(bmp))
{
    using (Brush brush = new SolidBrush(backgroundColor))
    {
        using (Pen pen = new Pen(Color.FromArgb(penColor)))
        {
            //do lots of work
        }
    }
 }
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
    //do lots of work
}

---

The most common argument for curly braces revolves around maintance programming, and the problems that would ensue by inserting code between the original if statement and its intended result:

if (foo)
    Bar();
    Biz();

---

Questions:

1. Is it wrong to want to use the more compact syntax which the language offers? The people that design these languages are smart, I can't imagine they would put a feature which is always bad to use.
2. Should we or Shouldn't we write code so the lowest common denominator can understand and have no problems working with it?
3. Is there another argument that I'm missing?

Answer 1

I'm quite happy to:

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

Personally, I don't see why

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

is any more readable.

Yes, lines are free, but why should I have to scroll through pages and pages of code when it could be half the size?

If there is a difference in readability or maintainability then, sure, put braces in... but in this case I don't see any reason to.

Also, I will always put braces for nested if's where I have nested else's

if (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

vs

if (condition1)
  if (condition2)
    doSomething();
else (condition2)
  doSomethingElse();

is terribly confusing, so I always write it as:

if (condition1)
{
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();
}

Whenever possible, I use ternary operators, but I never nest them.

Answer 2

Use some personal judgement.

if (foo)
  bar();

is fine by itself. Unless you're really worried about morons putting in something like this later:

if (foo)
  bar();
  baz();

If you're not worried about morons, you're fine (I'm not -- if they can't get basic code syntax right, this is the least of their problems)>

In exchange, it's a lot more readable.

The rest of the time:

if (foo) {
  bar();
  baz();
}

Which has been my favorite as long as I can remember. Additionally:

if (foo) {
  bar();
  baz();
} else {
  qux();
}

Works for me.

Vertical space by itself isn't terribly relevant, readability is. The opening brace on a line by itself just stops the conversation for a syntactic element, until your eye moves down to the next line. Not what I like.

Answer 3

Reducing lines is not really a good argument for dropping braces. If your method is too big, it should probably be refactored into smaller pieces or restructured. Doing that will no doubt increase readability more than simply taking out braces.

Answer 4

Speed of reading...

Aside from what has already been mentioned. At this point, I've already been conditioned to parse if statements with braces and white space. So I read:

if (condition)
{
    DoSomething();
}

DoSomethingElse();

Slightly faster than I read:

if (condition) DoSomething();

DoSomethingElse();

I read it a little slower if it looks like this:

if (condition) DoSomething();
DoSomethingElse();

I read this significantly slower than the prior:

if (condition) 
    DoSomething();
DoSomethingElse();

beause I can't help but read it again just in-case and wonder if the author intended:

if (condition)
{
    DoSomething();
    DoSomethingElse();
}

Already covered in general, but when it comes to reading the below, I'll be looking into this for quite a while to make sure what the author intended. I may even hunt down the original author to confirm.

if (condition) 
    DoSomething();
    DoSomethingElse();

Answer 5

My philosophy is if it makes the code more readable, why not do it?

Obviously you have to draw the line somewhere, like finding that happy medium between concise and overly descriptive variable names. But brackets really do avoid errors and improve the readability of the code.

You can argue that people smart enough to be coders are going to be smart enough to avoid bugs that stem bracketless statements. But can you honestly say you've never been tripped up by something as simple as a spelling error? Minutia like this can be overwhelming when looking at large projects.

Answer 6

If it's something small, write it like this:

if(foo()) bar();

If it's long enough to break into two lines, use braces.