First of all, it states that the following is allowed, but dangerous:
if (condition)
Exactly one statement to execute if condition is true
else
Exactly one statement to execute if condition is false
Well, all fine and dandy and I can see where it's aiming to. The thing is, that very form is the only form that exists. The braces just serve to gather several statements up to form a single statement, they're by no means part of 'if' syntax.
The first actual reason stated, as to why not leave the braces out, is the following situation
if (condition);
do_something();
Well, OK. I can see how one can accidentally type the semicolon after the if clause. But then again... Hello, it's 2008 calling! You won't believe what cool things our program editors nowadays have. They colour the different parts of code with different colours and you know what: they even indent your code for you! Amazing, ain't it?
if (condition);
do_something();
That certainly doesn't look like such a big error anymore. Also, if one can go and write an extra semicolon after the if clause, why couldn't this happen as well?
if (condition); {
do_something();
}
Even automatic indenting won't save you from that!
The other reason is one, I think I've seen quoted a few too many times:
if (condition)
do_something();
do_something_else();
Yes, the old case of "What if someone later on wants to add more functionality to the if block?" Well, 2008 calling again and all that. Try writing that to any even semi-decent programming editor. It becomes this:
if (condition)
do_something();
do_something_else();
Not so dangerous error anymore, either. You can clearly see that the second statement doesn't belong to the if block.
Also, it crossed my mind that both these errors become invalid code, if you have an else block after that if. That's pretty much a corner case though.
3 comments:
Guess what? It's 2008 and I just fixed one of those bugs with an extra semi-colon and no curly braces in the Inkscape sources just the other week.
:-)
Still a problem... still trickier to see...
But remember, if the convention is to always use braces, then reading through code for problems (including color-coded editor reading) goes faster. If the convention is to use braces *sometimes* and then to not use braces other times, reading through code goes much, much slower.
Oh, I forgot. It's 2008; people aren't stuck on 80 column 25-line terminals any more. You can afford an extra vertical line for a closing brace.
:-)
Yes, I agree. It's not using the curly braces that irked me, it was the reasoning given. Having a consistent style is indeed one of the good reasons to always use the curly braces.
Also the screen estate is indeed no longer a big problem. The computer I code on doesn't have too big a screen and it's actually widescreen format so it can't fit too many lines on screen. But I still get something like 60 rows onscreen, quite enough to fit a well-sized method on screen even with the extra line for closing brace.
Post a Comment