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?