What to put in the IF block and what to put in the

Question

This is a minor style question, but every bit of readability you add to your code counts.

So if you've got:

if (condition) then
{
   // do stuff
}
else
{
   // do other stuff
}

How do you decide if it's better like that, or like this:

   if (!condition) then
   {
     // do other stuff
   {
   else
   {
     // do stuff
   }

My heuristics are:

1. Keep the condition positive (less mental calculation when reading it)
2. Put the most common path into the first block

Answer 1

I generally put the positive result (so the method) at the start so:

if(condition)
{
doSomething();
}
else
{
System.out.println("condition not true")
}

But if the condition has to be false for the method to be used, I would do this:

if(!condition)
{
doSomething();
}
else
{
System.out.println("condition true");
}

Answer 2

If you must have multiple exit points, put them first and make them clear:

if TerminatingCondition1 then
  Exit
if TerminatingCondition2 then
  Exit

Now we can progress with the usual stuff:

if NormalThing then
  DoNormalThing
else
  DoAbnormalThing

Answer 3

I prefer to put the most common path first, and I am a strong believer in nesting reduction so I will break, continue, or return instead of elsing whenever possible. I generally prefer to test against positive conditions, or invert [and name] negative conditions as a positive.

if (condition)
    return;

DoSomething();

I have found that by drastically reducing the usage of else my code is more readable and maintainable and when I do have to use else its almost always an excellent candidate for a more structured switch statement.

Answer 4

I know this isn't exactly what you're looking for, but ... A lot of developers use a "guard clause", that is, a negative "if" statement that breaks out of the method as soon as possible. At that point, there is no "else" really.

Example:

if (blah == false)
{
    return; // perhaps with a message
}

// do rest of code here...

There are some hard-core c/c++/assembly guys out there that will tell you that you're destroying your CPU!!! (in many cases, processors favor the "true" statement and try to "prefetch" the next thing to do... so theoretically any "false" condition will flush the pipe and will go microseconds slower).

In my opinion, we are at the point where "better" (more understandable) code wins out over microseconds of CPU time.

Answer 5

First of all, let's put aside situations when it is better to avoid using "else" in the first place (I hope everyone agrees that such situations do exist and determining such cases probably should be a separate topic).

So, let's assume that there must be an "else" clause.

I think that readability/comprehensibility imposes at least three key requirements or rules, which unfortunately often compete with each other:

1. The shorter is the first block (the "if" block) the easier is it to grasp the entire "if-else" construct. When the "if" block is long enough, it becomes way too easy to overlook existence of "else" block.

2. When the "if" and "else" paths are logically asymmetric (e.g. "normal processing" vs. "error processing"), in a standalone "if-else" construct it does not really matter much which path is first and which is second. However, when there are multiple "if-else" constructs in proximity to each other (including nesting), and when all those "if-else" constructs have asymmetry of the same kind - that's when it is very important to arrange those asymmetric paths consistently.

   Again, it can be "if ... normal path ... else ... abnormal path" for all, or "if ... abnormal path ... else ... normal path" for all, but it should not be a mix of these two variants.

   With all other conditions equal, putting the normal path first is probably more natural for most human beings (I think it's more about psychology than aesthetics :-).

3. An expression that starts with a negation usually is less readable/comprehensible than an expression that doesn't.

So, we have these three competing requirements/rules, and the real question is: which of them are more important than others. For Allen Holub the rule #1 is probably the most important one. For Steve McConnell - it is the rule #2. But I don't think that you can really choose only one of these rules as a single quideline.

I bet you've already guessed my personal priorities here (from the way I ordered the rules above :-).

My reasons are simple:

• The rule #1 is unconditional and impossible to circumvent. If one of the blocks is so long that it runs off the screen - it must become the "else" block. (No, it is not a good idea to create a function/method mechanically just to decrease the number of lines in an "if" or "else" block! I am assuming that each block already has a logically justifiable minimum amount of lines.)

• The rule #2 involves a lot of conditions: multiple "if-else" constructs, all having asymmetry of the same kind, etc. So it just does not apply in many cases.

  Also, I often observe the following interesting phenomenon: when the rule #2 does apply and when it is used properly, it actually does not conflict with the rule #1! For example, whenever I have a bunch of "if-else" statements with "normal vs. abnormal" asymmetry, all the "abnormal" paths are shorter than "normal" ones (or vice versa). I cannot explain this phenomenon, but I think that it's just a sign of good code organization. In other words, whenever I see a situation when rules #1 and #2 are in conflict, I start looking for "code smells" and more often than not I do find some; and after refactoring - tada! no more painful choosing between rule #1 and rule #2, :-)

• Finally, the rule #3 hase the smallest scope and therefore is the least critical.

  Also, as mentined here by other colleagues, it is often very easy to "cheat" with this rule (for example, to write "if(disabled),,," instead of "if(!enabled)...").

I hope someone can make some sense of this opus...

Answer 6

As a general rule, if one is significantly larger than the other, I make the larger one the if block.