Re: Consideration for others code

This sounds a little backwards to be as a good way to ease yourself into the team. I'd have been inclined to say someting about how many times strictures had saved me untold time and embarasement in the past and would it be ok to add them through out the code base - "I'll fix any problems that show up as I add them".

Same sort of thing with the poorly structured code - "I don't quite see what's going on here" (to the original author), then: "Oh, now I see, but would it be better like this? Is it ok if I make similar changes elsewhere to improve maintainability of the code?".

I'd watch out making cosmetic changes that only affect layout unless the original layout was inconsistent. There's nothing that stirs up wrath more than having someone come and "fix" your carefully laid out code! One thing that may help is running the code through a pretty printer - just to make the layout consistent of course. :)

DWIM is Perl's answer to Gödel

Comment on Re: Consideration for others code

Replies are listed 'Best First'.

Re^2: Consideration for others code
by jhourcle (Prior) on May 23, 2006 at 13:23 UTC

Or someone (who thinks they understand what the code is doing) makes an 'optimization' that changes an edge case.

Similar to GrandFather's suggestion, I personally try to start with commenting the code -- breaking it apart, trying to figure out what it's doing. Yes, there are some people who get touchy about comments, but you can add the notes in there / write the documentation, and then ask the original author(s) if you understood their code correctly -- it leaves you (and them) in a better position to maintain the code down the road.

Depending on what state the code's in, the personalities, and the skills (most of the folks I work with are IDL programmers who dabble in Perl, so don't think in terms of map or foreach) -- if the people are receptive, you might be able to give some helpful 'did you know you can ...'-type tips, and then show them where it can be applied to their code.

Oh -- and on a related note, the original poster might want to read A refactoring trap, which discusses some of the problems with 'fixing' code.

[reply]


go ahead... be a heretic
	PerlMonks