>I'm not sure Mike, but I think that the code throughout the app was originally without m.dot and Naomi was changing it as she went along to use m.dot...

IF she's changing code just for her own purposes that's wrong. If she's doing it while making changes for business reasons, and she's doing what is technically and practically provably right for xbase languages - the only languages I'm aware of that exhibit this behavior, then congratulations to her. Since we're using Fox, we should work the way it really works. Adding them does no harm except a from a purely cosmetic perspective. It's hardly worthy of a professional to be concerned with this level of cosmetics.

If she has already made the change and they've gone into production, removing them is equally wrong.

Standards are guidelines for the most part. "If you're doing this, you must do at least that." If she uses the naming conventions "at least" then what is she doing wrong?

I know of a heart surgeon that uses a medical instrument and bandages to draw pictures of the heart valves etc while operating for the purpose of instructing other surgeons. While this practice is uncommon, it isn't against any standards because it would really be trivial to say "Thou shalt not draw during surgery".

This fellow also discovered a better way to repair heart valves by learning how they really work, by studying drawings Leonardo Da Vinci did - who also studied how the heart really works.

Frankly I recommend people use mdots. If they don't want to I don't force them. When and if something breaks in their code I'll let the customer hit the WSYP button. I don't expect anybody to force me to deliberately do what I know is wrong.

It all should come down to the customer/user. If adding the mdots hurts the customer in any way, it should not be done. If however, they can get imperceptible benefits - that accumulate mind you - why not give them these benefits?

>
>
>
>>>>Hi Naomi
>>>>
>>>>Thanks for your quick response.
>>>>
>>>>>Yes, it's efficient. I always add table aliases to avoid ambiguity. We're talking about lcVar = m.lcAnotherVar In this case m. indicates, that it's a memory variable and not a table field. Following strict naming convention reduces risk of running into table field to almost 0%. The performance difference would be visible only in lots of iterations...
>>>>
>>>>Aah, hadn't thought of a var to a var, so is it of general concensus that lcFirstVar = lcSecondVar is not efficient but lcFirstVar = m.lcSecondVar or m.lcFirstVar = m.lcSecondVar is?
>>>
>>>The second form. You don't need to put m. on the left side of expression.
>>>
>>>Did you read Gulliver's travells? The m. vs. no m. reminds me of the battle between different eggs beaters groups. Though in case of m. the m. supporters have more grounds...
>>
>>It's not the avoidance of mdot that I find stupid. It's taking a working, slightly faster and definitely safer piece of code (because of mdots), and changing it - which DEMANDS retesting, opens up risks to customers, users etc. - all because of someone's "personal preference" about insignificant COSMETIC appearances of the code.
>>
>>An engineer does not remove bolts from a bridge and replace them with rivets just because he thinks they look better.