Hi jim,

>>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 don't agree here. I don't see anywhere that it is restricted to evaluating variables or constants

>>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.

My functions are expressions also, whether they do any work or not, really does not matter from an abstractional point of view. The functions return .T. or .F., so the arguments are regarded as expressions (as anywhere in VFP functions where this is mentioned in the help). lExpression in the helpfile does not mean it is restricted to comparison of variables and constants only. You can do powerfull things to include VFP function and/or user defined functions in there.

>>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.

They can be harmfull yes, while DO CASE usually is a blessing, and you're saying the opposite.

>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.

My personal thought is that DO CASE increases readability because, if a CASE argument evaluates to .T. you execute the code beneath it and then directly go to the ENDCASE. Using proper indentation will inmediately tell where it is and which cases do exists. With multiple IFs you're not that sure you still have to go through significant amounts of code because there might be a next IF whose condition is met (not simulating a pure DO CASE). And it are those constructs (nested IFs that make programs less readable)

>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.

There is only one VFP equivalent to the IF .... THEN ... ELSEIF ... THEN ... ELSEIF ... THEN ELSE ... END IF construct and that is DO CASE.

(First IF = DO CASE + CASE, ELSEIF = CASE, ELSE = OTHERWISE, END IF = ENDCASE)

Don't be fooled about the syntax, the constructs characteristics is about a 100 match to DO CASE. The VB SELECT CASE otoh does not have a VFP equivalent, except that you can more or less implement it with DO CASE.

We have to agree to disagree here.

Walter,