>>>>>>>I think I would use:
>>>>>>>
>>>>>>>
>>>>>>>

do case
>>>>>>>   case not this.HaveCar()
>>>>>>>   case not this.HaveLicense()
>>>>>>>   case this.isDrunk()
>>>>>>>   case this.isTired()
>>>>>>>   case this.getCar().getTank().isEmpty()
>>>>>>>   otherwise
>>>>>>>      lCanDrive=.t.
>>>>>>>endcase

>>>>>>>
>>>>>>>I guess there as many ways as programmers <g>
>>>>>>
>>>>>>Not that many ways. I think I side with you that IsDrunk(), IsTired(), and so on are better ways.
>>>>>
>>>>>I actually never use this approach :).
>>>>>
>>>>>It's only that I liked it when I saw it in YAG's code, and thought that if I ever needed something like that, I'd probably go that way. It just happened that I didn't need it, and that the framework (i.e. my boss) prefers separate IFs - in case someone else needs to read my code. So in my current style, the above would be:
>>>>>

l=.t.
>>>>>l= l and this.HaveCar()
>>>>>l= l and this.HaveLicense()
>>>>>...
>>>>>if not l
>>>>>   *-- report error
>>>>>endif
>>>>>return l

>>>>>I know, this relies on VFP not executing any code past the point where l becomes .f., but I think the fears that this may change are unbased. The short logic hasn't changed since 1988, then why should it ever change?
>>>>
>>>>warning, with this style you cannot return a NULL value!
>>>
>>>And not any other type, except a Logical.
>>
>>no, any other fire a error,
>>but if l become null, it work like .T. in =l and this..... expression
>
>Just the opposite, unless I'm misunderstanding you.
>

>L=.NULL.
>L=L AND (1=1)
>?L             && .NULL.
>L=L AND (1<>1)
>?L             && .F.
>

>Regards,

>

clear
L=.T.
L=L AND (MESSAGEBOX("misunderstanding")=NULL)
?L             && .null.
L=L AND (MESSAGEBOX("Hi Jim")<>1)
?L             && .F.
L=L AND (MESSAGEBOX("not show")<>null)
?L             && .f.