Jim, I agree you on the whole thread. Code is about clarity, maintenance, and readability, not about how smart can you do it. You should follow certain rules and standards when coding that make it a bit repetitive task. It's not that fun sometimes, but it is the way one should do it.

I try my code to be the more alike to metacode. Reading the code should be like reading a business procedure. Everything should be pretty obvious. I had to read the CASE code twice to understand it, and that's not the rule with that simple piece of code.
What's wrong with:

local llSuccess

llSuccess = .f.

*-- I every step is completed, return .t.
if firstStep()
    if secondStep()
        if thirdStep()
            if fourthStep()
                llSuccess = .t.
            endif
        endif
    endif
endif

return llSuccess

I even like to include the line

llSuccess = .f.

even llSuccess being initialized to .f., because it makes clear what I mean.
The code is no that smart as the CASE code, but is more clear, and it is actually faster to write as you don't have to think it twice to figure it out if it's going to work.

Just my .02
Javier.

>ZAP! BOOM! BANG! PFTTTTT! (brings back the Batman series)
>
>That was your lightning, though I'd bet we agree on a lot more than we disagree on. My expressions of many things leave clouds where there is a need for clarity. Sometimes, with persistence all around, the correct point does come to light.
>
>Yes, I think you point out another problem with the construct under debate - one might find oneself structuring ones' code to facilitate use in such CASE constructs. In other words, there is the danger that some idiosyncracy of the language (that CASE *can* be employed this way) affects code in many unrelated parts of a program.
>
>But for me it still comes down to (real) readability, like when I'm debugging and want to see the pertinent code clearly and quickly.
>Whenever I see a CASE I say to myself 'oh goodie, I only have to find the single condition that applies here'. Given this corruption I am just as likely to conclude that 'OK, none of these apply so I can move on' because I would simply assume (correctly, in my mind) that the "conditions" on each CASE were indeed conditions. Later, when I was no further ahead, I would start going back over the code more 'carefully' and then I *might* spot this odd use of CASE. I would be right PO right then for wasting all that time and brainpower on nothing so far!
>
>I hope you recover quickly from the lightning bolt < s >
>
>
>>Hi Jim,
>>
>>I may get struck down by lightning for this next statement...
>>but I agree with you on this one. (bg)(ducking)
>>
>>In its defense, this *is* an interesting approach, but IMHO also a "future maintenance" nightmare. What happens if, in a future modification, I want things to stop or conditionally branch after one of the steps upon certain conditions being the case? If I want out after FirstStep, for instance, I still need to run -all- the code in -all- the other steps whether I need it or not. To carry this to its (probably illogical) conclusion, ** I cannot easily control what branches fire under what circumstances ** using this construct.
>>
>>CASE statements are intended to be used for executing only required processes based on a logical expression -- NOT to provide a logical code sequencer. CASE is meant to reduce the amount of code that must be parsed -- NOT to arrange the order of that parsing.
>>
>>Just my $.02 ---
>>
>>
>>>>>
>>>>>You may call it a corruption, I call it an elegant and readable solution to a common coding pattern.
>>>>
>>>>Kind of cool. I have never thought about doing something like that. However, I'd have to agree with Jim. It wasn't immediately obvious as to what was happening. I'd modify the code a bit to make it a little easier to understand (eg. add a comment):
>>>>
>>>>

>>>>Success = .f.
>>>>
>>>>* Run each method in sequence as each CASE
>>>>* gets evaluated. If an error occurs, bail
>>>>* out, otherwise set Success to true.
>>>>
>>>>DO CASE
>>>>   CASE ! This.FirstStep()
>>>>   CASE ! This.SecondStep()
>>>>   CASE ! This.ThirdStep()
>>>>   CASE ! This.ForthStep()
>>>>   OTHERWISE
>>>>      Success = .t.
>>>>ENDCASE
>>>>
>>>>Return Success
>>>>

>>>>
>>>>Like you, I think that I'd much rather see the above code than a bunch of nest IF statements.
>>>
>>>I shouldn't, but I just have to jump in here...
>>>
>>>"rather see" should not be a legitimate excuse for a coding practise that is a corruption of intended and expected usage of a programming construct.
>>>
>>>Just because I **CAN** cross the street without looking for traffic, it remains a stupid/silly/dumb/crazy/... thing to do.
>>>So it is with CASE. Who are you helping by coding this way?? If the answer is yourself, then it is the wrong answer. Similarly if you are doing it because you hate compound (or nested) IFs. Similarly if you are doing it because you hate typing.
>>>
>>>"Professionalism" doesn't mean stretching a language to its extremes or using nifty constructs because you understand the innards or using the minimum number of lines to accomplish some end or... In fact "professionalism" usually means quite the opposite. Take an Accountant... is there anything more boring to most of us? And look at what happens when an "Accountant" decides that his regular business is too boring and so starts devising alternative methods to accomplish 'standard work products' - you get your Enrons and Worldcoms and bunches and bunches of other like them!!
>>>
>>>CASE was clearly not invented for this kind of usage! Anyone who does so really is doing the busines of VFP programming a disservice IN MY OPINION!
>>>
>>>cheers