'Do Case' - good example to share ???

[Phil Hepburn]

Hi Karl, Wolfgang, all,

Does anyone have a good example (or two) of a CASE statement in X# ?

I don't seem to be able to put my hands on any here in Newport. I have SWITCH okay but not 'Do Case'.

Please attach the code so I can copy and run it before including it in the 'ClickStartXSharp' eNotes.

TIA,
Phil.
Wales, UK.

[Frank Maraite]

Phil,

SWITCH is checking against constanst, DO CASE checks anything.

Code: Select all

Local test as STRING
Local age as int
local Name as STRING
... // something stored in test

SWITCH Test
CASE "a" // "a" is a constant
...
CASE "b"
...
OTHERWISE // I have always OTHERWISE, so it's clear there is a hidden path
   NOP    // In this example nothing to do
END SWITCH

DO CASE
CASE age < 50
...
CASE age > 60
...
CASE Name == "Phil"
...
OTHERWISE
   NOP
ENDCASE

I've read that C# will now allow other than const in SWITCH cases. Don't know if X# follow this.

HTH
Frank

[Phil Hepburn]

Thanks a lot Frank,

I will look into this and change my eNotes accordingly.

I will use your sample in my notes if that is OK.

Cheers,
Phil.

[Phil Hepburn]

Frank,

Roberts notes would suggest so - as he calls the SWITCH statement a 'replacement for the DO CASE statement.

Also my own code handles an Enum as seen below :-

FrankDoCase_01.jpg (89.94 KiB) Viewed 338 times

Cheers,
Phil.

[FFF]

Phil,
not sure if i grokked all, but IMHO the crucial point is:
IF , and ONLY IF, your comparing statement tests for EQUAL, AND you are only interested in ONE (the first possible) TRUE, the choice is easy, switch is more efficient and replaces case completely.

In any other case (pun intended), to use switch you have to be absolutely sure that NO other, further, condition might "hit", - if not, you need case.

Sorry, no good example to share, but the above should do


Karl

[Frank Maraite]

Karl,

did you mean two CASE conditions with two different case blocks? Or two differetn CASE conditions with the same case block?

Thas last one comes with (from Phil's example):

SWITCH MaskOption
CASE MaskOption.None
myRXO := RegExOptions.None
CASE MaskOption.IgnoreCase
CASE MaskOption.IgnorePatternWhiteSpace
myRXO := RegexOptions.IgnoreCase // Sorry, it does not make sense, but ... you know
// This case block will be executed for both CASE's
OTHERWISE
myRXO := RegExOptions.None
END SWITCH

If this is not meant by you please give us an example.

I may check it but SWITCH and DO CASE do internally BREAK after the first hit, so no other, additional condition comes into play. Please tell me if I'm wrong. And I'm pretty sur in case of SWITCH there is always only one possible hit. Comparing a value against constants be exact match makes it unambiguous.

Frank

[FFF]

Frank,
a) Switch only checks one operator, "=="
b) i misread the branching descripton for Do Case, so yes, there is at max one hit per Case/EndCase as is with Switch
c) i heartily dislike the possibility to "stack" cases within Switch without written execution statements - i'm sure i'll never remember, if i only forgot to add them or not.

Karl

[wriedmann]

Hi Phil,

the "switch" statement has only a limited utility for me, as the expressions have to be static ones. This does NOT works:

Code: Select all

do switch nValue1
case nValue2
  nop
otherwise
  nop
end switch

whereas the "do case" works:

Code: Select all

do case 
case nValue2 == nValue1
  nop
otherwise
  nop
endcase

A sample for a "do case" could be:

Code: Select all

do case 
case nValue2 == nValue1 .and. nValue3 == 0
  nop
case nValue2 > nValue1 .and. nValue3 == 0
  nop
case nValue2 < nValue1 .and. nValue3 == 0
  nop
case nValue2 > nValue1
  nop
case nValue2 < nValue1
  nop
otherwise
  nop
endcase

My code is full of such constructs, and I try to use the "do switch" where possible.
This is a piece of code from my Door Configurator:

docasesample.png (76.48 KiB) Viewed 338 times

It should explain why the use of a "do case" is much more flexible than a "do switch".
Wolfgang

[Frank Maraite]

Hi,

@Karl:
Unit tests are your friend . Once you are familiar with you know the outstanding value.

@Wolfgang:
Your example shows what is named 'feature envy'. Put the boolean logic to where it belongs, the class oVariante, as some kind of 'super property' and return an enum. Then you can a) unit test your class b) use SWITCH. Of course it does not affect execution time but makes the code much cleaner.

@All:
I changed more than 90% of my DO CASES to SWITCH and found a bunch of bugs because in the case of SWITCH the compiler is able to check of double CASE's. With DO CASE this compiles ok:

Code: Select all

DO CASE
CASE Value == "a"
   DoThis()
CASE VALUE == "b"
   DoThat()
CASE VALUE == "a" // the same as the first CASE
   DoSomethingOther() // different CASE block.
OTHERWISE
   NOP
ENDCASE

This gives a compiler error:

Code: Select all

SWITCH Value
CASE "a"
   DoThis()
CASE "b"
   DoThat()
CASE "a" // This is not allowed by the compiler
   DoSomethingOther() // different CASE block.
OTHERWISE
   NOP
END SWITCH

When eliminating the 'feature envy' as described we can change almost all DO CASE's to SWITCH. That gives us more readable and better testable code, means less bugs.

Frank

[wriedmann]

Hi Frank,

I was sure you would ask me to change my code.

Unfortunately this code needs to be there as it has nothing to do with the AngebotVariante itself, but only how to edit it. Therefore it makes more sense (to me) to leave it in the ViewModel code.

For sure, my programming style is not the best one, and there are much better programmers than me here. And I admit than I have to change many things to make them better, but this piece of code is not on this list.

Wolfgang