To Always Use Braces for Conditionals and Loops… or not

This article was originally posted here at Programmer’s Ranch on 25th September 2013. The original article mentions Jesse Liberty as “one of many who suggest always using braces” with conditional statements. However, Jesse Liberty changed his view after reading the article (as you can see in the comments of the original article). As such, the article presented here has been slightly edited to remove this statement.

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

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:

…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

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