Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Hate Nested IFs? Consider this...
Message
De
13/01/2006 10:55:41
 
 
À
13/01/2006 09:12:31
Mike Yearwood
Toronto, Ontario, Canada
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9
OS:
Windows 2000 SP4
Database:
Visual FoxPro
Divers
Thread ID:
01086217
Message ID:
01086545
Vues:
25
>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.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform