>>I don't think an IF...ENDIF, unless it goes beyond a certain number of nesting levels, is ever too complex. In fact, I feel quite strongly the opposite. I even prefer IF...ENDIF to IIF(...).
>>
>>I know there is a school that truly believes that any "extra" line(s) is the equivalent of added complexity. I just think they are wrong.
>>Probably it comes down to the idea that I don't write my code for VFP "experts" but rather for average-->lower-skilled VFP developers. The idea being that virtually anyone can then maintain my code.
>>I acknowledge that VFP "experts" might criticize such code, but I see that as their problem, not mine.
>>
>>cheers
>
>Well, the message you reply to was merely to point out that speed optimization is not the only reason for shortcut boolean evaluation - another reason was to avoid errors.
>
>If you prefer nested IFs, that is no problem with me...
>
>By the way, yet another reason for shortcut boolean evaluation might be to avoid side-effects of code:
>
>

>if functionA() and functionB()
>  ...
>endif
>

>
>If functionB() changes anything in the environment, then it may very well make a difference if SBE is used, or not.
>
>Once again, the code is completely equivalent to nested IFs;

NOT TRUE if functionA() can return NULL

>but a seasoned programmer should know that SBE does exist: in the code above, there is no >guarantee that functionB() will be invoked!