Walter,
Personal preferences always win:)
I don't know I find it harder really to put the m. but I can say you might easily understand if a code from me is old or newer just by checking existence of m. all over the code :)
Cetin

>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