Single statement if block - braces or no?

  • Which is better/more generally accepted?





    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.

    But you have your opening brace in the wrong position. That much is certain.

    In many languages, a block is a statement, hence, syntactically, it is always if (expresion) statement

    Since you didn't specify a language... What about `statement if condition;`?

    @Christian - good one. That would be another question separate from this, no?

    @Ingo - good point.

    @Dave - let's say C/C++/Java/C#...

    Old Q, but: Run the auto format of your choice (IDE or astyle, whatever you prefer), and you see the difference immediately.

    The second is like a scratch on my brain each time my eye processes that kind of code.

  • dsimcha

    dsimcha Correct answer

    10 years ago

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

    //      statement;

    Or adding code in a hurry:


    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.

    Good point about putting everything on one line.

    But what about if statement is looooooooong ? :)

    @artjomka then refactor to a method.

    @artjomka: If statement is long, and has to go on its own line, then I use braces for readability. The point is that you want the shortest, least syntactically noisy construct that is unambiguous to a human who is reading it quickly rather than scrutinizing it.

    Yes. If the next day you have to think about it to figure out what you wrote yesterday, it probably isn't very clear.

    I prefer to do this, but our new coding standards (enforced by some VS template) decree a newline after all conditional statements. So now I have to add the braces (which means a one-line statement now takes up four lines).

    I prefer the one with braces for the reasons already mentioned. I don't like the one-liner, because it is not immediately obvious what happens when I step over the line in the debugger. I have to take the separate step to see what condition evaluates to.

    +1. Glad to see I'm not the only one who resorts to one line if statements.

    @TMN whitespace is free, monitors are big and your brain learns to recognise the shape which helps you parse the code.

    Although I can agree with the one-liner. Don't remember where I got this quote, but it illustrates my opinion: "If I don't put curly-braces around my if-statement consequent statement, another programmer will add a second statement assuming the braces are there but invisible, and bears will eat him."

    @Murph - I second the "brain learns the shape" argument - I'm pretty well used to expecting an if block to look a certain way, and that "shape" includes the braces.

    @Murph: Monitors seem to be getting fatter and shorter -- I have a 19" 1600x1200 monitor at home, but my 22" monitor at work is only 1680x1050. Height is indeed an issue.

    @TMN hmm, I cut my teeth on 80x25 character screens and did a lot of useful work at VGA and SVGA resolutions... in braces on multiple lines is the "right way" and it didn't get to be the right way purely on a whim. But if you don't like it so long as you conform to the coding standards of your organisations/projects who am I to argue.

    @Murph: whitespace is free? I must have missed that. On my screen, it takes up really much space. Much more than 50% actually. Which in my book seems like a big waste. Personally, I like to maximize content per square centimeter in code.

    @Konrad: I feel exactly the opposite, I prefer short lines and small groups of lines. Most of my methods contain blank lines just for the sake of separating different steps, I feel it makes it easier to read, it's the paragraph idea: the reader can just concentrate on one paragraph at a time, and when the step has been understood, move on to the next. And I rarely have paragraphs more than 4/5 lines long.

    @Matthieu: I feel exactly the same (read my answer below). But closing braces introduce *two* newlines (well, every sane code I’ve ever seen puts an extra newline after the closing brace). And that’s just too much separation.

    @Konrad: You make a compelling case in your answer, I still prefer dmischa's case for either having a single line (with the if) or using braces but I do understand now that I took your previous comment vastly out of context.

    @TNM : Whitespace is not free. Smaller fonts and larger fields of view increase cognitive loading, and thus perceptual error rates.

    When people who complain about wasted lines, I wonder, why do half of them use the brace style where even the `{` goes on its own new line. Baffling. I prefer a 3 line if stmt over a 4 line one. I'd also like to take the time to advocate programmnig on a portrait monitor display. You see TONS of lines.

    The one-liner does not work with most debuggers (it is not possible to trigger a break when the content of the 'if' clause is about to be executed).

    @hotpaw2: On the contrary. Smaller fonts and larger fields of view increase the amount that the programmer can see at one time. It is well-known that programmer comprehension of code falls off dramatically the moment he has to start scrolling his terminal or flipping pages of a listing. Read "Psychology of Computer Programming", by Gerald Weinberg.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM