Select Case vs. ElseIf

[Lauren Quantrell]

Is there any speed/resource advantage/disadvantage in using

Select Case x
Case 1
Case 2
etc. many more cases...
End Select

VS.

If x Then
ElseIf x+1 Then
ElseIf x+2 Then
etc. many more ElseIfs...
End If

[John Mishefske]

Lauren Quantrell wrote:

Is there any speed/resource advantage/disadvantage in using

Select Case x
Case 1
Case 2
etc. many more cases...
End Select

VS.

If x Then
ElseIf x+1 Then
ElseIf x+2 Then
etc. many more ElseIfs...
End If

Now adays I suspect not. Its more a question of readability so I vote for a properly
tabbed Select Case...

--
'---------------
'John Mishefske
'---------------

[Lauren Quantrell]

I tend to have a lot of

SELECT CASE x
CASE x1

SELECT CASE y
CASE y1
CASE y2
END SELECT

CASE x2
etc.
END SELECT

[John Mishefske]

Lauren Quantrell wrote:

I tend to have a lot of

SELECT CASE x
CASE x1

SELECT CASE y
CASE y1
CASE y2
END SELECT

CASE x2
etc.
END SELECT

If you have Case statement within your Case statements then it would be more readable to
use a function/sub (IMO) to prevent the logic from getting too hard to follow:

SELECT CASE x
CASE x1
getSomeValueOrDoSomeThing
CASE x2
etc.
END SELECT
....
Private Sub getSomeValueOrDoSomeThing()
....
End Sub

btw..indentation is a personal preference but be consistent in your implementation.
--
'---------------
'John Mishefske
'---------------

[Bruce Rusk]

There's one case in which (AFAIK) it makes a difference: if you're selecting
based on something calculated or read from an object, rather than a
variable. With IF you'd need to calculate it each time, or put it into a
variable, with Select you don't. In that case If would slow your process
down (more or less depending on the complexity of your calculation) or
create more variables.

I have a lot of these:

Select Case Len(TestString)

Case Is = 1

Case Is = 2

Case Is => 3

End Select

It's a lot cleaner with Select.

"Lauren Quantrell" <la*************@hotmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Is there any speed/resource advantage/disadvantage in using

Select Case x
Case 1
Case 2
etc. many more cases...
End Select

VS.

If x Then
ElseIf x+1 Then
ElseIf x+2 Then
etc. many more ElseIfs...
End If

[Steve Jorgensen]

On Wed, 19 Oct 2005 04:27:06 GMT, John Mishefske <jm**********@SPAMyahoo.com>
wrote:

Lauren Quantrell wrote:

I tend to have a lot of

SELECT CASE x
CASE x1

SELECT CASE y
CASE y1
CASE y2
END SELECT

CASE x2
etc.
END SELECT

If you have Case statement within your Case statements then it would be more readable to
use a function/sub (IMO) to prevent the logic from getting too hard to follow:

SELECT CASE x
CASE x1
getSomeValueOrDoSomeThing
CASE x2
etc.
END SELECT
...
Private Sub getSomeValueOrDoSomeThing()
....
End Sub

btw..indentation is a personal preference but be consistent in your implementation.

Just to add another opinion on the Select Case indentation style...

I use one of 2 styles for a case statement. If the statements are short
enough to fit on the same lines with the cases using a colon separator, then I
indent the Case lines. otherwise, I don't indent the case lines. Having 3
levels of indentation for a single branch structure, just seems to be hard to
read for no good reason, to me.

SELECT CASE x
CASE x1: getSomeValueOrDoSomeThing
CASE x2: etc.
END SELECT

Or

SELECT CASE x
CASE x1
getSomeValueOrDoSomeThing
CASE x2
etc.
END SELECT

In either case, the lines with the code that perform the actions are indented,
and lines that are -only- part of the branch logic are not. This is coherent
with the standard indentation for If/Then/Else.

[Steve Jorgensen]

On 18 Oct 2005 21:06:02 -0700, "Lauren Quantrell"
<la*************@hotmail.com> wrote:

I tend to have a lot of

SELECT CASE x
CASE x1

SELECT CASE y
CASE y1
CASE y2
END SELECT

CASE x2
etc.
END SELECT

There's usually a way to unstack these, and greatly improve reuse and
mainainability in the process. Try to set it up so that the X cases write
parial results to variables, then a separate block for Y finishes the job.

For instance, If you start with something like this...

Select case X
Case -1
Select Case Y
Case -1: Cell = "Top Left"
Case 0: Cell = "Left"
Case 1: Cell = "Bottom Left"
End Select
Case 0
Select Case Y
Case -1: Cell = "Top"
Case 0: Cell = "Center"
Case 1: Cell = "Bottom"
End Select
Case 1
Select Case Y
Case -1: Cell = "Top"
Case 0: Cell = "Center"
Case 1: Cell = "Bottom"
End Select
End Select

.... you can rewrite it like this...

Select case X
Case -1: XText = "Left"
Case 1: XText = "Right"
End Select

Select case Y
Case -1: YText = "Top"
Case 1: YText = "Bottom"
End Select

Cell = XText & " " & YText
If Cell = " " Then Cell = "Center"

[David W. Fenton]

"Lauren Quantrell" <la*************@hotmail.com> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

Is there any speed/resource advantage/disadvantage in using

Select Case x
Case 1
Case 2
etc. many more cases...
End Select

VS.

If x Then
ElseIf x+1 Then
ElseIf x+2 Then
etc. many more ElseIfs...
End If

Others have given you good answers, and to your specific question
about the nesting of multiple levels of CASE SELECT.

There's another issue:

Sometimes a CASE SELECT is *not* equvalent.

If/Then/Else is processed in sequence, and each control line (the
If/Then, the ElseIf/Then and the Else lines) is processed
independently. That means you have 2 or more tests that you can run,
and they don't have have to be run on the same expression.

CASE SELECT operates on a single expression, usually testing a
single value.

CASE SELECT can do more than testing equality, though:

CASE SELECT lngVariable
CASE <0
[do whatever]
CASE 0
[do whatever]
CASE >0
[do whatever]
END SELECT

I see no reason why that is superior to (I'll explain the odd logic
later):

If lngVariable < 0 THen
[do whatever]
Else lngVariable = 0 Then
[do whatever]
Else
[do whatever]
End If

Now, I don't remember the details on this, but I believe CASE SELECT
tests in order, down the list, so you're going to test 3 values for
numbers >0, 2 for 0 and 1 for <0. With the If/Then there's only a
maximum of 2 comparisons, as the last two possibilities are handled
by a match or a non-match.

You could do the same with:

CASE SELECT lngVariable
CASE <0
[do whatever]
CASE 0
[do whatever]
CASE ELSE
[do whatever]
END SELECT

Of course, the natural order for a CASE SELECT is ordered for
numbers or alphabitical for strings (makes it easier to read),
though you may choose to use a different order if you have a
non-random distribution of values.

In any event, testing for equality with 0 is probably going to
happen less often than <> 0, so I'd leave that as the last ELSE in
either structure. So, that would give you:

CASE SELECT lngVariable
CASE <0
[do whatever]
CASE >0
[do whatever]
CASE ELSE
[do whatever]
END SELECT

And:

If lngVariable < 0 THen
[do whatever]
Else lngVariable > 0 Then
[do whatever]
Else
[do whatever]
End If

Now, that's one set of issues.

THe other is that you may be doing a Boolean test on more than one
expression. In that case, CASE ELSE becomes complicated. Your
nesting example is exactly that. It could have been expressed as a
Boolean expression of ((x = 1) and (y = 1)), though your particular
example doesn't need to be expressed that way.

The point is that you may have non-symmetrical tests. You may do
some completely different branch of code for the NOT case of such a
set of tests. In that case, If/Then/Else is probably better, or a
mix of it with CASE/SELECT at the lower level.

So, balanced trees can use either structure, with CASE SELECT being
better, while unbalanced trees often are better suited to
If/Then/Else.

Hope that nakes sense!

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc