Perl Monk, Perl Meditation | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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. In reply to Re^2: Consideration for others code
by jhourcle
|
|