19

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?

Improve this question
2
  • 4
    Order by simplicity / understandability of the conditions! The rest can be taken care of by optimisers, branch predictors and refactoring. – Marjan Venema Jan 5 '14 at 12:00
  • This is why we get paid the big bucks: to make these difficult decisions. – user251748 Jun 12 '17 at 19:52
25

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();
}
Improve this answer
5
  • 7
    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 '14 at 11:59
  • 2
    @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 '14 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 '14 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 '14 at 18:29
  • 2
    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 '14 at 19:17
6

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
Improve this answer
2
  • 2
    why is it more readable? I see no difference between the two in terms of readability – John Demetriou Feb 17 '16 at 9:57
  • 4
    @JohnDemetriou The Else is more visible if the Then is short. People scan for structure first, then assign meaning to it. Code without an Else is different from code with one, so making the Else more visible is more understandable. (All other things being equal, on Tuesdays when it is not raining, etc) – user251748 Jun 12 '17 at 18:51
4

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 ;-)

Improve this answer
2

I have found that the exact opposite pattern leads to easier to read code, and reduces or eliminates nested if statements. I refer to this as a "gauntlet" pattern. (In story telling, a gauntlet would be a series of challenges that have to be met successfully before the final task is completed.) By handling your edge cases first, you allow the main body of your code to be clean and concise:

if(gauntlet_1){ handle the first gauntlet condition }; 
if(gauntlet_2){ handle the second gauntlet condition };
...
// All preconditions (gauntlets) have been successfully handled

// Perform your main task here
Improve this answer
2
  • So the "handle gauntlet" part would either have to be a transfer of control, like a throw or return statement, or would have to actually correct the fault. Some people frown on a series of if ... return statements, but I don't and think it does in fact make the code easier to read, as you said. – user251748 Jun 12 '17 at 18:56
  • 1
    If the gauntlet condition is something that would prevent the function from succeeding, it returns an error immediately. If the gauntlet condition can be handled, I do so before entering the main body of code whenever possible. I am primarily trying to avoid nested IF statements, which in my experience are one of the primary causes of obscure and hard to debug coding errors. – Byron Jones Jun 12 '17 at 19:09
0

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.

Improve this answer
-1

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.

Improve this answer
-1

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.

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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