>My underlying concern was not whether or not the code should be changed whenever it can be done without going against standards, guidelines, or breaking other code, but rather how she went about it. She is already trying to resolve a touchy situation at work and this only compounds it. It is obvious that her coworkers are resentful that everytime she touches something, she modifies it in order to optimize it, enhance it, or just for aestetic reasons. They have already left childish nasty grams inside her code (do not do this...) and they removed her changes. Before she proceeds she should clear it with her boss or risk more animosity among the developers. She is not working in a healthy atmosphere and this will only make it worse. Sometimes it is better to 'let things go' if they are not truly necessary in order to promote a better working environment - unless she is willing to go to work for herself. Naomi knows that her changes made the code more efficient - she knows
>she was right - but it is not always better in the long run to be 'right.'

Unfortunately that is the saying "Where ignorance is bliss it's folly to be wise". But I think generally I agree with you. On the other hand, we have to work to change the standards if they are insufficient.

>
>
>>>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.