The Only Reason To Use Curly Brackets Blocks For IF-Statements

Without curly brackets, you could accidentally write a semicolon after the IF-statements. The semicolon is a valid, empty statement, which will be "execute" instead of the actual (intended) one.


         if(condition );
                doSomething();

So either write the IF-statements with curly brackets blocks:

         if(condition ){
                doSomething();
         }

...or carefully search for semicolons after the IF-statement.

Comments:

Nothing prevents you from writing
if (condition); {doSomething();}

Posted by Heiko Behrens on September 22, 2009 at 01:48 PM CEST #

This is bad:

if ( condition )
__doSomething();
__doCondition();

I use only if-conditions w/o curly brackets on fast return and single lines:

public String trim(String s) {
__if ( s == null || s.length() == 0 ) return s;
__// Trim the string...
}

br, josh.

Posted by Aljoscha Rittner on September 22, 2009 at 03:28 PM CEST #

Hi Adam,
I understand your point. But in an environment with a wide range of skill levels, having a consistent standard does have benefits.

I ask our team abide by: http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#449
(At least its formally documented)
So that code reviews don't have any surprises either logically or stylisitically.

-AB

Posted by A Buckton on September 22, 2009 at 04:10 PM CEST #

I constantly use auto-format feature in my IDE (Ctrl+Shit+F in Eclipse).

It prevents from...

if(condition );
doSomething();

or even...

if(condition )
doSomething();
doAgain();

...because the code will be indented correctly. It makes clear to see what is inside if statement or not.

Posted by A Casa do Java on September 22, 2009 at 08:52 PM CEST #

@Heiko,

a very good point. But this is less likely. You would in general begin the block right after the if statement, so a misplaced semicolon will probably be inside the block.
Actually I had to look at your code twice, until I found the problem :-).

thanks!,

adam

Posted by Adam Bien on September 23, 2009 at 12:52 AM CEST #

@Josh,

I wrote successfully one-liners without any problems right after the if-statement for about 15 years :-).

Last week I spent about 1h for debugging and found a misplaced semicolon - I suspect a revenge here :-).

thanks!,

adam

Posted by Adam Bien on September 23, 2009 at 12:59 AM CEST #

@ABuckton,

absolutely! If there is a standard available- you should at least evaluate it. For some reasons I tweaked the Sun's coding conventions for my purposes over time. Will have to re-sync myself again :-),

thanks!,

adam

Posted by Adam Bien on September 23, 2009 at 01:02 AM CEST #

I use curly brackets after if ALWAYS.
When first writing code, they are almost useless as error prevention.
But when I or someone else myst change the code and add another line, its much less error prone to have these braces already there.

But I'm in camp of those who adds useless lines and then fold them.

Posted by 195.39.65.70 on September 23, 2009 at 12:14 PM CEST #

I prefer always using braces, even if it's a simple one line statement in the if. I also always use code formatting in the IDE, and turn on the option to force braces on all control statements.

If there is an error, and you format your code often to stick to the standard style on the project, you will most likely pick up errors ("Hey, why is that not indented?? Why is there a single semi-colon on that line with nothing else? Oh, it's outside the block, doh!")

Another useful thing about this is on a team based project, ensuring that developers format the code before committing/merging code to the source repository, it makes merging and code reviews so much easier (assuming all members on the team use the same formatter).

Posted by James Barrow on September 23, 2009 at 12:54 PM CEST #

If you ever fall into to the dangling-else problem (hint: c traps and pitfalls) you never ever forget to use curly braces.

Anyway, this is a perfect topic for religious wars.

Posted by Olaf Heimburger on September 23, 2009 at 10:12 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments
License