>Jim
>
>>>To me, this looks like the standard checklist approach:
>>>

lCanDrive=.f.
>>>do case
>>>   case not this.HaveCar()
>>>   case not this.HaveLicense()
>>>   case not this.drunk()
>>>   case not this.tired()
>>>   case not this.car.tank.empty()
>>>   ...
>>>   otherwise
>>>   lCanDrive=.t.
>>>endcase

>>>
>>
>>This isn't too bad, but the conditions aren't doing any work either.
>>But when the construct is used as a mini-mainline but they look like condition tests because all CASEs are assumed to be condition tests they sure mislead me, because I expect CASEs to test things and I expect only 1 CASE to be relevant (or the OTHERWISE).
>>I can talk/write crap English and still be understood, but it is not recommended for a variety of reasons. Same goes for programming, and just because you can do something doesn't mean you should.
>>Of course others will disagree. I'm not telling anyone what they should do, only why I don't like it.
>
>How about a car-based example of what you feel is dangerous. Please demonstrate the danger.
>
>Is something like this the problem?
>
>case not this.ChangeOil()
>case not this.FillGasTank()
>otherwise
> lCanDrive = .T.
>endcase

I would read this, clearly, as TESTS... is the "change oil" indicator true and is the GasTooLow indicator true. And given only two conditions with no code for either CASE, I could tolerate it.