That reminds me this code:

if ( ... ) try {
..
} catch (Exception e) {
..
} else {
...
}

Every time you are combining two types of blocks, forgetting braces and not increasing indentation, you are creating code very difficult to understand and maintain.

Perhaps it is because I learnt my trade (way back when) using the Jackson Entity Structure Diagram method, but I subscribe to the view that the only correct unbraced term after an if or an else is a subsequent if (ie allowing an else if ladder)

Anything else (no pun intended) leaves potential for misunderstanding and/or maintenance issues. That is the central aspect of the OPs idea being “unsafe”.

I’d also be very cagey about including the while() on the same line as the else – whether braced or not. It doesn’t read right to me… the lack of any extra indentation masks that it is the else clause. And lack of clarity makes for misunderstandings (see above).

So in the example I would strongly advise/recommend (and insist, in my team) on:

if ( blah )
{
    ...
}
else
{
    while ( !bloop() )
    {
        bar();
    }
}

Of course, I would also expect to see suitable comments too.

— Edit —

Recently Apple suffered from an SSL vulnerability, caused by a poor maintenance fix – that added a second line to an un-braced single line. So let’s put to bed the idea that unbraced single lines are OK?

I have always been taught to keep everything in braces, indented and commented. I believe it’s much easier to read and spot errors. Personally i feel modularity is key so i would always write the code like this :

    if(blah)
    {
     ....
    }
    else
    {
       while(!bloop()
       {
        bar;
       }
    }

I would extract method and make it

if ( blah )
{
    ...
}
else
{
   newMethod();
}

See “extract method” approach explained at Refactoring Catalog site:

You have a code fragment that can be grouped together.

Turn the fragment into a method whose name explains the purpose of the method.

Plain text

Copy to clipboard

Open code in new window

EnlighterJS 3 Syntax Highlighter

<code>void printOwing() {

printBanner();

//print details

System.out.println ("name: " + _name);

System.out.println ("amount " + getOutstanding());

}

</code>

<code>void printOwing() { printBanner(); //print details System.out.println ("name: " + _name); System.out.println ("amount " + getOutstanding()); } </code>

void printOwing() {
    printBanner();

    //print details
    System.out.println ("name:    " + _name);
    System.out.println ("amount    " + getOutstanding());
}

                                                                                                        

Plain text

Copy to clipboard

Open code in new window

EnlighterJS 3 Syntax Highlighter

<code>void printOwing() {

printBanner();

printDetails(getOutstanding());

}

void printDetails (double outstanding) {

System.out.println ("name: " + _name);

System.out.println ("amount " + outstanding);

}

</code>

<code>void printOwing() { printBanner(); printDetails(getOutstanding()); } void printDetails (double outstanding) { System.out.println ("name: " + _name); System.out.println ("amount " + outstanding); } </code>

void printOwing() {
    printBanner();
    printDetails(getOutstanding());
}

void printDetails (double outstanding) {
    System.out.println ("name:    " + _name);
    System.out.println ("amount    " + outstanding);
}

I would consider it as a bad habit of coding. Sometimes it works perfectly fine and you will have no problem in compiling and running the code. At other times it may cause serious bugs and you will end up spending hours in fixing that bug.

It is always recommended to modularize your code. If you have to put a while loop in else part put it in a block so that others, when working on your code can easily understand the logic.

if ( blah )
{
    ...
}
else
{
    while ( !bloop() )
    {
        bar();
    }
}

It’s a good practice to put code in blocks. It makes it simpler and easier to understand and debug as well.

It might be fine if it stays simple like that although personally I don’t like it and my preference is to use braces even for the simplest if/else code blocks. It’s just tidier for me.

However, where this gets messy is when you have nested if/else loops some with braces some without. A While loop in the middle of all that spaghetti! I’ve worked with code that bad and it’s a nightmare to debug and to understand. This follows on from the first point it’s fine when it stays simple and you’re happy with it, but then other programmers come along and add things to it, probably an if else within the while loop. If it’s written clean in the first place then there’s less chance of this happening.

The point is to make stuff clear so that other programmers can see at a glance what’s right and wrong. Write code so that the pattern looks right and doesn’t jar.

The flip side of this is that maybe I could see some people claiming that in certain instances this reads well. If I’ve got the resource I need do this processing else while I’m waiting for something do this. Even then to me there’s still no difference in nesting the while loop inside the else block.

Well, despite everyone argues about using braces and seem to love them, I actually prefer the opposite. I only use braces when I have to because I find it more readable and concise without.

if (...)
   foo();
else while(...)
   bar();

…I actually find this “else while(...)” remarkably readable! It even reads like plain English! But I guess people will all find it strange because it’s unusual to say the least.

In the end, we all tend to make it idiot-proof with braces though …because, well, you know.

What is so wrong with braces that so many people is trying to avoid writing them ?

What problem does exactly else while solve ?

Braces are cheap and good, and they make code intention evident and plain as opposed to clever and witty.

Quoting Unix Philosophy:

Rule of Clarity: Clarity is better than cleverness.

Because maintenance is so important and so expensive, write programs
as if the most important communication they do is not to the computer
that executes them but to the human beings who will read and maintain
the source code in the future (including yourself).

I always put braces, just because you might add another line when in hurry, indent it, forget the braces and scratch your head what’s happening. I keep the opening bracket on the same line, but it doesn’t matter. I both cases it’s better to have them.

if(blah) {
    foo();
}
else {
    bar();
}

There’s nothing wrong with

if (blah)
    foo();
else
    bar();

just like there’s nothing wrong with

if (blah) foo(); else bar();

in the right circumstances (your circumstances may vary, but that particular style is best used when you have a lot of repetitive code – then the view of each line is more important than the stylistic indentation)

But if you choose one way, keep to it – consistency is king. So your second example is very bad, as the if expression had brackets for its statement, the while statement should be inside the brackets for the else clause, not outside it.

besides, I have seen this code before:

if (x) foo()
{
  bar();
}

and it was written by the coding standard nazi himself (who insisted on brackets for everything).

Modern IDEs can easily be configured to reformat (including removing or adding unnecessary braces) and/or reindent the code on saving a file. Thus your example would automatically look like for instance

if (blah) {
  blub();
} else
  while (!bloop()) {
    bar();
  }

The indentation always makes the nesting easily visible, even without unneccesary braces. So, if you manage to enforce such IDE settings, I see no risk.

Personally, I find code that omits the braces and linebreaks much more readable since it avoids clutter:

if (blah) blub();
else while (!bloop()) bar();

But of course, many developers are very happy to argue about such things forever and a day.