Hi James

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

OK, that's definitely not what I advocate. If a developer needs to change stuff for business reasons, go ahead. I don't agree with this business of rigid coding style standards. That is being taken too far. All code does not have to look like it was written by one person. There has to be room for some personal freedom. This is North America after all.

I work with lots of previously existing code. I often struggle with wanting to change it. I wrote about something recently here on the UT where the previous programmer built private arrays high up and used them everywhere except in one case where the array was passed. This ARCHITECTURAL (not cosmetic) change was confusing and dangerous. It's recommended that information be passed to functions, and not made public (which private from high up really is). Yet I didn't change that.

While working with Drew Speedie, we had standards and we all worked together really well. We even had a way to make things more fun working together. If you write a piece of code that is called by my routine, and your code causes my code to break, you'd get the weasel award. This was really great. It meant we all tried extra hard to discuss how pieces of code were written, how they'd interact, and to make sure they worked, just so we didn't get the weasel. If Naomi's code breaks someone else's code give her the weasel. It was a little stuffed animal. Everybody knows you messed up and the darn little thing stares at you.

Now, as to the mdots, that is a side issue to Naomi's willy-nilly changing code. Besides, don't you have source control? Someone should be controlling when a developer can check out stuff before they make changes.

OK, some feel mdot is not significant. Fine. Don't stop others from doing it if it's so insignificant. If you see it in some code, ignore it. Nobody should use a cosmetic argument like "it looks weird" to stop me from making my code more secure. I don't stop people from smoking because it's not significant to me and that's a bad habit.

Frankly I wish I didn't have to use mdots. I got bit by not using them years ago and I will never make that mistake again. Nor will I let my clients face it either.

I put code into old systems. There's no documentation, there's no way to find every dang fieldname just to be sure I don't name a variable the same as an existing field.

I'm trying to do my very best work. I'm not worried about what other programmers think because we are ALL supposed to be concerned with how the systems work for our users/customers etc first!

If you worked for me, I'd recommend you add mdots, but wouldn't force you - UNTIL some customer got a crash from you not using them. Then I'd make you fix it FREE no matter how long it took. Would that be enjoyable?

Didn't you see someone within the past couple of months on the UT who has years of VFP experience got bit in the butt hard by not using mdots? What you think it'll never happen to you?

On the other hand, I'll never be put through that because no matter what, my code won't fail EVEN if there's a conflict. I certainly sleep better that way.

Are you going to let an architectural problem exist because you're concerned with the cosmetics of the code? That's wrong.

Sorry for the RANT, but why would anybody live with a risk that is so easily handled by something so seemingly insignificant?

Over and out.


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