Coding Horror: The Tyranny of ElseIf

Jun 20, 2004

The Tyranny of ElseIf

I don't understand it. I've seen this phenomenon over and over in VB.NET, in code from experienced programmers:

        If dt.DayOfWeek = DayOfWeek.Sunday Then
            Return dt
        ElseIf dt.DayOfWeek = DayOfWeek.Monday Then
            Return dt.AddDays(6)
        ElseIf dt.DayOfWeek = DayOfWeek.Tuesday Then
            Return dt.AddDays(5)
        ElseIf dt.DayOfWeek = DayOfWeek.Wednesday Then
            Return dt.AddDays(4)
        ElseIf dt.DayOfWeek = DayOfWeek.Thursday Then
            Return dt.AddDays(3)
        ElseIf dt.DayOfWeek = DayOfWeek.Friday Then
            Return dt.AddDays(2)
        ElseIf dt.DayOfWeek = DayOfWeek.Saturday Then
            Return dt.AddDays(1)
        End If

Why in the world would you express logic this way, instead of the much simpler SELECT CASE statement?

        Select Case dt.DayOfWeek
            Case DayOfWeek.Sunday
                Return dt
            Case DayOfWeek.Monday
                Return dt.AddDays(6)
            Case DayOfWeek.Tuesday
                Return dt.AddDays(5)
            Case DayOfWeek.Wednesday
                Return dt.AddDays(4)
            Case DayOfWeek.Thursday
                Return dt.AddDays(3)
            Case DayOfWeek.Friday
                Return dt.AddDays(2)
            Case DayOfWeek.Saturday
                Return dt.AddDays(1)
        End Select

I mention this because I see it constantly from many different programmers. What gives?

I think the ELSEIF keyword is destructive and, like GOTO, has no good use outside of a very specialized niche. ELSEIF, in my experience, is abused far more than it is used properly. Here's another example from a project I work on:

        If result = DialogResult.Retry Then
            strProjectName = .ProjDetailsPnl.PnlGenInfo.TxtProjectName.Text
        ElseIf result = DialogResult.OK Then
            intNewProjectID = .ProjectID
        End If

I have a very hard time coming up with any valid justification for the use of ELSEIF. 98 times out of 100, SELECT CASE is easier to read and offers the CASE ELSE condition, which encourages developers to handle unknown conditions properly. In the above example, what happens when the dialog returns DialogResult.Cancel?

Posted by Jeff Atwood View blog reactions

« Multiple Monitors and Productivity

User-Friendly Exception Handling »

Comments

I agree. And from my experience, VB seems to encourage deviant logic flow. I've run across

If Not Foo Then
Else
Console.WriteLine("Baz")
End If

as well as things like

If Foo IsNot Nothing Then
If Foo.Length 6 Then
Console.WriteLine("Foo must be at least six digits!")
End If
End If

I assume the second case is due to non-shortcircuiting boolean operator evaluation (OrElse/AndAlso don't seem to be very popular), but I have no idea what could have brought about the first. Really sloppy refactoring, perhaps?

DeafByBeheading on February 2, 2007 2:23 AM

Okay, but the code is just going to the next Sunday if today is not already Sunday. Given that, why would you use if-then-else *or* select-case? You can use a simple aritmetic operation: addition.

return dt.AddDays((7 - (int) x.Date.DayOfWeek) % 7)

Yeah, it relies on Sunday having value 0. We can change that for other values of Sunday.

Hugh Brown on April 13, 2007 3:15 AM

Im no .net programmer but I have to agree. My primary language is PHP and I see it all to often. especaily the

If Foo IsNot Nothing Then
If Foo.Length 6 Then
Console.WriteLine("Foo must be at least six digits!")
End If
End If

when it is much simpler to express it as

if(count($foo) '6')
{
echo "Foo must be at least six digits!";
}

at least in PHP.

Arron on November 23, 2007 6:40 AM

I was just thinking about which one to use today when I remembered I needed _ranges_, i.e.:

if (x 100) ...
else if (x 200) ...
else ...

That, and the really short (2-3 cases, perhaps even 4) are the only times when using a strand of if's can be justified. (And when switch...case is broken like with AS3.0's XML objects)

Another evilness of the elseif keyword is that it makes it harder to realize that 'if...elseif...elseif' constructs are equivalent to a set of nested if's, i.e. 'if...else if...else if'.

aib on December 11, 2007 8:55 AM

Don't forget as well that "select case" is easier for the compiler to refactor into jumps based on a fast to calculate value, rather than forcing a load of comparisons like if statements might. This leads to faster code in some cases... of course a large enough select/case will become ifs and elseifs anyway once the compiler has it in its hands, but there is a middle ground too...

Short story, select/case is good for your compiler, if/elseif is not.

Jheriko on January 7, 2008 8:41 AM

Or you can make it look even prettier using the old school colon.

Select Case dt.DayOfWeek
Case DayOfWeek.Sunday: Return dt
Case DayOfWeek.Monday: Return dt.AddDays(6)
Case DayOfWeek.Tuesday: Return dt.AddDays(5)
Case DayOfWeek.Wednesday: Return dt.AddDays(4)
Case DayOfWeek.Thursday: Return dt.AddDays(3)
Case DayOfWeek.Friday: Return dt.AddDays(2)
Case DayOfWeek.Saturday: Return dt.AddDays(1)
End Select

That ElseIf is bad, but I've seen worse! I inherited some code that was like this:

If dt.DayOfWeek = DayOfWeek.Sunday Then
Return dt
Else
If dt.DayOfWeek = DayOfWeek.Monday Then
Return dt.AddDays(6)
Else
If dt.DayOfWeek = DayOfWeek.Tuesday Then
Return dt.AddDays(5)
Else
If dt.DayOfWeek = DayOfWeek.Wednesday Then
Return dt.AddDays(4)
Else
If dt.DayOfWeek = DayOfWeek.Thursday Then
Return dt.AddDays(3)
Else
If dt.DayOfWeek = DayOfWeek.Friday Then
Return dt.AddDays(2)
Else
If dt.DayOfWeek = DayOfWeek.Saturday Then
Return dt.AddDays(1)
End If
End If
End If
End If
End If
End If
End If

Dave on June 24, 2008 8:56 AM

I must admit, I have used

If Not Foo Then
Else
do something
End If

When working with Boolean values(null, 0, 1)

if not x then will only execute for 0
do something

if x then
else
do something will execute for 0 and null

I realize that i could just AND/OR for the null condition, but four letters seems simpler. I have no problem glancing at that statement and knowing what it is doing....but then again, i work with databases, and am all the time branching on null/0/1 conditions.

Duke on December 5, 2008 2:06 AM

I have used the
if (not condition) then
expression
else
expression
in a few cases, actually in a lot of cases. This was in cases when it seemed logical to follow the THEN branch in most cases and the ELSE was only for a few exceptions. It makes perfect sense when it's easier to evaluate something as being wrong than being right (if you you have only conditions that tell you a value is wrong, instead of having conditions that tell you it's right; for example, a basic word filter). So if the value is NOT WRONG (like DOH, IT'S RIGHT), you do what your normally do. If you have an exception from that rule, you treat it in the ELSE branch.
Saying that you should NEVER EVER USE IF NOT X THEN .. ELSE .. constructs is just plain stupid, because code redesign just to fit the IF X .. ELSE .. pattern might add some complexity to the code.

There are a few cases where it makes more sense to do it this way.

Tom on December 16, 2008 3:35 AM

Oskar on February 7, 2009 1:44 AM

Well understood.
thanks for the blogger
http://winguard.blogspot.com - Winguard
http://dexzone.blogspot.com - Dexzone

winguard on March 2, 2009 6:32 AM

Don't forget as well that select case is easier for the compiler to refactor into jumps based on a fast to calculate value, rather than forcing a load of comparisons like if statements might. This leads to faster code in some cases... of course a large enough select/case will become ifs and elseifs anyway once the compiler has it in its hands, but there is a middle ground too...
http://tour-elite.ru

Hvostokril on May 13, 2009 2:08 AM

Did you guys know that the code:

If Foo IsNot Nothing Then
If Foo.Length 6 Then
Console.WriteLine("Foo must be at least six digits!")
End If
End If

is necessary because you can't test the length of a null object? If you try, you'll get an exception, so first you test that object reference is not null (or nothing in VB).

As far as the original if ... elseif is concerned, it can be a common structure in C. The switch statement in C only accepts a literal value, so you can't test strings ( strcmp(var, "dafdf") == 0 ) in a switch statement and you have to resort to if ... elseif. In C its not so bad as long as the whole structure is laid out cleanly.

I'm guessing that some programmers have stepped out of the C world into VB and taken some of the C habits with them!

Either that or they are not aware the select case even exists, because they are expecting to use the "switch" or "case" keywords - the keywords "Select Case" are unsual and particular to VB.

Mat on June 9, 2009 3:46 AM

Wow, commenting on a 6-year old post?

Sure, why not.

In many programming languages switch is limited to 256 options - at least it was when I was working in VS98.

Also, many times people use String.Compare's when they should use Enums and that lends itself to an elseif format.

-S!

Stephen Furlani on June 17, 2010 12:06 PM

The comments to this entry are closed.