Hi Jim,

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

I agree that less code is not neccesarely leading to more readable code. However I do find this a reasonable rule of thumb. Esspecially in the example above If find there is unneccesary code in there that could have been handled just in one line.

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

If begin to suspect that the root of the problem with this line is the boolean logic and the expected evaluation sequence (which actually might be different in different languages).

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

I have a problem with this. The do case is a direct equivalent to:

IF Contdition1 THEN
    ....
ELSE IF Contdition2
    ....
ELSE IF Contdition3 
    ....
ELSE IF Contdition4 
    ....
ELSE IF Contdition5 
    ....
ELSE IF Contdition6 
    ....
ELSE IF Contdition7 
    ....


If anything is allowed in an *IF* I can't see any reason why this is not allowed in a CASE statement.

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

Then please give us some coding example of the point you are trying to make. I guess I'm missing the point here.

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

Not per se, You're right I tend to write as little code as readability allows. It is an attempt to make a balance between volume of code, readability, bugless code and performance. That balance might be totally different for another developer, I agree, but this *ALWAYS IS* personal preference.

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

I'm not sure if this is the case. How can you judge that something readable for someone else except yourself. I might find your code less readable while you will say the same about yours. How do you know ?

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

Performance rarely is a reason to code compact, I totally agree. However, in general I would say that a piece of code taking up 20 (written, not empty) lines is more readable than 50 lines, just for the very simple reason that the NEXT programmer has to read less lines.

The tradeoff with less codinglines is that the lines itself are likely a little more "complex". OTOH, if you do it well, it helps the reader because it has not to track as many conditions and variables trough multiple lines. 

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

Then there is nothing left to agree to disagree.

Walter,