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.