tags:

views:

181

answers:

6

As the topic states, sometimes these issues conflict. For example...

In this case, the nominal case is first, but the expression is negative.

if ( !foo.IsDead() ) {
  DoThis();
} else {
  DoThat();
}

In this case, the expression is positive, but the nominal case is last.

if ( foo.IsDead() ) {
  DoThat();
} else {
  DoThis();
}

Of course, a third option would be to flip around the IsDead function to be IsAlive(). I'd like to hear others' thoughts on these 3 choices when they encounter them in coding. Do you go with nominal, positive, or fix the whole thing by flipping the boolean itself.

+2  A: 

I prefer option two as it's slightly clearer / easier to read.

But you're heading for religious war territory I suspect.

In terms of flipping the name of the function, I'd only change if isAlive() is the most likely outcome. That is, I think the code is clearer if the most likely outcome is your boolean expression equating to true. The least likely (false) should come second. It it's 50/50 then I wouldn't worry.

dave
It isn't 50/50. So when writing functions with boolean return values, the value returned should be the nominal value is what you're saying.
Anonymous
+1 for warning about a religious war! :P
GrayWizardx
+1  A: 

What are you going to check for more - being alive or dead. If the scale tilts significantly towards one of them, you should name the predicate method accordingly.

As for placing nominal or positive cases first, I'd go with the nominal. It's not that hard to figure out !dead as being alive or vice versa, but it's always nice to see the main flow of execution first and the exceptional cases later.

Eli Bendersky
A: 

I think it depends on what the frequency of interaction is. In general I was taught that you should always put the most frequent, or most likely case as the true evaluation for the if case, and put supsequent ones in the else block. I think it is a matter of personal choice though.

GrayWizardx
+1  A: 

When arranging the if statements, I put them in order of frequency if I know it at all. This surely improves performance.

When dealing with code that checks for error and then progress accordingly, I always put the error handling code in the last if statement. This contributes to code readability.

Regarding your 3rd option, I only make sure that the method name itself is not negative such as isNotAlive(), otherwise I take it just fine.

You may want to read Section 15.1 (if Statements) of Code Complete. This section discusses about an almost similar issue.

Programmer in Paradise
+1 for names in the negative ... isNotAlive() ... arrrrrrggggghhhhh
pmg
A: 

I don't like something like this..

 if ( IsDead() ){}
 else
 {
  //do something.
 }

so I would prefer the former.

sevity
A: 

I suggest using which ever is most readable and easy to follow. Worry about performance if and only if it is an issue that users are complaining about (directly or indirectly). A slow correct program is always better than a fast program that is unreliable.

If you are worried about the optimization, reduce the number of comparisons. Comparisons cause branches (jumps). Branches annoy computers because it causes them to clean out their instruction caches, sanitize them, make them smell nice, then reload them. Most processors only clean out their caches in the spring time with other people. :-) Although some have been known to empty out their caches when purchasing gifts.

Thomas Matthews