Single statement if block - braces or no?

Question

Which is better/more generally accepted?

This:

if(condition)
{
  statement;
}

Or:

if(condition)
  statement;

I tend to prefer the first one, because I think it makes it easier to tell what actually belongs in the if block, it saves others from adding the braces later (or creating a bug by forgetting to), and it makes all your if statements uniform instead of some with braces and some without. The second one, however, is still syntactically correct and definitely more compact. I'm curious to see which is more generally preferred by others though.

Answer 1

The first is better because the second is error-prone. For example, let's say you are temporarily commenting out code to debug something:

if(condition) 
//      statement;
otherStatement;

Or adding code in a hurry:

if(condition) 
    statement;
    otherStatement;

This is obviously bad. On the other hand, the first one does feel too verbose at times. Therefore, I prefer to just put everything on one line if it's sufficiently short and simple:

if(condition) statement;

This cuts down on syntactic noise while making the construct look like it does what it actually does, making it less error-prone. Provided that this syntax is only used for very simple, short conditions and statements, I find it perfectly readable.

Answer 2

I always use brackets just to be safe.

It's fine when you write it, but you know somebody will come along in the future and insert another statement without putting brackets around it.

Answer 3

I prefer the version without braces where possible.

The following explanation is longish. Please bear with me. I will give a compelling reason for me to prefer this style. I will also explain why I think that the usual counter-argument doesn’t hold.

(Near-) empty lines are a waste

The reason for this is that the closing brace requires an extra line of code – and so does the opening brace, depending on style.¹

Is this a big deal? Superficially, no. After all, most people also put empty lines in their code to separate logically slightly independent blocks, which vastly improves readability.

However, I detest wasting vertical space. Modern monitors actually have ample horizontal space. But vertical space is still very, very limited (unless you use a monitor turned upright, which isn’t that uncommon). This limited vertical space is a problem: it’s widely acknowledged that individual methods should be as short as possible, and that corresponding braces (or other block delimiters) should be no more than a screen height in difference so that you may see the entire block without scrolling.

This is a fundamental problem: once you can’t see the entire block on your screen any longer, it gets complicated to grasp.

As a consequence, I detest redundant empty lines. Where single empty lines are crucial to delimit independent blocks (just look at the visual appearance of this text), consecutive empty lines are a very bad style in my book (and in my experience they are usually a sign of novice programmers).

Likewise, lines which simply hold a brace, and which could be economised, should be. A single-statement block which is delimited by braces wastes one to two lines. With only 50-ish lines per screen height, this is noticeable.

Omitting braces maybe does no harm

There is just one argument against omitting braces: that someone will later add another statement to the block in question and will forget to add the braces, thus inadvertently changing the semantics of the code.

This would indeed be a big deal.

But in my experience, it isn’t. I’m a sloppy programmer; and yet, in my decade of programming experience, I can honestly say that I have not once forgotten to add the braces when adding an extra statement to a singleton block.

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.

Now, I am not saying that omitting braces doesn’t cause mistakes. What I’m saying is that we have no evidence one way or the other. We simply don’t know whether it causes harm.

So until someone can show me hard data, collected from scientific experiments, demonstrating that this is indeed an issue in practice, this theory remains a “just-so story”: a very compelling hypothesis that has never been put to the test, and that must not be used as an argument.

---

¹ This problem is sometimes solved by putting everything – including the braces – on the same line:

if (condition)
{ do_something(); }

However, I believe it’s safe to say that most people despise this. Furthermore, it would have the same problems as the variant without braces so it’s the worst of both worlds.

Answer 4

I go with the second. It's more succinct and less verbose.

I try not to write to the lowest common denominator, so I expect that other developers know how to write one of the single most common control flow structures in programming today.

Answer 5

I'd use the following (the consensus here):

if (condition) {
    any_number_of_statements;
}

Also possible:

if(condition) single_compact_statement;

Not so good, especially in C/C++-like languages:

if(condition) 
    single_compact_statement;

(No choice here in Python ;-)

---

In Perl, you'd use:

$C = $A**3 if $A != $B;

or

$C = $A**3 unless $A == $B;

(This is not pseudocode ;-)

Answer 6

I use the braces method - for all the reasons above plus one more.

Code merges. It's been known to happen on projects I've worked on that single-statement ifs have been broken by automatic merges. The scary thing is the indentation looks right even though the code is wrong, so this type of bug is hard to spot.

So I go with braces - on their own lines. It's easier to spot the levels that way. Yes, it does waste vertical screen real estate and that's a genuine downside. On balance though, I think it's worth it.

Answer 7

No braces. If some other programmer adds a second statement to my code it's no more my fault than if I let someone drive my car and they went over a cliff.

Answer 8

We have had this argument more than once here, and the overall consensus is to always use braces. The main reasons are about readability/maintainability.

If you need to add code to the if block, you don't need to remember/search for braces. When future programmers read the code, the braces are always unambiguous.

On the plus side, ReSharper will automatically add the braces for lazy programmers in Visual Studio, and I assume there are addons for other IDEs that will do so as well.

Answer 9

I use the first syntax, almost without exception. Because it cannot be misinterpreted.

"Don't make me think" doesn't just apply to user-interfaces, y'all ;-)

Answer 10

I personally prefer the second. The first one looks ugly, awkward, and wastes horizontal space. The main problems with the second one are macros and people modifying your code at a later point getting it wrong.

To this, I say "don't use macros". I also say, "indent your damn code correctly". Considering how every text editor/IDE used for programming does indentation automatically, this shouldn't be that hard to do. When writing code in Emacs, I would use the auto-indent to identify if I wrote something wrong on a previous line. Anytime Emacs starts screwing up indentation, I usually know I've done something wrong.

In practice, I end up following whatever coding convention has been set before me. But these ones annoy me (and makes me much happier when I code in Python and this entire bracket disaster is gone):

if (condition) {
    statement;
} // stupid extra brace looks ugly

Then

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

Although honestly, two statements in an if statement annoy me far more than a single statement. Mostly because then brackets are required and it still looks funny with only two statements in the if statement.

Answer 11

I use the two-line version without braces (the 2nd form), but not to save space.

I use that form because I find it more readable, more visually appealing, and easier to type. I only use that form if those conditions are met; i.e. the if condition has to fit nicely on a single line, and the corresponding statement has to fit nicely on the following line. If that is not the case, then I will use braces to improve readability.

If I use this form, I make sure that there is an empty line (or a line containing only a brace) before and after the if statement (or above the comment, if present). While this is not a rule that I consciously follow, I notice it now after reading this question.

Conserving screen space is not a priority for me. If I needed more space I would use a larger monitor. My screen is already large enough for me to read anything that I might need to focus my attention on. It's unlikely that I would need to focus on so many lines of code at one time that they take up my entire screen. If there is so much nesting going on with a chunk of code that I can't understand it without viewing more of it at one time, then I would have to consider whether the logic could be better represented by refactoring.

Below are some examples that demonstrate how I use this form of the if statement.

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

Answer 12

Braces. Always. I'm kind of the fan of them, because it gives code some consistency. And also as @dsimcha wrote - less chance for errors on adding additional lines of code.

"Ugliness" of braces around single line of code are less harmful than additional work which is probable in those cases with debugging and/or adding code.

Answer 13

Personally I go with brackets.

Why?

Well if anyone comes along and needs to add code into the if statement it's 100% clear where the scope is.

It keeps the format of if statements consistent no matter how many statements there are in the block.

However, if the project style is to go without, stick to that.

Answer 14

I prefer braces for consistency, but not wasting too much white space (so more readably formatted code is in my limited field of view). So I write this for short enough lines:

If (cond) { statement; }

Answer 15

I almost always use the brackets just to be on the safe side. However, sometimes if the contents of the block are really short I'll do leave them off and make it a one-liner like so:

if (x==5) Console.WriteLine("It's a five!");

Answer 16

I usually use braces, but there are some cases where I don't.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

To me, it would just be silly to add them there. If someone adds a statement after the return, we have bigger problems than scoping issues.

Answer 17

If the IDE has code formatting available I do not use braces.

On the other hand, where code may be edited in other editors which does not support auto formatting it is dangerous not to put braces as mentioned in other posts. But even so I prefer not to use braces, and it has not been problem for me.