SNIP
>
>I'd say that is a personal opinion, and I don't think that every VB user using the VB equivalent to VFPs DO CASE would agree also.

Well I *know* that there are some here (UT) who disagree with my position on DO CASE and, like EXIT/LOOP, I admit is is a personal preference to a large extent.
BUT... if one is talking about readability I think it's safe to assume that the majority of readers expect a single CASE condition to be true and certainly does not expect that any CASE condition is going to do actual "work" and then respond with .F. (or the CASE being constructed to force a .F.). A CASE statement is designed to ask a question, not to perform some piece of work.

>
>>I continue to contend that DO CASE's design was never to do as your top example shows AND that most readers never expect to see one doing what you are doing. That itself makes its readability questionable. YOU expect/know its intentions but an outsider will read the code anticipating that ONE of the CASE statements will return true and so execute the code below it.
>
>Again, I think we disagree on the intent of the DO CASE. I truly do think that a do case was designed for these kind of constructs.

Well just have a look at the Help for it. It starts out with "Executes the first set of commands whose conditional expression evaluates to true (.T.).". So right away a .T. is EXPECTED to occur. Then the examples show the CASE statement having an argument "lExpression1". My opinion is that this does NOT convey that lexpression1 is going to do ANY "work" other than return a T/F. Validating a customer's status would be fine, but generating an invoice THEN RETURNING FALSE is not "readable" because avergae code reader does not expect any CASE statement to generate an invoice. The rest of it's entry in Help makes no mention of the corrupted construct you advocate.

>
>>Just because something can be done does not mean it should be done. For instance, languages that have GO TO, JUMP, BRANCH, etc still have them but people simply do not use them to cross module boundaries.
>
>I'm getting the impression you're using about the same arguments against my usage of DO CASE, as I've been arguing with the usage of LOOP and EXIT, Aren't we ?

Well I quite see it the other way... in the case of LOOP/EXIT you say they harm readability yet in the case of your DO CASE you say they help readability.
Now if readability means code with fewer indentations, you are right. But if readability means using constructs as expected then you are way off. Readability does not mean fewer keystrokes by the original coder, but rather that a (next) reader can quickly and easily and accurately see what is going on.

Notice, by the way, that your VB equivalent uses IFs. To me that only further backs up that IFs are what should be used in the cases cited and not CASE.

cheers

>
>Walter,