[RESOLVED] Who writes a Case statement like this?

Is it just me, or if you saw code like this you'd be shaking your head saying, "What the...?"

Code:

---

        Select Case (rsProductsRiders!Status)
            Case Null
                strFundingType = "S"
            Case "Y"
                strFundingType = "S"
            Case "F"
                strFundingType = "S"
            Case "W"
                strFundingType = "W"
            Case "N"
                strFundingType = "N"
            Case "M"
                strFundingType = "S"
            Case "C"
                strFundingType = "N"
            Case Else
                strFundingType = "S"
        End Select

---

Nope, it's not just you.

Here's my version.

Code:

---

Select Case (rsProductsRiders!Status)
           
            Case "W"
                strFundingType = "W"
            Case "N"
                strFundingType = "N"
            Case "C"
                strFundingType = "N"
            Case Else
                strFundingType = "S"
        End Select

---

Well, it can be considerably shortened. Since the 'Else' is "S" there's no need to test for conditions where the result would be "S". Also Cases "N" and "C" can be put together

Code:

---

        Select Case (rsProductsRiders!Status)
            Case "W"
                strFundingType = "W"
            Case "N", "C"
                strFundingType = "N"
            Case Else
                strFundingType = "S"
        End Select

---

EDIT: I see Zvoni beat me to it !

I'd much rather maintain your code, than this!

However, I think you missed one:

Code:

---

Select Case (rsProductsRiders!Status)
           
            Case "W"
                strFundingType = "W"
            Case "N", "C"
                strFundingType = "N"
            Case Else
                strFundingType = "S"
        End Select

---

EDIT: And Doogle beat me!

Quote:

---

Originally Posted by Doogle

Also Cases "N" and "C" can be put together

EDIT: I see Zvoni beat me to it !

---

I know that, but for some reason i dislike it.
I always write each case in its own line for better readability, even if it means i have duplicate code *shrug*

btw: Is there a difference in performance? Because i don't think so.....

At least it's relatively easy to read, given the structure of a Select Case and the shape of the code text but it's certainly not optimal. I don't know whether Select Case supports lists and ranges in VB6 as it does in VB.NET but, at the very least, you'd put the conditions together that produced the same result.

I'm working with a lot of legacy code, and sometimes I just get fed up with how inefficient it is.

Sometimes I wish copy and paste was never invented. If you didn't have copy and paste and had to type, you'd probably look a lot more closely for existing code that you could call instead of writing it multiple times. In two places in this application, there is the same call to the database to insert a record. When a field was added on the two forms that make the call, only one call was updated. I think they missed the idea of a function. You write the function once, and call it n-times. You don't write n functions. If that's what you're doing, all your code might as well be in-line.

Right, jmcilhinney.

But back to my function example, suppose whenever you set strFundingType to "N", you also wanted to do x, y and z. If there was only one case path that set it to "N", you'd add x, y and z there. But if there were several, then you have to make sure you get them all.

Quote:

---

Originally Posted by MMock

Right, jmcilhinney.

But back to my function example, suppose whenever you set strFundingType to "N", you also wanted to do x, y and z. If there was only one case path that set it to "N", you'd add x, y and z there. But if there were several, then you have to make sure you get them all.

---

Conversly if when you set it to "N" and if the status was "C" you wanted to do a,b and c and if the status was "N" you wanted to d,e and f then there's a good argument to separate the two. Perhaps the original coder wanted to build that flexibility in, just in case it was ever needed. (pun not intended)

I make it dependent on the complexity what should happen if a case is true.

If it's something simple like just assigning a value to a variable (like in this code-snippet), i do it the way i described (duplicate code)
If it's something more complex, i write a function, and call it inside the case(s)

Yes, i know the danger in missing the "other" line of code, when i change it say instead of strFundingType = "N" i change it to strFundingType = "X"
but i haven't had any issues with it.
..... or i just got lucky... :bigyello:

Quote:

---

Originally Posted by Doogle

Conversly if when you set it to "N" and if the status was "C" you wanted to do a,b and c and if the status was "N" you wanted to d,e and f then there's a good argument to separate the two. Perhaps the original coder wanted to build that flexibility in, just in case it was ever needed. (pun not intended)

---

Touche.

Though I believe you are giving the original programmer too much credit. Personally, I'd write it condensed then split it out as the need arose, but point taken.

Quote:

---

Originally Posted by Zvoni

..... or i just got lucky... :bigyello:

---

Or you are just conscientious and thorough!

How about even shorter?

Code:

---

strFunding = rsProductsRiders!Status
If strFundingType = "C" Then strFundingType = "N"
If strFundingType <> "W" And strFundingType <> "N" Then strFundingType = "S"

---

EDIT: Sorry for a late post...i see many posts since # 4

I don't know...I think I would spend a long time looking at that, trying to understand it. It doesn't seem as obvious.

@Sam: You may run the risk of 'Invalid use of Null' on the initial assignment if the status returned from the Table is null.

Quote:

---

Originally Posted by Doogle

@Sam: You may run the risk of 'Invalid use of Null' on the initial assignment if the status returned from the Table is null.

---

Not if he turns on the Error-Handler. Then in Case of Null strFunding would stay blank

Code:

---

On Error Resume Next
strFunding = rsProductsRiders!Status
If strFundingType = "C" Then strFundingType = "N"
If strFundingType <> "W" And strFundingType <> "N" Then strFundingType = "S"
On Error Goto 0

---

Don't know MMOCK...seemed fairly logical to me...
set the variable
if it is "C" make it "N"
if it is not "W" and not "N" then it is "S"
:-)

Sure, it's just subjective to one's way of understanding. I might want what you said as a comment to the if-statement, which the Case statement doesn't need because it already has that spelled out.

Makes sense.....

Quote:

---

Originally Posted by Zvoni

Not if he turns on the Error-Handler. Then in Case of Null strFunding would stay blank

Code:

---

On Error Resume Next
strFunding = rsProductsRiders!Status
If strFundingType = "C" Then strFundingType = "N"
If strFundingType <> "W" And strFundingType <> "N" Then strFundingType = "S"
On Error Goto 0

---

---

Bleh... now that means for each new combination added you have to do twice the work, first to add it as it's own logic, then again in the exception logic....

does no one use ElseIf any more? if I've satisfied the first condition, it should stop... no sense in doing any further checking...

-tg

Quote:

---

Originally Posted by SamOscarBrown

How about even shorter?

Code:

---

strFunding = rsProductsRiders!Status
If strFundingType = "C" Then strFundingType = "N"
If strFundingType <> "W" And strFundingType <> "N" Then strFundingType = "S"

---

EDIT: Sorry for a late post...i see many posts since # 4

---

what happens if "N" is a valid value for rsProductsRiders!Status, for which the strFundingType needs to be "Z"....


-tg

I totally agree with you about elseif! I've closed the project, but I could easily pull out many places where it's not but should be.

It's been a *long* time since I earned my degree, but some things stuck, such as what you said...

Quote:

---

Originally Posted by techgnome

Bleh... now that means for each new combination added you have to do twice the work, first to add it as it's own logic, then again in the exception logic....

does no one use ElseIf any more? if I've satisfied the first condition, it should stop... no sense in doing any further checking...

-tg

---

tg, i just wanted to point out the solution to doogle's objection, but as you can see from my own post/code-sample i'd also still choose the select case.
and you're right: elseif would be the right method in sam's case

tg---Wow...that is one of my problems (i got many)...listening to you experts in VB, sometimes I just don't get it....for example, 'Z'? where'd that come from? Not being sarcastic, just trying to understand why an elseif, especially given the orig post. After this, I'll stop posting to this thread. :-)

Sam, if strFundingType is "C" there is no sense in checking if it's not "W" or "N", therefore ElseIf, but i have to admit i didn't understand tg's reference "Z" :-)

EDIT: there is a mistake in sam's code.
in his first line he uses strFunding, in the If-clauses he uses strFundingType......

the "Z" came from a hypothetical change 6 months from now when someone else has to go into the code to change it....

if the code looks like this and I'm paying careful attention, the logic can get screwed up....

Code:

---

On Error Resume Next
strFunding = rsProductsRiders!Status
If strFundingType = "C" Then strFundingType = "N"
If strFundingType <> "W" And strFundingType <> "N" Then strFundingType = "S"
On Error Goto 0

---

Code:

---

On Error Resume Next
strFunding = rsProductsRiders!Status
If strFundingType = "C" Then strFundingType = "N"
'CO 9948: Added to change Status "N" to Type "Z"
if strFundingType = "N" then strFundingType = "Z"
If strFundingType = "C" Then strFundingType = "N"
If strFundingType <> "W" And strFundingType <> "N" Then strFundingType = "S"
On Error Goto 0

---

So now, if the status is "C"... is sets the funding type to "N" but on the very next line we chack for a status "N" and set the funding type to "Z"! so now, we're effective mapped Status "C" AND "N" to "Z"

That completely changes the logic and now it's wrong... plus also, rsProductsRiders!Status isn't the fundingType, so I have moral issues setting it to that in the first place... but hey... what ever...

-tg

Quote:

---

Originally Posted by techgnome

if the code looks like this and I'm paying careful attention, the logic can get screwed up....

---

Did you mean not paying careful attention?

thx Z...ah....got the elseif (and yes, I do use it on occasion)....but in this case, I'd have to go back and see if appropriate....but, I understand...thanks

Good catch on strFunding vice ....strFundingtype! argh!

ok ok ok.....Case Statement it is! :-)
Adios

(Frenzied Member---that's me!)

Tg, thanks! Now i've understood your reference to "Z".
which brings us back to the select case from the original post where something like you described cannot happen if you insert a "new" case

Wow - I see this thread is resolved already - but I just have to put my two cents in.

The syntax in the OP is clear. And more important very, very easy to maintain and enhance. It's the "enhancing" part that's key here - if the list in intended to be added to - or altered - then the single case / value list is optimal in that regard.

And didn't that just get proved by the 30 posts about other ways to do it what were simply not clear - or buggy - or hard to even tell?

3rd cent...

Coming from a SQL background I am a big proponent of CASE ELSE - otherwise CASE statements in sql are "non-deterministic" and can return a NULL value...