hmm
one line
no status variable
same result

Just dont be doing this in C# and Java! =)

Please… you really want to mess with stable and understood ideas such as exception handling? I’ve written this same code in C many many years ago, and I dont believe there’s a compelling reason to go back (even if it is to save a few cpu cycles).

status = doWhatYouWant();
}

The standard macro is illustrated in http://en.wikipedia.org/wiki/C_preprocessor#Multiple_statements and widely used in well-written macros.

http://go-oo.org/lxr/source/sc/sc/source/filter/xml/xmlimprt.cxx#2540

In the code base I now work on, there is a plenty of over-nested if-statement blocks like this one above. In fact, that one is not bad in comparison to some of the worse ones I’ve encountered.

Thanks for the good piece, Dennis!

If the condition on line X of a function being true prevents the remainder of the function from being executed and causes ‘3′ to be returned, it should read like that:

The second function clearly shows that condition1 being true results in 1 being returned and no more code being executed.
To obtain the same insight into the first function you must read through the if..else.. structure, and check any code after it – simple in these contrived examples but in real code it can be harder.

Now, if we are in an environment where RAII cannot easily be applied – e.g. C – then continuing through the function until cleanup is necessary, but the second example shows far more easily what it is than the first.

boolean status = true;
status &= doSomething();
status &= doSomethingElse();
status &= doWhatYouWantedToInTheFirstPlace();
return status;

(Works for Java anyway, my memory of C logic operators is a little hazy)

statements. That’s clear to you? As anonymous said, multiple exit points are always a sign that you need to think twice.

statements are not your enemy, there is no reason to avoid them. If you are writing branching code, then avoiding them seems pathological to me. That’s why they exist!

IMHO the ‘flatter’ (i.e. less nested) a function is, the more readable it is. If the execution of line #3 of a 20 line function results in none of the rest of the function being executed, it is easier to read if it states that *explicitly* by using the ‘return’ keyword. It’s similar to the exception’s ‘fail-fast’ mechanism

My opinion only, but I feel strongly on this one…out of interest why do you believe multiple exit points make a function more readable?

If the language does not allow, or the status is not an error it would be far more appropriate to wrap the whole thing in a function and use return:

function doTheThing()
{
// preconditions
int status = doSomething();
if (status)
return status;

status = doSomethingElse();
if (status)
return status;

// computation
return doWhatYouWantedToInTheFirstPlace();
}

It makes the exit points from the function far more readable, and reduces nesting.

int m1() {
int status = 0;
// preconditions
status = doSomething();
if (status) return status;

status = doSomethingElse();
if (status) return status;

// computation
status = doWhatYouWantedToInTheFirstPlace();
return status;
}

void m2() {
int status= m1();
if (status) {
// cleanup
}
}

status = DoSomething();
if(!status)
{
status = DoSomethingElse();
}
if(!status)
{
status = DoWhatYouWantedToInTheFirstPlace();
}