SNIP
>
>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 ??

I certainly can't agree (just because there's more code?) that it is "more complex". Sometimes more code makes for easier reading. It certainly is NOT axiomatic that less code = more readability.

The difference between IF... and DO CASE / CASE... is that average programmer expects that anything can happen in the arguments of an IF while (I maintain) 95%+ of programmers expect ONLY decision-related factors in CASE arguments and certainly do NOT EXPECT ANY CASE ARGUMENTS TO PERFORM AN ACTUAL *PIECE* OF WORK TOWARDS A FINAL PROCESS.
By design an IF implies that the interrogated function may well be doing some work and reporting its outcome. A CASE is expected to simply report an outcome, *I* contend.
>
SNIP
>
>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.

I'm not going to re-write because this is a more minor example of what I find objectionable.
A cursory look by anyone might well conclude that yours is even more readable, but they might see it very differently if they were in the throes of debugging and the code was a little more complex in nature.

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

Right, **your** personal preference is for the shortest code possible. I'm trying to say that this is an incorrect conclusion for the general programming population - at least when carried to this extreme. Shortest code possible is generally good, but it is not axiomatic and ought not be used to otherwise justify corruption of 'expected' usage.
Just because VFP "lets" you do something doesn't mean that you should use it, especially when you know that it is production code that others will be called upon to maintain.

We have a fundamental disagreement as to the definition of "readability". You apply it to yourself and I apply it to everyone except myself. My programming is generally of the simplest form and wastes (as you might call it) lots of lines. But I am quite sure that people would find my code easier to modify than they would find code using corruptions of DO CASE like this. That people might see my code and call it "bush league" is of no real concern to me. I am confident that anyone could easily read/understand/revise my code regardless. And they would be real silly to re-write working code just because they thought it took up too many lines.
>
>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 ??

I have to admit it is rooted somewhat in "personal preference". The preference that code be readily understandable by doing only expected things with specific constructs. I do not make number of lines a factor because I have a scroll wheel that negates that "problem". Also, systems are so fast now that it is only in very rare situations (and I feel I know those well) that an extra few lines will cause any impact at all.

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

And there is no real way to measure it. All I can say is that most of my programming life has been spent in systems and applications where more than me was responsible for the code and we had "programming standards" that undoubtedly would have outlawed this corruption of the CASE construct for the overall benefit of us ALL.

cheers

>
>Walter,