Re: Consideration for others code

tcf03:

Tread lightly! The appearance of code is a "religeous war" issue to some people. Until the code becomes *yours* (i.e., you're the primary maintainer), change the code as little as possible. I'd definitely add "use strict" and "use warnings" statements to the top, and fix errors as they appear. But you should use the same style as you find in the (ugly...to you!) file.

(It never ceases to amaze me how much time can be pissed away by people reformatting each others code.)

Once the code becomes yours, however, then you can start on structural and stylistic improvements. (As your schedule allows....)

Also, there are politics involved: At one place, I was maintaining some code that I thought ugly. In a couple of places, it was particularly bad, so I was complaining about it to my boss. About a month later, I found that my boss was the one who wrote that code. It took me several months to fully extract my foot from my mouth...... 8^P

It's also possible that you may come to appreciate the style in use. (I've changed styles more times than I care to count. It's amazing what you can get used to quickly.)

Of course, the code *could* just be a hideous mess with no style. Even then, I'd restrict myself to bug fixes until I inherited it. And never badmouth code until you know who wrote it! ;^)

--roboticus

Comment on Re: Consideration for others code

Replies are listed 'Best First'.
Re^2: Consideration for others code by tcf03 (Deacon) on May 23, 2006 at 12:39 UTC
Thanks - This seems to be my best overall solution to the problem - I have already reverted back to the revision before I took over. I will be maintaining the code, but I feel it is in my best interest to, as you say, tread lightly. I have already stuck my foot in my mouth by making a general statement about the code - the guy who wrote it then went on to show me how his code was better than the example I was showing him. He did not write the particular program that I used as an example. I understand its a sticky situation, and I know how I feel when someone comes along and changes things that I have done. In time, I definatley will change the code to suit my style, as I am the maintainer - but some people have put in a lot of work to get it to the point its at, and I respect that... Ted -- "That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved." --Ralph Waldo Emerson	[reply]
Re^2: Consideration for others code by graq (Curate) on May 24, 2006 at 12:50 UTC
In a couple of places, it was particularly bad, so I was complaining about it to my boss. About a month later, I found that my boss was the one who wrote that code. It took me several months to fully extract my foot from my mouth...... 8^P I worked at a place where a colleague (sitting next to the head of IT) said "What ***** wrote this *?", only for said head of IT to say 'Me, I did'. Admittedly, the first thing the head of IT did to get code 'working' was to delete `use strict`, so it was a fairly valid point to raise. I have yet to be employed by a business that doesn't dance on the edge; eolving their code base rather than planning and developing. I point out the different solutions available (and their false economies) - but who wants to plan and create something to be proud of when hacking it will do for now. Personally I always point out any code that I know to be bad, or don't understand. But, this works for me, and should not necessarily be applied to all cases. Sometimes I do re-factor code by hand in order to learn what it is actually doing (which will be different from what others think it does, what the business wanted before and what they want now). I am not frightened of being wrong or highlighting my own lack of knowledge and I am happy to put my foot in my mouth. Either way someone learns something. Although I agree to some extent that you should have consideration for other people's code, I wouldn't lose sight of the fact that it most likely is not their* code - it belongs to the company. Your job is to amend, delete to create new lines of code that will profit the company you are working for. Keep a good perspective of what you are doing and who you are doing it for. -=( Graq )=-	[reply] [d/l]


Pathologically Eclectic Rubbish Lister
	PerlMonks