Hi Jim,

First of all, I have trouble reading to what DO CASE construct you are refering to. I've made 4 DO CASE construct and one nested IF

>I've always recognized that FP/VFP's DO CASE differed from the "traditional" CASE found in other languages and feel that it is yet another small advantage of VFP over other languages. It is rare that I restrict a CASE to a single variable being tested for different values.
>So I certainly have no problem at all with your first example below.

I take, you mean the second example.

>My objection comes from one factor in particular, which is usually justified (as you do here) by "I hate nested IFs".

>I will try to precisely describe what I find objectionable:

>I say that 100% of programmers expect that the "work" of any CASE statement of a DO CASE is to make some decision, whether it is simple or complex.
>When it is simple then the factors can be coded right in the CASE, but more complex DECISIONS might need a function call or two.

>When a function call in a CASE statement does more "work" than simply make a decision then I believe that you are betraying the expectations of 95% of VFP programmers. And when you deliberately preceed that worker function with a little "!" so that the tests will continue to later CASEs then you confound them even further.

Well I might understand your objection against the little "!" : maybe I should use "NOT" instead.

>Is that worth it just because **you** hate nested IFs? My answer is no, it is not, WHEN IT IS PREDICTABLE THAT OTHERS WILL MAINTAIN THE CODE.

Not sure what you're saying here.

>For the sake of YOUR distaste of nested IFs you will significantly extend the maintenance time of some other programmer to enhance or fix the code!

Well I think this is where I disagree. The DO CASE in most cases IMO is *far* more readable to most VFP developers, if they give it a chance. Regardless of what you say, the nested IF always has a problem with the IF and ELSE clause beeing too far appart to be readable in deep nested IFs. The NEXT programmer might be tempted to insert some code that it makes it even harder to read making it even harder to read.

The DO CASE otoh forces the developer to fit in the logic from a top down sequence (the CASEs), and there simply is no specific ELSE, except the next CASE. It restricts the developer from making unreadable code in many cases IMO.

>From a 'readability' point of view your second example is really off-putting to me. You've had to use "!" in 4 of your CASE statements to assure execution of the next in most cases. While it's perfectly readable on the second CASE the "!" in the first, third and fourth instances hurt readability badly. Remember, the only "work" expected to be done is to make a decision or to provide a decision factor. Yours are doing more than that.

Again, I might understand the "!" readability argument. We can solve that one with a NOT. BTW this is not specifically a problem with DO CASE, but more with the "!" itself. Further the usage of "!" is depended on the problem. With nested IFs you have to use them as well or use the ELSE condition with an empty IF body.

The core of your argument here seems to be "95% of the programmers don't expect the argument of a CASE to do any work, but rather only simple comparisons".

I don't know if that is true. I've seen many DO CASE constructs from other programmers doing functions like TABLEUPDATE(), SEEK() or other UDF functions. Maybe a survey would tell, but either you or me might be wrong in here.

>I believe that most (95%+) programmers start reading a DO CASE with the mindset that they don't really need to examine each function in detail because only a decision (factor) is being provided so they can readily assess its impact on their problem at hand by simply reading the whole DO CASE. So they will quickly move on from here because they see nothing that might impact their problem at hand.

I believe it is just a matter of Abstraction. If I say something like:

CASE THISFORM.RecordHasChanged() AND !THISFORM.SaveChanges()

I don't think you'll have to do a lot of investigation to know what it is doing. Not that in the nested IF version the statement is the boolean inverse.

IF !THISFORM.RecordHasChanged() OR THISFORM.SaveChanges()

Note that you did not get rid of the "!"
I take that you have the same objection against the above because now the *IF* is doing more work than 95% of the NEXT developers expect?

So you would solve with something like this ?

lSavedRecord = .T.
lRecordChanged = THISFORM.RecordHasChanged()
IF lRecordHasChanged
   lSavedRecord = THISFORM.SaveChanges()
ENDIF

IF lSavedRecord
    .....

I certainly would object against that, because it is more complex than the original in anyway.
If doing the functions directly in the IF argument, I really wonder why you make a difference between the argument of an IF and a CASE ??

>Once they learn **YOUR** chosen usage then of course they now know that they have to carefully examine each and every function call's code too. That is decidedly not "helpful".

Again, I think it is a matter of abstraction here. A function should have a meaningfull name and cover the things it does. In cases there can be any doubt, a comment in the first line in the CASE body might be helpfull if there is any doubt.

If I look at the alternatives, I doubt that anyone would say that the DO CASE usage is less readable then the nested IF alternative. I would ask you to rewrite the 4 DO CASE statements in your way and let the lurkers tell us what is more readable.

>There are certain things in VFP programming (and any other) that "personal preference" ought not to overrule. Some that come to mind are abbreviating everything to save typing, coding a 8+ function expression to show one's coding prowess, avoiding the use of nested IFs by employing a 'corruption' of DO CASE just because one hates nested IFs. These are things that may satisfy the originator but they surely hamper the NEXT programmer's work in that code.

Not sure what you mean with a 8+ function expression? Anyways, my main objective when using DO CASEs is to reduce code and increase readability and therefore reducing the chance of coding mistakes. Therefore it is my personal preference to do it this way.

It seems however that you disagree in my standpoint. Is this only because of you think that the DO CASE should not be used for that ?? Or that most users will be confused ?? or because of your personal preference ??


>The ultimate purpose for "readability" is to serve the NEXT programmer. Your second CASE construct fails that for 95%+ of programmers.

Again, I have trouble believing this actually beeing the case.

Walter,