>In your item #1, with "a" evaluating to true, the result cannot ALREADY be known *until* the OR is encountered and 'recognized' as such. If it was followed by a AND (instead of a OR) then the result would *not* already be known. The only way to recognize the difference is to 'evaluate' the operator following the initial expression (in this case) and to make the decision accordingly.

I will put it in a different way: any operator is in fact a function, so, our expression can be written:

or(a, and(b, c))

Without optimizations, the and() must be evaluated before or() (or, more precise, the and() function will exit before the or() function).

>As you also know, and it is true for virtually every language, the programmer is always told to 'optimize' logical expressions by placing the known most "restrictive" condition(s) first so that the result can be determined with the minimum of execution cycles. This "proves" that the so-called VFP 'optimization' is a figment of the imagination - such 'optimization' is the programmer's responsibility and always has been. In fact we are all so used to it that none of us even considered writing the statement as b AND c OR a, did we < g >?! (or, alternately, [(b AND c) OR a ]

Always told or not, I simply don't do it! I write the conditions in the most readable form. I optimize them only if I need to do it. Since it's almost never a need for such optimizations... I do it very rarely.

Besides, I found out that the big majority of programmers "optimize" their programs based on their own criteria (usually, there's a very good justification for each optimization, at least in theory :)) that doesn't optimize anything in fact (often, the performance degrades as well as the readability). I have seen so many cases like this...

That doesn't mean you're wrong in this particular situation!

Vlad