Why is it considered a bad practice to omit curly braces?

java c# c++ c coding-style

63,726

Solution 1

Actually, the only time that's ever really bit me was when I was debugging, and commented out bar():

if(foo)
  // bar();
doSomethingElse();

Other than that, I tend to use:

if(foo) bar();

Which takes care of the above case.

EDIT Thanks for clarifying the question, I agree, we should not write code to the lowest common denominator.

Solution 2

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();

Solution 3

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

if(foo()) bar();

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

Solution 4

I also used to think it's better to only use braces when really needed. But not anymore, the main reason, when you have a lot of code, it does make it more readable and you can parse over the code quicker when you have a consistent bracing style.

Another good reason for always using braces, besides someone adding a second statement to the if, is something like this could happen:

if(a)
   if(b)
     c();
else
   d();

Did you notice that the else clause is actually that of the "if(b)"? You probably did, but would you trust anyone to be familiar with this gotcha?

So, if just for consistency and because you never know what unexpected things might happen when someone else (it's always the others that are stupid) changes the code, I always put braces, because it makes the source code more readable, quicker to parse by your brain. Only for the most simple if statements, like an if where a delegation is made or is switch-like, where you know the clause will never be extended, I would leave out the braces.

Solution 5

Lines are cheap. Processor power is cheap. Developer time is very expensive.

As a general rule, unless I am developing some absolutely resource / speed critical application, I would always err on the side of writing code that is

(a) Easy for any other developer to follow what I am doing

(b) Comment specific parts of the code that may need it

(d) Easy to modify if it needs to be in future (i.e. adding / removing code)

The speed or academic elegance of the code is secondary to these factors from a Business perspective. This is not to say I set out to write clunky or ugly code, but this is MY order of priority.

By omitting curly braces in most instances, it for me makes (b), (c) and (d) more difficult (note not impossible however). I would say that using curly braces or not has not effect on (a).

View more solutions

63,726

Bob

Updated on August 20, 2020

Comments

Bob over 3 years
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?
- Robert S. over 15 years
  
  This comes across more like a rant than a question. It's like you're saying, "I know why it's bad but I just don't care."
- Bob over 15 years
  
  I gave what I think is the most common argument against my case. I am asking for other reasons why I might be wrong.
- George Stocker over 15 years
  
  Argumentative? Could you rephrase? The answer you gave and the answer the top person gave are 'the answer', so your question really is self-answering.
- Bob over 15 years
  
  They are not 'the answer.' I am looking for other answers because I think the most common is wrong. For example, Torlack gave a C++ example about macros.
- Andrei Rînea over 15 years
  
  I agree with you. Omit them. Period.
- Piotr Owsiak over 14 years
  
  ...or use VB.NET and forget about it too ;-P
- Admin over 14 years
  
  WHO CARES ABOUT HOW MANY LINES SOMETHING IS IT IS IN 2010. Monitors are wide and cheap and high res! My monitor is 2048 X 1152 and I have TWO of them! Readability is way more important that saving 2 vertical lines when you can easily introduce subtle errors that are hard to find.
- Paolo Di Pietro about 14 years
  
  I use curly brace for conditions. I never used (that's why its a comment and not an answer) but found quite interesting the no-curly brace for "using" statement, I think it clarifies the reading.
- Adam Ruth almost 12 years
  
  Monitors are wide and cheap, but they aren't tall and cheap. Vertical space is more scarce than horizontal space.
- Chris Fong over 10 years
  
  @AdamRuth Turn them sideways :)
- learnvst about 10 years
  
  So you don't screw up like Apple with the SSL bug found in Feb 2014, LOL.
- Andrew Theken over 9 years
  
  Stacking usings without curly braces will not compile if you add a statement between them, while omitting curly braces on conditionals will compile, even if you add/remove a statement directly following the if statement. In one case, omission of curly braces cannot cause a runtime error, in the other, omission can easily cause a runtime error.
- Trevor over 9 years
  
  If you were serious about reducing lines of code, you would use this construct: foo && bar(); instead of single-line if-statements, foo ? doSomething() : doSomethingElse() instead of single-line if-else-statements, etc. Alas, most people aren't really serious about reducing lines of code. :)
- Trevor over 9 years
  
  Oops, missed the C# tag.
- Niels Abildgaard over 8 years
  
  If your biggest argument is line count something is wrong with your thinking on code :-)
- Néstor Sánchez A. about 8 years
  
  Extra curly braces are for people with bad indentation: they get lost and usually don't know that -for instance- any "else" belongs to the nearest "if".
- Chris Fremgen almost 8 years
  
  Re: "WHO CARES ABOUT HOW MANY LINES SOMETHING IS IT IS", Consolidated code makes it much easier to read when debugging javascript in browsers while viewing the website. And if this is the argument, why use helper functions at all?
- martinkunev almost 7 years
  
  @Trevor Reducing number of lines is not about reducing number of lines. It's about readability of the code. This is also the answer to why writing foo && bar(); is usually bad.
- Trevor almost 7 years
  
  @martinkunev exactly.
- Pryftan over 4 years
  
  It's only considered bad by people who need to learn how to parse code better. And as someone already mentioned if they have a problem without {} then what about ternary operators? The example isn't even nested! @martinkunev That school of thought and similar is so very limited. Too binary. Yes, yes, boolean tends for 1 or 0 but that's the result of the operations. The only problem with code like that is ... it depends on too many variables. But I know people also frown against code like: if ((s=socket(...))<0) though I never had a problem reading such code. Styling debates are barking.
Mike Scott over 15 years

That point was already made in the question.
Mike Scott over 15 years

That point was made in the question.
George Stocker over 15 years

Mike: Then shouldn't it be closed as 'not a real question'? Others made that point, did you vote them down as well? In the end, that's the actual answer as to why it's a bad practice.
Elie over 15 years

Not quite, actually. Yes, he mentioned the potential for this kind of bug, but I was talking about making your code bug-proof and removing potential for error as part of best practices.
tvanfosson over 15 years

You said "I don't need it" then gave a reason for using it: readability!
user1568901 over 15 years

Of course this is very subjective. Leaving them off sometime improves the readability.
James McMahon over 15 years

True, if I ever leave the brackets out, I keep one line, like others have mentioned. I've been bitten too many times but multi line bracketless statements. Even if you know to look out for it, it can still occasionally get you.
Elie over 15 years

I think he's trying to get more badges
Bob over 15 years

Is there really such a thing as bug proof code?
Bob over 15 years

I always argue the case that consistency is more important than actual style, why should we make an exception only in the case of usings?
user3532201 over 15 years

Bad examples. In both of those cases, I would factor that 200 line for loop into its own method, or preferably several methods.
Jon Skeet over 15 years

@Bob: Good point, and I do only do it occasionally. I wouldn't like to pretend that I have actual reasons here :) Actually, there's a reasonable reason - nesting the usings (and only usings) like that is fairly obvious, and you still end up with a block. I can't immediately see the danger.
Elie over 15 years

No, but you can make it more difficult. Read "Best Kept Secrets of Peer Code Review" by Jason Cohen (see link at the side of some pages here) to get a better idea of why you do this.
AaronLbk over 15 years

Your first example will not compile, this is the compile error you will recieve: Embedded statement cannot be a declaration or labeled statement
Bob over 15 years

The countless programmers in point 1, are they industry leaders that we should be following, or the LCD type of programmer?
rodbv over 15 years

Who is this Mike Scott and why is he the answer police? It always cracks me up that people have to state what's obvious. So why didn't Mike continue to comment on the added description that users are posting about this issue. Aren't all answers referring to the question?
Kena over 15 years

+1 for comment about python. I'm always amazed how "stupid" I can be when continuously switching between languages.
Treb over 15 years

They are our forefathers, those mythical figures who in ancient times laid the foundation of our craft as we know it today. We will forever be in their dept. One of the many important works they did was the abolishment of the evil know as GOTO. (Ancient times = 1970s to 1990s) 1970s to 1990s
josesuero over 15 years

yeah, that's what I do too. It forces you to add braces if you add another line, and it's pretty clear to see that bar() is actually part of the if, so bad things will happen if you just comment it out.
rampion over 15 years

b/c I'm an insensitive clod, and I'm obsessed with getting rid of the "cost" of function calls. :)
rampion over 15 years

True, but it DOES happen. Plus, any time a block is longer than the reader's screen is high, you'll have this issue. And you can't control your code reader's screen height. They might only see a couple lines on each side.
B Bulfin over 15 years

That indentation is horrible.
B Bulfin over 15 years

That's distasteful to some because the ternary operator is intended to calculate values. The flow control in your example is a side effect.
B Bulfin over 15 years

"I don't pay for space taken on screen." You do pay for it by not being able to see other code simultaneously.
B Bulfin over 15 years

Closing brackets should always be at the level of the block, never trailing the end of the last line.
Michael Kniskern over 15 years

@recursive - you are right. It looks like the common practice to use this for calculating value: en.wikipedia.org/wiki/%3F:
dumbak over 15 years

Best solution to this bug: Use Python. (Kidding, of course.)
user3532201 over 15 years

It does happen. That doesn't mean it should happen.
Nemanja Trifunovic over 15 years

Not very debugger-friendly, though. How do you set up a breakpoint on the "bar" part?
GalacticCowboy over 15 years

@Nemanja: Just put your cursor on bar(); and hit F9. Both VS2005 and VS2008 handle intra-line breakpoints, if they're separate "statements".
Jonathan Leffler over 15 years

The couple of pages of code should be in a separate function, usually.
Admin over 15 years

GalanticCowboy: There are more environments than those you know. :-)
Eric over 15 years

I dont get why it was downmodded it saves one line for every bracket pair i use it all the time
Nathan Strong over 15 years

if only all code declared itself as such... sigh
rampion over 15 years

excuse me, I meant I was playing the role of such a clod. However, I hold that the same problem can occur for shorter regions, when viewed through a small viewport. And that's outside the coder's control.
user2245201 over 15 years

That's rough of course, but I think the biggest problem for maintainers is that they will add a second line, and not realize it's not a part of the conditional statement even though it REALLY looks like it should be.
Andrei Rînea over 15 years

This is one of the two cases where I do use braces. Otherwise not.
jmucchiello over 15 years

This is more popularly known as K&R style. Based on the book The C Programming Language by Kernighan and Ritchie: en.wikipedia.org/wiki/The_C_Programming_Language_(book). And it should not get you modded down.
Nathan Prather over 15 years

Thanks! I figured it was just personal taste. I used to find this syntax annoying myself, but I adopted it after reading Code Complete, and really enjoy it now.
Kristen about 15 years

I wouldn't rely on a Unit Test to find that. LINT maybe, Unit test no!
Nosredna almost 15 years

I don't like the one liner style because I always go looking for the loop body below.
nickf almost 15 years

i was reading all the answers above this one thinking "why has no one suggested this yet???" It makes the closing bracket align with the block which it is closing, that is "if" or "while", etc, not a meaningless "{". +1.
Bob almost 15 years

Right click on bar and choose Insert Breakpoint... Not hard at all. Know your tools.
stone almost 15 years

Right clicking the indicator bar does nothing; do you mean right click the text? Anyway, if you only want the break point to be hit when the "if" statement is true, and "bar()" is on its own line, you can put the cursor anywhere in that line and press F9, or left click the indicator margin. If, however, all of the code is on a single line, you have to position the cursor on "bar()" or right click exactly there before pressing F9, and clicking the indicator margin won't work (places breakpoint on the 'if'). It's not "hard," but it requires less concentration when the code is on two lines.
stone almost 15 years

Oh, ha ha, right click on "bar()." You did mean the text. Gotcha. Sure, or just press F9...
stone almost 15 years

>>you have to position the cursor on "bar()" or right click exactly there before pressing F9, (I meant position the cursor exactly there before either pressing F9 or right clicking)
Brian almost 15 years

Try if (foo && bar) snafu() . C# supports short-circuiting :)
Piotr Owsiak over 14 years

The problem is solved when, in your 4th sample, you just put an empty line after if statement to seperate it from DoSomethingElse() That's what I do and readability is practically the same as with the 1st sample (if not better ;-P) Another thing is that putting lines in groups of 2 or 3 signifficantly helps readibility, you just scan through the code much faster.
dance2die over 14 years

Looking at Mono code seems quite foreign to me after reading the whole guideline.
MordechayS over 14 years

How about if (condition) {newline} DoSomething(); {newline x2} DoSomething(); ? I find that less verbose than 2 curlies for a single if. I find (when they're long) one line if (condition) dosomething harder to read but I think I'm in the minority there
Brian over 14 years

I agree that curly braces may be faster to read, but when you want to see more stuff at once, it increases reading speed of the individual stuff but decreases comprehension speed and requires more re-reads. And things become plain painful when you have curly braces for serial errorchecking code with many lines like, if (badCondition) return; It is not always practical to refactor such code into an or conditional.
Liggy over 14 years

@Kristen - The idea of the unit test is to assert the behavior of the method. If the behavior changes (as described above) the unit test will fail. I don't see the problem in that.
Ponkadoodle over 14 years

Maybe it's because I'm used to Python, but putting the first curly brace on the same line as the if statement allows me to read+understand it even quicker.
Nate C-K about 14 years

The problem with the braceless style it makes you waste your precious concentration thinking about whether or not the block has braces rather than more important things. This alone is a good enough reason to use the simplest possible convention, which is braces always.
Alan Plum about 14 years

As a former Java programmer, I have to fully agree with automated formatting being the real answer to the problem. You don't even have to have your editor add braces automagically -- auto-indenting alone can help avoiding ambiguities a lot. Of course now that I have switched to Python, I've become used to formatting my code properly in the first place.
Alan Plum about 14 years

I find the one-liner style more irritating than helpful because (especially in deep nesting -- ugh) the statement can be easily overread and confusion may ensue. I almost exclusively use such single-statement ifs for input validation (i.e. early returns) or loop control (e.g. ignoring irrelevant file names in filesystem walks), though, where blank lines help setting them off from the main code.
Gabi Purcaru over 13 years

@CrashCodes this is why I prefer adding lots of spaces in functions, especially before and after conditionals and loops.
Igor Popov over 13 years

I don't understand. You have a variable that controls the debugging (debugEnabled) and you still use comments to disable the debugging??? Why didn't you just set debugEnabled to false?
Igor Popov over 13 years

I feel the same about braces. It's all about the complexity. Ideally we would have only one line blocks. That's what I call readability, not unnecessary braces.
OscarRyz over 13 years

This is not exactly the scenario, but you make a good point. Stupid things ( like not setting debug to false ) do create subtle and stupid bugs that are harder to find than "obvious" bugs. Not using braces didn't help too much in this case.
Wick over 13 years

I prefer your second example. For me it's less about whether the specific curly brace characters match up, & about a conceptual start-matches-end thing.
Kelly S. French over 11 years

Your last statement about (a) is an opinion that a large number of devs, including other posters here, would argue.
Beska over 11 years

@AdamJaskiewicz Right. It does happen. We have to think about what does happen, rather than what should happen. If we could restrict ourselves to what should happen we wouldn't need to worry about bugs.
Andrew over 11 years

But why rely on Unit Test to pick up the glaringly obvious that should be fixed before going to UT?
alexander.biskop about 11 years

This should rather be written as if (a && b) ... in the first place methinks.
Ben Voigt over 10 years

@alexander.biskop: Surely not, since that gives the else block a different meaning (!a || !b) than either with (!a) or without (a && !b) added braces.
alexander.biskop over 10 years

@Ben Voigt: True! Fell for it ;-) Half a year and two upvotes later, someone realizes the statement I made is wrong...Guess I didn't pay enough attention to detail, mainly because the intention behind my comment was a different one than pointing out a technically correct transformation of that if-clause. What I meant was that nested inline if-statements generally decrease readability (and esp. traceability of control flow) significantly imho and hence should rather be combined into one statement (or circumvented altogether). Cheers
Ben Voigt over 10 years

@alexander.biskop: At the same time, debugging is easier with nested ifs each with simpler conditions, since you can single step onto each.
TheOptimusPrimus over 10 years

Braces are explicit by nature. I'll stick with that, thanks.
Per Lundberg over 10 years

In the last case, hunt down the original author and spank him... ;)
Bohumil Janda over 10 years

One-line style also hides the bar() from test coverage. It will look covered even if foo is always false.
nawfal about 10 years

The only time I prefer the first style is when I have to return immediately or throw an error in case something is wrong. Like if (parameter == null) return null;.
Suamere almost 10 years

+1 mostly to get you to 98. You'll hit 100 soon! But seriously, this entire issue is almost non-existent when people follow Single Responsibility. Not just classes... but Single Responsibility Solutions, Projects, Modules, Members, and even Single Responsibility Lines of code. When you do Unit Testing and/or Test-Driven Development, you're almost forced to break your code into tiny objects. In other words, this entire question is only an issue in procedural style long methods. And exactly as you point out, it's a readability issue, which is not an issue in Single Responsibility.
supercat over 9 years

If open braces are always placed on lines by themselves, then an if which is followed by a single indented line may be visually recognized as controlling a single statement without need for any braces. The open-brace-by-itself style thus saves whitespace in the situation where an if statement controls something that is semantically a single action (as distinct from a sequence of steps that happens to only contain a single step). For example, if (someCondition) / ` throw new SomeException(...)`.
supercat over 9 years

If open braces are placed on lines by themselves, then anyplace that two or more lines are indented without a brace pair will look wrong, as will any unmatched brace pair. Such usage will cost a blank line in cases where an if statement controls a block, but avoid the need for a block in cases where an if statement controls a single action rather than a block.
Andrew Theken over 9 years

This is another way of saying, "had the source included the curly braces, I wouldn't have wasted time while debugging." - adding the braces is trivially simple, and avoids leaving pitfalls for the next person. The only argument against is "readability," which is pretty tenuous, given that this is a case where something implicitly happens if you omit them.
Noctis over 9 years

just seen this almost happening in my code :) figured i'll have a look around, and lo and behold ... it's already out there :)
Almo about 8 years

Saving vertical space is not a virtue.
ruffin over 7 years

Is this always the case? That is, else priority always goes to the nearest if clause when no brackets exist? Makes sense (you gotta pick something), though I wonder what people used to do before keyboards had brackets. NOP? ;^)
gman about 7 years

@igor How about because they just wanted to remove one line of logging not all lines of logging?
Rich over 6 years

ReSharper suggests removing the braces. Either way is fine with me but I'd like to use whatever will be easier for someone (including myself) to read in the future.
ErrCode over 5 years

Demonstration that C# will complain as per mockobject's comment: dotnetfiddle.net/9r0AZg
FINDarkside about 5 years

This is even worse than not using brackets.
Pryftan over 4 years

@AndrewTheken Which is a way of NOT saying 'if I became better at parsing code I wouldn't have to worry about this problem ....'. Not once even in debugging has omitting the '{}'s caused me a problem. It also looks much nicer to my eyes. Add in the time that it takes to type them (even more so if on different lines) and it wastes far more time than saves.
Pryftan over 4 years

That's funny. I find it slower the way you find it faster. Which is just another reason or way of showing that style questions are so barking and akin to arguing about religions, gods or whatever else.
Pryftan over 4 years

@ruffin Yes. Always. But for a very interesting document about C history - written by Ritchie himself - see bell-labs.com/usr/dmr/www/chist.html. There you will also find an interesting titbit about the compound += at one point being the other way round! (That is it was =+). As for {}s remember structs? Functions? Etc.
Sedat Kapanoglu almost 4 years

I don't recommend this because eventually the content of the if expression and the name of the function bar() might change due to renames, changing requirements etc and might surpass max line length at some point. Another developer might see the overflowing line and wrap it. Then, you have the same dangling statement. I'd say never omit braces. It requires less thinking too, you don't need to ask yourself "should I put this in braces?" every time.
symbiont over 2 years

@SedatKapanoglu you can exceed the max line length by renaming, even if you always use braces. although i tend to agree with always using braces. i've made them one-liners, when i have many following each other to improve readability