Hi Jim,

I agree that the most traditional and simple usage of DO CASE is the construct that is simular to the switch case structure found in several other languages:

DO CASE
    CASE x = 1
        .....
    CASE x = 2
        .....
    CASE x = 3
        .....
    CASE x = 4
        .....
    CASE x = 5
        .....
    OTHERWISE
        .....
ENDCASE

However you can do more with it. In the above example the order of the casing does not matter. However You can also use the ordering to rule out certain conditions.

DO CASE
    CASE DELETED()
        ... Do nothing

    CASE OLDVAL("MyField") == EVAL("Myfield")
        ... Do nothing

    CASE OLDVAL("MyField") > EVAL("Myfield")
        && Increase stock

    OTHERWISE 
        && IOW, OLDVAL("MyField") < EVAL("Myfield")
        && Decrease stock
ENDCASE

In the above the ordering is fixed. You cannot change the ordering without changing the behaviour.

The thing you are objecting against is the use of functions to perform a certain action.

DO CASE
    CASE THISFORM.RecordHasChanges() AND !THISFORM.SaveChanges()
        && Failed to save the changes

    CASE !SEEK(cItem,"Items")
        && Item does not exist

    CASE Items.Discontinued
        && Item has been dicontinued and thus cannot be ordered

    CASE nOrderCount = 0

    CASE nOrderCount > 0 AND !oBizOrders.Order(cItem, nOrderCount)
        && Could not order 

    CASE nOrderCount < 0 AND !oBizOrders.Order(cItem, nOrderCount)
        && Could not return order

    OTHERWISE
        && Order has succeeded
ENDCASE

I am well aware of that developpers comming from another language and see the DO CASE as a replacement of the switch case statement (or another simular construct in other languages) might get confused at first sight. However the last example above atually simulates a flow diagram where the CASEs are implementations of decision points.

IMO, this implemenation is more readable than the implementation with IF statements:

IF !THISFORM.RecordHasChanges() OR THISFORM.SaveChanges()
   IF SEEK(cItem,"Items")
       IF !Items.Discontinued
          DO CASE
             CASE nOrderCount = 0
             
             CASE nOrderCount > 0
                 IF !oBizOrders.Order(cItem, nOrderCount)
                     && Could not be ordered
                 ENDIF

             CASE nOrderCound < 0
                 IF !oBizOrders.Order(cItem, nOrderCount)
                     && Could not be returned
                 ENDIF
          ENDCASE
       ELSE
          && The item has been discontimued
       ENDIF
   ELSE
      && Item does not exist
   ENDIF
ELSE
   && Item could not be saved
ENDIF

While I do recognize that nested IFs cannot always be avoided, reading through a nested if is always troublesome (at least for me). It takes me a rewrite to figure out what it exactly is supposed to do and draw a process flow diagram out of it. a DO CASE in this instance would give me a better structure to give this overview. Its a more high level of implementation a process flow IMO.

The problem with the nested IFs is that the ELSE of the same condition could be a few pages away. In the past I had to deal with a lot of clipper programs that were written in the JSP style exactly doing this (a DO WHILE .T. with EXITS, LOOPS and a lot of nested IF conditions and a lot of repetitive code in a lots of ELSE conditions: a real maintenance nightmare.

Somethimes I may drift too far in my desire to capture everything into a do case. In a nested IF construct like the following..

IF x
   IF y
      DO SomeThing
      IF z
      
      ELSE
      
      ENDIF
   ELSE
   ENDIF
ELSE

ENDIF

The 'do something' is not a function, but does just perform a certain algorithm. It is not a part of the decisions in the nested IF. This does not fit well into a do case. In very exceptional cases were my urge to capture this into a DO CASE is stronger than my will to write a nested IF, I will do the following:

DO CASE
    CASE !x

    CASE !y

    CASE Something() <B>AND .F.</B>
        && Just a trick to execute the function something uncunditionally.

    CASE z

    OTHERWISE

ENDCASE

So, yes, I am aware that people not used to the DO CASE usages might find it odd at first, but IMO it is not that hard to get used to it, and in the end it might prove more readable and maintainable. So yes, I think people should be aware that DO CASE is not an implementation of switch .. case but a construct that has a wider application.

Walter,











>SNIP
>>
>>Also in this case, performance is not the factor that determines the place of a CASE statement in a DO CASE. The performance differences is in most cases negligible. Personally I use the order of the CASE to rule out certain conditions. I take advantage of the CASE ordering. While not regarded as best practise by many, its a practise I'm very comfortable with.
>
>I just **had** to make a comment here, Walter...
>While you yourself are very comfortable with that practise, you seem to neglect the fact that others who might read such code do not even expect such a usage and so might be led quite astray by such coding.
>
>I dare say, for instance, that most VFP developers do not expect a CASE construct to be written such that every (or most) CASEs WILL *each* perform an important part of a task. Most readers, I contend, expect a single CASE to come into play in a DO CASE block.
>
>So while you are very "comfortable" you seem to be making no allowance for who will read the code next. To me this is the single most important part of programming that has known production/maintenance requirements.
>>
>>I want to take the opportunity to point out, that seeking performance improvements in this kind of issues is useless. Most of the time the performance issue is related to database access or the algorithm or design of the system. Focusing on these kind of things to improve performance is non productive IMO.
>
>I agree fully. However, there is a difference between "focusing" and just plain coding practises that help to maintain high performance.
>cheers
>
>
>>
>>>Just my $0.02
>>
>>My € 0.02
>>
>>Walter,