>>Jim
>>
>>>>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.
>>
>>Meaning what exactly? If ChangeOil actually effected an oil change you would not like that? Why? I'm not criticizing. I only want to understand what you see as dangerous.
>
>What I see as problematic, at least for me, is that I expect CASEs to:
>1) test things only, not execute some needed work;
>2) have only 1 CASE relevant
>
>I've wasted debugging time when it is done otherwise, because of those assumptions. To me the "bad" constructs are the equivalent of code driving through a red light in that I just don't expect it. I can drive through red lights, but I prefer not to.
>
>If the problem was that 'we are losing oil in the system' I would look at that CASE and say to myself 'OK, that's not touching the oil' and I would move on. If it did the oil change I would have made a bad assumption.


So you're saying it's ok to ...

case CheckOil()
ChangeOil()

I guess I'd agree.