>>So, if you've got a large number of iterations and/or method calls it could make a difference, but in normal usage it probably isn't worth worrying about. Like everything, you need to test it in your app to make a final decision.
>>
>>Interesting stuff... and Thanks!
>
>It is interesting. It might be a good practice to optimize even for small tasks. It's an acquired methodology. It would be difficult to turn it on just for big projects if our practices did not have a foundation in the little tasks.
>
>The first time I really noticed the clock (486D) was with a DOS dBase benchmarker I experimented with. It was a loop that set a variable to true if the loop counter was an "even" number, and false when it was an "odd' number. I think it was something like this:

>* this loop took twice as long
>for c=1 to 64000
>lleven=.f.
>if mod(c,2)=0
>   lleven=.t.
>endif
>endfor
>
>* ... as this one
>for c=1 to 64000
>if mod(c,2)=0
>   lleven=.t.
>else
>   lleven=.f.
>endif
>endfor
>
>* ... and ever since, even for really simple logic routers I still code it
>if 1+1=2
>   * do something
>else
>    * do nothing
>endif

>Then, one evening I was at a FUG meeting and Marcus and Crew (it's good to live in Houston - sometimes) were presenting - and what d'ya know - the marquee geeks (at least those from Marcus's shop) included an unused "else" in their logic constructs.

Did you ever try the ifless construct?

llEven=mod(c,2)=0

I'm not saying it's possible each time, nor that it's necessarily better than an ifelsendif, only that we shouldn't avoid it. Sometimes it may do nice to replace your five-liner with a one-liner. And it should work the same, for even, "even", odd and "odd" numbers.

>Software development is always about the details. A project should always "strive" to perform like a Ferari even if the developer is only building a shopping cart!

>Thanks for the "test" Paul!

Trying to confuse me again? I know it's a real test, despite your "quotation" "marks".