Hi Walter,

i agree with Cetin,

the first rule for to be a good developer it is:

correctness and formal precision

m. it is not a option in VFP, it is a rule.
If i read a VFP program, and found:

? varCash

I must interpret therefore:
print the field varCash,
if you cannot find it then print the variable one varCash

If you write "? varChar", but you want to print the variable one, then the code that you have written is mistaken, will be able also to work, but it formally remains mistaken.

The performance variation is only a consequence of the rule and the fact that VFP is a pure interpreter, and therefore to interpret "m.varChas" demands more time than "varChar".

Fabio

>Hi Cetin,
>
>Personally I find the performance argument irrelevant. Only in a tight loop of a million variable references and having a wide table open it might be relevant. It is too farfetched to me, esspecially since it is very likely that in such loop you've got commands that do some kind of I/O (consuming a lot more time) making the whole performance difference irrelevant. When I find such instance (and that would be very, very few in the projects I've ever done) and have a performance problem in that area, I might consider using m. to speed up things. However, most of the time the performance can be enhanced by changes in the core algorithm.
>
>Since in my project I avoid the situation of fields and variables having the same fieldname, why should I bother to learn the wicked rules about when or not to use m. ? I Just don't use them at all, except in special cases where it is identified to have a good reason for it.
>
>I dump this in the "In theory an advantage, in practise irrelevant" bucket.
>
>
>Walter,
>
>
>
>
>
>
>
>
>>I didn't because reading there always made me feel m. doesn't have much contibution to performance and it's not right IMHO:)
>>Wish I could find the thread I mentioned that shows you can't ignore the time difference. Use m. to win.
>>Both from performance point + ambiguity resolve use m.
>>Cetin