Gigi Labs

Please follow Gigi Labs for the latest articles. Programmer's Ranch no longer has its domain, so please update your bookmarks and links to programmersranch.blogspot.com.

Wednesday, September 25, 2013

Best Practices: To Always Use Braces for Conditionals and Loops... or not

Hi everyone! :)

While following a number of Pluralsight courses by Jesse Liberty (which I highly recommend), I was reminded of the long-running debate about whether one should always use braces when control flow statements (conditionals and loops) are involved. Jesse Liberty is one of many who suggest always using braces. So let's say we have the following conditional:

            if (x == 0)
                Console.WriteLine("x is zero");
            else if (x < 0)
                Console.WriteLine("x is negative");
            else if (x > 0)
                Console.WriteLine("x is positive");

The proponents of the always-use-braces camp would have us write them like this:

            if (x == 0)
            {
                Console.WriteLine("x is zero");
            }
            else if (x < 0)
            {
                Console.WriteLine("x is negative");
            }
            else if (x > 0)
            {
                Console.WriteLine("x is positive");
            }

In this article, I'm going to discuss the advantages and disadvantages of this approach, as well as my personal opinion based on my experience. I want to say from the beginning that this article is subjective and not completely factual or objective - so take it for what it is. There is no general consensus on this matter precisely because it is a matter of personal taste.

Brace styles


Braces (or curly brackets) are a feature in just about any programming language that uses the C-style syntax, including C, C++, Java, C#, JavaScript, PHP, and many others. They define a scoped block that can be executed as a single statement as part of control flow (conditionals and loops). There are many different styles in which they can be used.

The Java folks seem to like this kind of style:

            if (x == 0) {
                Console.WriteLine("x is zero");
            }

The .NET camp, on the other hand, seems to prefer aligning braces vertically:

            if (x == 0)
            {
                Console.WriteLine("x is zero");
            }

If you have just one statement, you can technically leave out the braces, so you can write your code like this:

            if (x == 0)
                Console.WriteLine("x is zero");

...or like this.

             if (x == 0) Console.WriteLine("x is zero");

Personally, I think the first and last options aren't the best in terms of readability (especially when code becomes complex) so I'll focus on the second and third. I normally use the second option (with braces) when I have multiple statemenents, and the third option (no braces) when I have just one. Many people recommend always using braces, and dismiss the third option as bad practice. Let's take a look at the reasons why.

If you need to add statements, you'll find the braces ready


So let's take the same example as before, where you have this statement:

             if (x == 0)
                Console.WriteLine("x is zero");

If you need to add additional statements to be executed as part of the conditional, the braces will have to be added anyway. Some people recommend always using braces so that you'll find them ready when you need to add additional statements.

In that case, I suppose, we shouldn't use empty element syntax in XML:

<RowDefinition Height="30" />

...and instead always write our tags in full:

<RowDefinition Height="30"></RowDefinition>

...simply because we might need to add something inside the element at some point. I think this is a very weak argument, because it disregards a language feature that may be very convenient, and at the same time bloats code with something that adds no meaning to the code. Take a look at the first two code snippets in this article - the one that uses braces is twice as long (in terms of lines) as the other one. And for what? Because people are too lazy to type in the braces when they are eventually needed? Wat.

Adding statements can be error-prone


Another reason why omitting braces is considered bad practice is that it may be easy to introduce logical errors when maintaining such code (see this question on Programmers StackExchange and this other one on Stack Overflow). Let's say you have this:

            if (x == 0)
                Console.WriteLine("x is zero");

Then, you add an additional statement intended to be within the conditional, and you do it like this:

             if (x == 0)
                Console.WriteLine("x is zero");
                Console.WriteLine(" which means it's neither positive nor negative");

Oops! The second Console.WriteLine() isn't actually part of the conditional, so it always gets executed, no matter what. This is a valid argument. But let's dissect it a little further.

First, let's start again from our simple single-line conditional:

             if (x == 0)
                Console.WriteLine("x is zero");

Now, if you want to add code at this point, you have two courses of action. If you want to add statements as part of the conditional, you know that there's just one statement and no braces, so adding them should be a pretty automatic response:

            if (x == 0)
            {
                Console.WriteLine("x is zero");
                Console.WriteLine(" which means it's neither positive nor negative");
            }

On the other hand, if you want to add a statement that is not a part of the conditional, you add it at the same level as the if statement:

            if (x == 0)
                Console.WriteLine("x is zero");
            Console.WriteLine(" which means it's neither positive nor negative");

Even in absence of braces, the indentation shows clearly that one statement belongs to the conditional and the other does not. So actually, when seeing this kind of code:

             if (x == 0)
                Console.WriteLine("x is zero");
                Console.WriteLine(" which means it's neither positive nor negative");

...I can't help but think that the readability problem (which results in incorrect control flow) is one of indentation, not of whether to use braces or not.

I can certainly imagine beginning programmers making this kind of mistake, but I find it hard to believe that more seasoned programmers find it hard to read basic conditionals. As one of the answers to this question states:

"I even find it implausible that this should be a common mistake: blocks are a fundamental part of programming. Block level resolution and scoping is an automatic, ingrained mental process for programmers. The brain just does it (otherwise, reasoning about programming would be much harder). There is no additional mental effort required to remember putting the braces: the programmer also remembers to indent the newly added statement correctly, after all; so the programmer has already mentally processed that a block is involved." -- Konrad Rudolph

Also, one of the sections in this article states that:

"Programmers with enough discipline to always notice the braces (and put them in when needed) don't need this idiom [always using braces].
"Auto-indent editors make it obvious whether your new statement is part of the else clause, making it unlikely you'll have the bug this idiom tries to prevent."

Summary


Personally, I think that using braces when they aren't necessary is a waste of space, resulting in a lot of unnecessary lines of code. I use them when needed, and don't use them for single statements. I find nothing wrong with omitting braces when they aren't needed. This has worked for me for many years, and you may or may not agree wtih me. Different people find themselves comfortable using different approaches, and there is no general consensus on what is best.

So find out what works best for you, and don't let anyone tell you how you should write your code based on subjective arguments. While you should definitely learn from more experienced programmers and best practices based on rational and logical arguments, be practical and don't get too religious about your code.

1 comment:

  1. I find your argument persuasive, and suspect I was being overly prissy. -jesse

    ReplyDelete