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

if (uncommon_condition) {
} else {

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?

  • 4
    Order by simplicity / understandability of the conditions! The rest can be taken care of by optimisers, branch predictors and refactoring. Commented Jan 5, 2014 at 12:00
  • This is why we get paid the big bucks: to make these difficult decisions.
    – user251748
    Commented Jun 12, 2017 at 19:52

7 Answers 7


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 ) {
} else {
  • 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. Commented Jan 5, 2014 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
    Commented Jan 7, 2014 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 :-) Commented Jan 7, 2014 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
    Commented Jan 8, 2014 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). Commented Jan 8, 2014 at 19:17

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

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

is more readable than

if (s != null)
    // long
    // code
    // block
    // short code
  • 2
    why is it more readable? I see no difference between the two in terms of readability Commented Feb 17, 2016 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
    Commented Jun 12, 2017 at 18:51

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

(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
  {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

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


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


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
  • 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
    Commented Jun 12, 2017 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. Commented Jun 12, 2017 at 19:09
  • I really like using "the gauntlet" upon entering methods to express the idea that arguments are invalid and therefore execution cannot proceed. The intent is also definitely not exception prevention. Instead it is distinct from a rational or even default choice of an if ... ( elseIf ) ... then. Oh, hmmm... say, maybe a secretary submitting a blank piece of paper rather than the expected business letter. ( Business offices are naturally typing safe in some respects! get it? haha )
    – radarbob
    Commented Aug 7, 2021 at 22:30

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.


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.


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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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