Comments on: Braceless if considered harmful

By: 123

123 — Sat, 28 Mar 2009 22:05:43 +0000

If you’re dumba$$ enough to not notice the bug in this example IMMEDIATELY, you need to switch professions fast, not ruin others’ code with your overly verbose, ugly crutch.

if (x > 3)
__y = x – 3;
__doSomething(x);
// continue with rest of program…

By: Sean M. Cox

Sean M. Cox — Fri, 18 Jan 2008 22:07:35 +0000

Personally, I like to have simple single line if statements without the braces. I did it the other way for years until I discovered that braces weren’t required. (Learned it from the source library for the standard Java classes.) To me, the code is just much prettier – cleaner looking – without the braces and I, personally, have never run into any of the issues that have been described. However, I can certainly imagine that some might have trouble following the braces, or lack thereof. For me it has worked and the aesthetic satisfaction I get from looking at the code produced weighs in significantly against the potential bugs that I have never experienced.

I also like to keep my conditions separate from the code that depends on them as I find it more readable that way. (Especially when I have a moderately length condition or longer.)

Certainly this could be different in a collaborative environment.

By: MetaphoriC++

MetaphoriC++ — Fri, 09 Nov 2007 04:44:42 +0000

I agree with truth machine. In 20+ years of programming (C, C++, Lisp, Java, Perl and now PHP…) we never met the problem (bug),
if (x) y(); z();
The code should be indented with the right tool anyway (e.g. Emacs). A good programmer doesn’t fall in such a “trap”.
In Perl when there are a lot of consecutive if-else[if] statement, the code is full of {}s even for single statements – it is harder to read. if (a) { while (b) { if (c) { for (;d;) { e(); } } } } ??

As for the
// A if (x) { y(); z(); }

// vs B if (x) { y(); z(); }
I go for B. Someone will inject a line between the “if” and the “{“? and let the {}s alone??
When there is a lot of nested conditions/while/for… the code is well spaced out, and readability is increased.

By: truth machine

truth machine — Thu, 14 Jun 2007 08:58:09 +0000

Anyone who can’t immediately see the error in the example with two indented statements without braces is broken; such people are bug-prone in any case, and lord only knows what other blatant bugs they’re missing because they are incapable of reading the language. But even such broken people can avoid this sort of bug simply by using the right tools — use an auto-indenting editor and such incidents simply can’t happen. That’s a far better crutch for those who need one, especially since such broken people are liable to forget to add the required braces — if they can’t be bothered to notice something as obvious as that they’re adding a second statement to an if block without braces, then they can’t be counted on to add the extra braces. If I had a maintenance programmer who was that sloppy, I would transfer them immediately to QA where they could experience the consequences of such behavior.

By: Kevin

Kevin — Wed, 06 Dec 2006 23:37:31 +0000

The problems described above would not happen in a Test Driven Development environment (typically XP shops).
If I’m not attentive and forget my braces, I’ll discover my error in the next few minutes.

“What if someone adds another line and forgets to add the braces?” – This is fear-based programming and has no place in confident, courageous coding.

By: The Cafes » RatJava

The Cafes » RatJava — Mon, 13 Nov 2006 18:24:13 +0000

[...] Smart developers have known for years that braceless multiline statements are bug prone. The problem is that the indentation can be actively misleading and cause bugs during code evolution and maintenance. For example, suppose you start with this if statement: [...]

By: Masklinn

Masklinn — Sat, 23 Sep 2006 19:32:01 +0000

> will always run dosomethingelse() IT IS SUPPOSED TO WORK THAT WAY. You see?

The point of the post is that 95% of the time it isn’t supposed to work that way, and it’s a bug.

And when it’s supposed to work that way and isn’t a bug, then it’s sheer stupidity, because most programmer’s eyes are trained to check the fastest way to see blocks: check indentation.

Therefore most people will think that dosomethingelse() is inside the if block, and will misunderstand the code unless they take a second look at the exact code.

Therefore, that kind of code is either a “software bug” (the software will be buggy) or a “programmer bug” (the programmer won’t get the code, and will be buggy).

> if (x>3)
> {
> ####dosomething();
> }
> Is simply an excesive usage of space for a single-line if.

And this is why Kernighan and Ritchie invented the K&R style
if (x>3) {
doSomething();
}

Look ‘ma, no excessive use of space even for single-line conditionals!

By: disgusted

disgusted — Thu, 14 Sep 2006 16:09:32 +0000

if (x>3)
####dosomething();

Now if I want to add a line of code:

if (x>3)
{
####dosomething();
####dosomethingelse();
}

(used # instead of spaces in the case this form would cut blank space)
You see? I know that not using {} only works for one line. The fact that I used braceless if in the first time is proof that I already know about this. And I also know that the compiler ignores whitespace so if:

if (x>3)
####dosomething();
####dosomethingelse();

will always run dosomethingelse() IT IS SUPPOSED TO WORK THAT WAY. You see? I am coding in JAVA/ C++ / C# I am sure that I am not coding in python, so I can’t expect that if to cover both statements just because of the identation.

if (x>3)
{
####dosomething();
}

Is simply an excesive usage of space for a single-line if. In my opinion, others may argue that but that’s the good thing about this world, I can use that syntax, I am not using a condescendant compiler that expects me to make silly mistakes.

But in my opinion the best would be if (x>3) dosomething() ; It is logical, it is short and prevents the first mistake.

“However in the heat of programming, especially maintenance programming, itâ€™s really easy to miss this”

By: John Cowan

John Cowan — Thu, 02 Mar 2006 21:19:18 +0000

I don’t understand what cuddled elses (putting } on the same line as else/catch) has to do with safety. Can someone explain that?

By: Alex Blewitt

Alex Blewitt — Thu, 23 Feb 2006 13:10:41 +0000

It’s also a justifiable reason for always putting { on the end of the line, and } else { on the same line. Arguing about aesthetics is one thing (whichever ‘reads’ better to you is the one you’ve been using the most) but putting } and { on the same line as the if/while/for/else/try/catch is the only way to prevent errors by insertion of a line of code. It doesn’t even have to do anything; a System.out.println() will break code if put in the wrong place.

Alex.