Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In some code I'm writing right now, I have something like this:

if (uncommon_condition) {
    do_something_simple();
} else {
    do();
    something();
    long();
    and();
    complicated();
}

Part of me thinks "It's fine the way it's written. Simple cases should go first and more complicated cases should go next." But another part says: "No! The else code should go under the if, because if is for dealing with unusual cases and else is for dealing with all other cases." Which is correct or preferable?

share|improve this question
3  
Order by simplicity / understandability of the conditions! The rest can be taken care of by optimisers, branch predictors and refactoring. –  Marjan Venema Jan 5 at 12:00

6 Answers 6

up vote 14 down vote accepted

Order by their likelihood of being executed. The most common, most likely, etc. condition(s) should go first.

The "difficulty of dealing with them" should be dealt with by code structure, abstraction, etc. in the example the else block could be refactored to single method call. You want your if clauses to be at the same abstract level.

if ( ! LotteryWinner ) {
    GoToWorkMonday();
} else {
    PlanYearLongVacation();
}
share|improve this answer
5  
For performance I might agree. But then again, most optimisers and branch predictors are perfectly capable of taking care of that. For readability I might agree if the most likely case has significantly more lines than the less likely case. But to me that would sooner indicate the need to extract a method than to use a not. Personally I would concentrate on avoiding not conditions. They have been proven to induce more cognitive load to understand than "positive" conditions and are detrimental to readability / understandability of code. I tend to use them in guard statements only. –  Marjan Venema Jan 5 at 11:59
1  
@MarjanVenema, I can see your point about "not"ing. But the double negative is the real "not" WTF. The other day I ran into this in our code doesNotAllowxxFiles = false. Bad enough but then do this if(! doesNotAllowxxFiles) –  radarbob Jan 7 at 4:17
    
Yep, double negatives, negatives combined with and's and/or or's (sic!) and negatives combined with a method/var with Not in the name, get my brain in a twist every time :-) –  Marjan Venema Jan 7 at 6:56
    
if you find yourself having trouble understanding what's going on, I think it's often useful to do thing like: simpleBool = (!(complexBool || randomfFlag)) && !randomFlag –  TruthOf42 Jan 8 at 18:29
    
I would agree with you, except for the existence of Guard Clauses (which always have the exceptional condition in the THEN portion of the IF statement, not the common condition). –  Robert Harvey Jan 8 at 19:17

No fixed rule as such I heard about the usage but I follow like this

if(usual)
{
(more often)
}
else (unusual)
{
(rarely occurring)
}

But if both have same function with different properties then better go for unusual first then usual so that you can save one instruction.


if(x == 0)  // 1
  {x = 1;}  // 2
else
  {x = 2;}  // 3

For above code assembly code will be something like this:

1. 000d 837DFC00        cmpl    $0, -4(%ebp)
   0011 7509            jne .L2

2. 0013 C745FC01        movl    $1, -4(%ebp)
   001a EB07            jmp .L3

    .L2:
3.001c C745FC02         movl    $2, -4(%ebp)

        .L3:

If condition inside if is true then flow is 1->2( 4 intructions)
IF condition inside if is false then flow is 1->3 (3 intructions)

So its better to put unusual or rarely occurring events in if part and normal condition in else so that we can save one instruction every time ;-)

share|improve this answer

Try to enhance readability. One way is to place the longer code block into the else part.

if (s == null)
     // short code
else 
     // long 
     // code
     // block

is more readable than

if (s != null)
    // long
    // code
    // block
else
    // short code
share|improve this answer

For me it's more about the conditions than the complexity of the code they execute. You need to order the conditions so as to trap unusual conditions first, then the more common after. Also, if the else code is really long and complicated, I'd probably make a sub for that, to keep the conditional part obvious for the reader.

share|improve this answer

I don't have a fixed rule, but generally I follow this - first, consider where there's a missed design pattern that will factor this out. If not, I write it so that the condition in the if is the most clearly understood. That is, avoiding double negatives and the like.

share|improve this answer

As for such scenarios there is no thumb rule for it. But possibly we can follow to write the positive or most likely code in the if block and left out in the else block or default cases.

share|improve this answer
    
this does not offer anything over what was already explained in earlier answers - programmers.stackexchange.com/a/223093/31260 and programmers.stackexchange.com/a/223520/31260 –  gnat Jan 9 at 13:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.