I find it hard to believe you can't find time for the UT :o) Are you no longer working primarily with VFP?


>I just haven't updated my profile in a while. I hardly ever come here anymore, but some of Nadya's post have gotten the attention of all of us who work with her.
>
>>Hi James! I wasn't aware of that. You both list different companies and the cities are different?
>>
>>
>>>I work with Nadya, and I can say that all of us fear her going into our code and changing it just because she feels she can make it better. Nadya has a tendency to take over other people's work and make it her own, without permission. She has been talked to on more than one occassion by our manager not to do this, but she doesn't listen. The m.s are a minor annoyance to all of us. She will take a working piece of code in production and replace all the variables with m.s. She also implements "improvements" that have caused serious problems in the past.
>>>
>>>I respect Nadya's ability; she is a talented programmer, but she does not work well with others. If she had her way she'd take over the entire project, and my manger knows this and has told us all to stand up to her when necessary.
>>>
>>>
>>>
>>>>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.'
>>>>
>>>>
>>>>>>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.