Comment On A Truly Selective Case

Anonymous:

For those of us that aren't VB programmers, can someone explain what exactly Select Case True means?

That means it will hit the Case line that evaluates to True.

Now, to be completely fair, Select Case True is currently necessary in VB.NET to do Type evaluation in a Select Case construct:

Select Case True

   Case TypeOf MyObject Is MyType

   Etc..

End Select

Clearly, of course, one could use If/Then/ElseIf..

Anonymous:

For those of us that aren't VB programmers, can someone explain what exactly Select Case True means?

Anonymous:

I am guessing that in VB the 'break' is implicit?

You are correct.

Charles Nadolski:

Forgive my noobishness, but isn't use of
a COM object a WTF in and of itself?  Something that is to be
avoided if possible?

loneprogrammer:

What exactly is the complaint about this code?  "It looks strange" is a weak reason.

Switch statements are equivalent to if/elseif/elseif/.../else.  Some languages (like Perl) do not have switch statements at all.

The CPU treats everything like a goto in the end, but nobody would argue that everything should be done with only gotos.  So why should all switch statements be done with only if/else statements?

I can't really comment on whether this is a WTF because all VB code looks like a WTF to me. [;)]

But switch case is not equivalent to if-else in all languages even though it can generally be replaced by them.  Switch case statements are generally used in Java because they are 'faster' than chained if-else (at least theoretically.)

loneprogrammer:

What exactly is the complaint about this code?  "It looks strange" is a weak reason.

Switch statements are equivalent to if/elseif/elseif/.../else.  Some languages (like Perl) do not have switch statements at all.

The CPU treats everything like a goto in the end, but nobody would argue that everything should be done with only gotos.  So why should all switch statements be done with only if/else statements?

We're not saying all switch statements should be done with If/Else statements.  But Select Case True or switch(true) robs the switch case statement of any space-saving benefit it would have while making the code more confusing to read.

Anonymous software guy has it pretty well.

Select Case False

  Case Request.username = UserObj.username

    error("Invalid username")

  Case Request.password = UserObj.password

    error("Invalid password")

  Case 1 + 1 = 2

    error("Luckily, this will never happen")

End Select

loneprogrammer:

What exactly is the complaint about this code?  "It looks strange" is a weak reason.

Switch statements are equivalent to if/elseif/elseif/.../else.  Some languages (like Perl) do not have switch statements at all.

The CPU treats everything like a goto in the end, but nobody would argue that everything should be done with only gotos.  So why should all switch statements be done with only if/else statements?

For one, it was totally unecessary to even use "select case true" in this example, as software guy pointed out. That would be my complaint about this code, exactly. Plus, doing something that looks strange, whilst there is a perfectly well accepted non-strange-looking way of doing the (in effect) the same thing, it's a bad idea, because it effects readability for one, and can put silly notions in to the less informed mind (like a fresh junior dev or something).

"Keep it simple, keep it safe" my grand-daddy's lesbo mothers friend use to say.

loneprogrammer:

What exactly is the complaint about this code?  "It looks strange" is a weak reason.

Switch statements are equivalent to if/elseif/elseif/.../else.  Some languages (like Perl) do not have switch statements at all.

The CPU treats everything like a goto in the end, but nobody would argue that everything should be done with only gotos.  So why should all switch statements be done with only if/else statements?

I agree - the code does look strange, and anonymous software guy shows the way the select/case should be coded, and the unsafe error messages that are displayed are not good either - but code itself isn't much of a WTF.

Now, the clearing out of strings, that's a different story....

loneprogrammer:

Switch statements are equivalent to if/elseif/elseif/.../else. 
Some languages (like Perl) do not have switch statements at all.

skicow:

Now, the clearing out of strings, that's a different story....

It's amazing how often I see this type of thing in our contractors' code.  Initializing things before they are initialized.

This is really annoying when it's a local variable because the compiler will tell you if there is a path that doesn't ensure initialization and doing this defeats that feature.

select case Value
   case Condition1
   case Condition2
   case else
end select

but I have used select case True in the past.  I evaluate code
on efficiency & readabily (in that order). If two methods yield the
same result with the same performance, I'll favor the more readable
code.

So, in this instance:

If TypeOf ctl Is ListBox Or TypeOf ctl Is ComboBox Then
    ' do something
ElseIf TypeOf ctl Is TextBox Then
    ' do something else
ElseIf TypeOf ctl is CheckBox Then
    ' do something else
Else
    ' raise err
End If

Select Case True
    Case TypeOf ctl Is ListBox, TypeOf ctl Is ComboBox
	' do something
    Case TypeOf ctl Is TextBox
        ' do something else
    Case TypeOf ctl is CheckBox
        ' do something else
    Case Else
        ' raise error
End Select

I find the select case slightly more readable (IMO). 

loneprogrammer:

I think the time on the web server is off.  The timestamps on the posts look wrong.

Looks like GMT (or the DST version maybe) to me.

Anonymous:

I've been told by a couple people that switch(true) is actually a *more efficient* method of handling some types of multiple exclusive tests than with if/elseif/elseif/elseif/elseif/ese.  I don't recall the explanation exactly; something about the structuring of switch/select "tables" as seen by the compiler/parser being a more efficient way for the compiler/parser to jump to the correct peice of code. 

So to me the Select Case True is not such a strange thing to see.. BUT in this code, that doesn't stand up.. What really is WTF about this is that they did not "Select Case objLoginValidation.error" since that is the *only* variable they are comparing.  In this case, a Select Case True is not properly used for the optimization I heard of, if it exists.

Then to be even weirder, they provide "Case Else" for "Select Case True".  It's like putting random checks in your code saying

If(true == false) { Error('OMGWTF Somethings wrong!'); }

If I'm not mistaken, "Case Else DoBlah" on a "Select Case True" doesn't mean, "in the case that True is not True, DoBlah" but rather, "in the case that none of the above conditions evaluated to True, DoBlah."

As for at the second part of the WTF:  When I was in college taking computer science courses one of my professors told us about a bajillion times each semester to always, always, initialize our variables explicitly.  Now, even though I'm out of college and I know that that isn't always necessary, I still find myself doing

Dim Blah as Integer

Dim Meh as String

Blah = 0

Meh = ""

every now and then.

Anonymous:

I've been told by a couple people that switch(true) is actually a *more efficient* method of handling some types of multiple exclusive tests than with if/elseif/elseif/elseif/elseif/ese.  I don't recall the explanation exactly; something about the structuring of switch/select "tables" as seen by the compiler/parser being a more efficient way for the compiler/parser to jump to the correct peice of code. 

So to me the Select Case True is not such a strange thing to see.. BUT in this code, that doesn't stand up.. What really is WTF about this is that they did not "Select Case objLoginValidation.error" since that is the *only* variable they are comparing.  In this case, a Select Case True is not properly used for the optimization I heard of, if it exists.

The optimization of switch case is that if you take an integral type and switch on it, the compiler can build a 'jump table' that allows if you jump directly to the correct instruction without check the preceeding cases.  Like if you are testing 1, 2, 3 and 4 and you pass in 4, it can jump ahead 4x memory slots to the corresponding instruction (this is a very oversimplified explanation) instead of check 1, 2, and 3.

By the very nature of the select case statement, it cannot have this optimization.  It is, as far as I can tell, purely syntactical sugar.

we only use the best security practices!

{

    Object a, b, c;

    //... some code

    a = someThing;

    b = someThingelse;

    c = someOtherThing;

    //... some code



    a = null;

    b = null;

    c = null;

    return;

}

I'm surprised there are some defenders of the Select Case code. Actually that's a lie, I'm never surprised. I see some of the strangest code defended on a regular basis.

Does the code compile? Sure. Will it work? Yep. Does it look weird? That's an opinion issue. Is this how "Select Case" was intended to be used? Absolutely not.

It's that last part that makes this a WTF. If/Else If/Else and Select Case are both selection structures, so you may be able to swap them out in just about any situation. The point is that If/Else If/Else was intended for making comparisons on different sets of circumstances or groups of data, and Select Case was intended for a limited set of options for a single data value.

'An If statement works better for this kind of criteria

If MyAge > 60 Then
ElseIf MyAge <=60 And GotAgoldWatch = True Then

'Use selection struction for limited, predefined possibilities

Select Case CurrentDayOfTheWeek

You could always use a For or Do loop to add two numbers together (loop through, incrementing your variable as many times as the number you want to add to it), but why would you do that when you can just make that plus sign do what it was intended to do? Just because it isn't broken doesn't make it OK.

loneprogrammer:

Some languages (like Perl) do not have switch statements at all.

Obviously in this particular case, Select Case objLoginValidation.error should have been used.

Nonetheless, Select Case True can be a useful feature in VB 6. It allows lazy evaluation.

If x = 1 OR y = 2 OR z = 3 Then

will evaluate all three conditions in VB 6.

Select Case True

   Case x = 1, y = 2, z = 3

will lazy evaluate (so if x = 1 then y and z won't be checked). Note that the comma is essentially equivalent to OR.

I have never seen that documented anywhere, but sure enough it's true. VB is known for not having short-circuiting, but I'll be damned if it works in the Select Case situation.

Anonymous:

Obviously in this particular case, Select Case objLoginValidation.error should have been used.

Nonetheless, Select Case True can be a useful feature in VB 6. It allows lazy evaluation.

If x = 1 OR y = 2 OR z = 3 Then

will evaluate all three conditions in VB 6.

Select Case True

   Case x = 1, y = 2, z = 3

will lazy evaluate (so if x = 1 then y and z won't be checked). Note that the comma is essentially equivalent to OR.

OOo, I didn't know that. That's a pretty cool trick--short circuit evaluating in VB6.

I sometimes use Select Case even when there is only one real 'case' I am interested in. Like when I have to check for a range or set of values. Instead of

If medCode = 320 OR medCode = 331 OR (medCode => 412 AND medCode <= 420) OR medCode = 499 Then
   'Do stuff
Else
   'Do something else
End if

I can do:

Select Case medCode
Case 320, 331, 412 to 420, 499
   'Do something
Case Else
  'Do something else
End Select

This is especially helpful if there are 30+ valid values to check.

I wish I could just use the SQL "IN" syntax:
medCode in (320, 331, 499)

BradC:

I wish I could just use the SQL "IN" syntax:
medCode in (320, 331, 499)

UncleMidriff:

As for at the second part of the WTF:  When I was in college
taking computer science courses one of my professors told us about a
bajillion times each semester to always, always, initialize our variables explicitly.

loneprogrammer:

What exactly is the complaint about this code?  "It looks strange" is a weak reason.



Switch statements are equivalent to if/elseif/elseif/.../else. 
Some languages (like Perl) do not have switch statements at all.



The CPU treats everything like a goto in the end, but nobody would
argue that everything should be done with only gotos.  So why
should all switch statements be done with only if/else statements?

"I have never seen that documented anywhere, but sure enough it's true. VB is known for not having short-circuiting, but I'll be damned if it works in the Select Case situation."

I believe Code Complete makes mention that changing if-then-elses to switches speeds up VB code. Where as it drastically slows Java code. If I manage to be able to leave work tonight, I can dig up the benchmarks they provide otherwise I'll leave that as an excercise for the reader.

Case objLoginValidation.error =

the enum intellisense pops up.  If you coded it the "correct" way:

Select case  objLoginValidation.Error

    case LockedAccount

    case InvalidLastName

    ...

you would get no Intellisense whatsoever.

Anonymous:

Calm down.  I agree that to a non-VB6 guy this looks weird.  But there is a perfectly valid reason for using type of select statement -- You get INTELLISENSE.

Anonymous:

Gentlemen,

Calm down.  I agree that to a non-VB6 guy this looks weird.  But there is a perfectly valid reason for using type of select statement -- You get INTELLISENSE.

The moment you type in 

Case objLoginValidation.error =

the enum intellisense pops up.  If you coded it the "correct" way:
Select case  objLoginValidation.Error
    case LockedAccount
    case InvalidLastName
    ...

you would get no Intellisense whatsoever.

You would actually get intellisense... in VB.NET

Drak

Dim strSQL
strSQL = ""
strSQL = "SELECT Column FROM TABLE1"

...

strSQL = ""
strSQL = "EXEC usp_MyStoredProc"

Anonymous:

But on a more objective note - back in the old days ....  now I
really mean long ago when I was young and Intel was still doing 4 bit
processors, memory was stil a factor in programming and tight code was cool,
switch (select case or what ever - depending on the language)
statements resulted in neat jump tables when the compiler started
spitting out machine code. Most of the time this generted more
efficient code than any  if else elseif   bla bla bla at nausium would generate. My $0.02

Select Case False
Case test1
Case test2
Case test3
Case Else
	' all predicates true
End Select

Makes a wonderful replacement for

If test1 And test2 And test3 Then
	' all predicates true
End If

UncleMidriff:

As for at the second part of the WTF:  When I was in college taking computer science courses one of my professors told us about a bajillion times each semester to always, always, initialize our variables explicitly.

I think the reason for this is that some primitive languages required that the contents of each variable be terminated with a NULL character so that the language would know when to stop reading. When assigning a value to a variable that already contained a value only the number of bytes actually supplied would be overwritten, so if the original contents were longer the surplus bytes would still remain. Thus the following two statements:

var1 = "FIVE"

var1 = "TEN"

would result in the contents of var1 being "TENE".

By setting the variable to '' (which was supposed to fill it with NULLs, not just set the first byte to NULL) you effectively erase the existing contents before inserting a new value.

Thankfully modern languages are not so stupid, but some college professors are still behind the times and insist on using outdated practices.

dubwai:

...

But switch case is not equivalent to if-else in all languages even though it can generally be replaced by them.  Switch case statements are generally used in Java because they are 'faster' than chained if-else (at least theoretically.)

WTH? Generally used in Java? I mean - if you have it, you use it, why the f*ck shouldn't I use it as frequently in C as I do in Java, or any language that has some sort of switch/select-case construct? And anyway, someone using a case statement in Java only because it's faster has no clue about performance. Java itself isn't that slow u know, the problem is that java makes it easy to write a program in an inefficient way (C# has the same problem), and the early VM's weren't really that fast, but that changed a lot since then. When you want/need optimalisations, look at the source (not literaly [:P]) of the performance problems - which is in general the main program design - not always the implementation. Case statements should be used when comparing one variable value to multiple constant values, that's what it's there for, to make such a thing clear & readable.

And this case-statement actually de-optimizes that case-statement, since the cpu has to evaluate each "case"-value also, which ends up in 2 compares. Not that you're gonna notice this (in any language that is) with the cpu's of today, and even on a 486 33mhz, you'll never notice this, certainly when it's only executed once in a login sequence... Oh no, the user should wait 0,00000001s longer - now he's gonna have a heart-attack! [*-)][:P]
The problem with this code isn't that it doesn't work, the problem is that it's unreadable, confusing and simply a bad design. Probably a coder who thought he was doing something in a smart way nobody ever thought about, or he was maybe just messing around, having fun [:P]