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
in thread Consideration for others code
by tcf03
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |