Writing Rightly

[woodwardiocom]

For the programmers out there: Say you have an if, where one case is an error condition which can be handled in a couple lines of code, and the other is the normal condition, which requires 20-30 lines of code. Which order do you put them in?

// Order the first.
if (ErrorCheck())
{
    HandleError();
}
else
{
    // Twenty or thirty lines of code go here.
}

// Order the second.
if (!ErrorCheck())
{
    // Twenty or thirty lines of code go here.
}
else
{
    HandleError();
}

Code Complete says, "Put the normal case after the if, rather than after the else." (This would be the second way.) It then goes on to justify this by the principle, "Put code that results from a decision as close as possible to the decision."

The thing is, I think the first way adheres to that principle better. If you do it the second way, your error handling may be more than one page away from the decision, so you can't look at it and the decision at the same time. Whereas, if you put the shortest case right after the decision, you can see both branches at the same time, and both right next to the decision.

Opinions?

Comments

[tactical-grace.livejournal.com]

It's going to come down to a stylistic preference, and there are decent arguments on either side.

My preference is to put the error condition at the top, for pretty much the reasons you describe. There are some circumstances when I might make a different choice, though.

[bluegargantua]

I think you're ok in this case because the non-normal case is so short. If the error condition also required some work beyond HandleError(), then I'd go with the book's suggestion.

later
Tom

[caulay.livejournal.com]

I always try to put the most common case first, especially if it is longer. I say "try" because sometimes the syntax to accomplish that becomes rather complex and confusing. (In *that* case, I try to simply the "if" syntax as much as possible and let if fall out that way.)

This is mainly for debugging purposes, since it's most likely that any errors will 1) be seen in that section first and 2) are more likely to exist there in the first place but it's also useful for maintenance, since it's most likely that if there are changes to the behavior to be made, they'll be made to the "normal" case.

[ectropy.livejournal.com]

if(ErrorCheck()) {
HandleError()
}

That puts it right up front, "If we screwed up, fix it." And if you can write the code to support it (HandleError, then return out of the function), you might not even need an explicit else-statement, which makes the code much easier to read.

[mrw42.livejournal.com]

If the code is at all performance-sensitive, you should put the normal case first, because the optimizer will assume that the "if" case is more common than the "else" case and optimize accordingly.

If the code is not performance-sensitive, do whatever makes it easier to read.

[ceo]

I typically do

if(ErrorCheck())
{
  HandleError();
  return retval;
}

// Twenty or thirty lines of code go here.

Early return is a controversial topic in C/C++; there are those who argue for a single-entry-single-exit rule (the single-entry part dates back to the bad old days when people thought it was OK to goto into the middle of a function). I feel this makes the code unnecessarily convoluted, particularly for things like error checking.

The real C++ way to do this, of course, is

if(ErrorCheck())
{
  HandleError();
  throw "something bad happened";
}

// Twenty or thirty lines of code go here.

[dmmaus.livejournal.com]

Personally, I'd do it the second way, because my internal feeling of how code should work goes like:

if (everything's okay)
    do the usual stuff
otherwise /* and this is hopefully a very rare occurrence */
    panic!

YMMV.

I tend to do it the second way

[drwex]

to some degree this is governed by the try/catch paradigm.

I don't feel strongly about it, though.

[notthebuddha.livejournal.com]

I think 20-30 lines of code in an if-then is too many regardless; that many functional lines can almost always benefit from being rolled into a separate function for re-use, or involves fussy twiddling that I keep separate, so I can try different approaches to improve it and profile one from the others by changing one line instead of a dozen.

When I need to see code more than a screen apart, and the IDE doesn't support multiple opens of the same document, I'll open Ultra-Edit or Notepad++ along side, which allow multiple opens and auto-detect changes from other sources. And there's always portrait mode.