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

No, not at all. That code in a CASE is not only supplying factors for a decision but it is also doing 'work' necessary for the final outcome of the routine. My contention is that most programmers do not expect such a thing is a CASE. Simple as that. Expectations are different for IFs.

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

Call it an "unwritten convention" if you will. I can perfectly legally go around wearing my undershorts on my head. Does that mean I should?

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

I think my point is clear enough. Those who don't want to see it will not, no matter what I write. To recapitulate: programmers know to expect that anything can happen within IF constructs whereas they expect that only decisions factors will be evaluated in CASE statement. They do not anticipate that each CASE is expected to be doing a piece of "work" towards COMPLETING AN ACTION, but expect that any action performed within a DO CASE will be solely under the first CASE statement that evaluates to true.

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

Technically, of course, everything in code amounts to "personal preference". I'm trying to tell you that in the case of CASE statements doing "work" and all of them doing some part of the (overall) "work" to achieve an end you should seriously re-think your preference. Not for your personal immediate benefit but for those who follow you in maintaining your original code.
Volume of code or degrees of indentation should be at the bottom of anyone's list when it comes to the issue of "readability". However, other programmers' expectations and competencies necessarily have to be at the top of the list. After all, we are not in the business of writing puzzles. Any code that may be puzzling for other programmers is code that is not "readable" no matter how short and pretty and correct it might be.

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

Well, anyone who looks at my code will not be impressed by the 'prowess' it demonstrates. I acknowledge that some (many?) who look at it will immediately categorize me as a bush-league programmer. But I look at it this way: if I were a lawyer virtually anyone could read and understand my contracts. They would not have to call another laywer to understand. That's my definition of "readability".

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

Here we disagree. You can wite a legal contract using $10 words that might be very short. Mine using 10¢ words might be 3 or 4 times as long. To understand yours I have to call on another lawyer while anyone can read and understand mine.
If your 20 lines are loaded with "tricks" and unusual uses of language constructs while my 50 lines are simple and straightforward it might well be that the next programmer will be able to change my code far faster, and with more confidence, than your 20 line gem.

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

This still isn't justification for corrupting a construct. The issue is not tracking conditions and variables through extra lines of code. The issue is that in a DO CASE construct your average programmer expects only 1 CASE to be relevant within the entire construct. They do not expect that EVERY CASE plays a role in the final outcome. Code that does this may be shorter, prettier, less indented and avoid the dreaded "nested IF" but it is not easier to read and understand. In fact it is almost gauranteed to be misunderstood, leading to far more frustration before finding the root of the problem being worked.

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

I guess not.

cheers
>
>Walter,