Take three deep breaths.

First off, remember that the code works. Most sloppy code is the result of time pressure and improperly defined, rapidly changing specifications. When in doubt, ask the original programmer if your understanding of his code is correct. Stay away from making suggestions. You will generally get an explanation of the development sequence that led to the problem, and, often, the OP will -- on his own -- do some rewriting of the most egregious common modules.

Concentrate on your own code in all its glory. When you need to interface with another's code, discuss the API at the highest level possible. "I've found that this works" and "Will this help?" work better than "Don't do that".

Come from the place that everybody wants to excel and would if they knew how. It's just as easy (in terms of keystrokes, anyway :) to write clean Perl code as it is to write crap. Do not buy extra copies of quality texts, but do make it known that yours are available for study and that you've been helped by reading them. Be available as a sounding board, and you'll discover that the code around you starts to get better. Compliment improvements!

On a personal note, I have always found the above advice hard to stick to, but when I do, I'm lifted up to the position of de-facto project leader by my peers because people do want things done right. The most important part of that advice is to do your own job well. Until you do that, everything else you say is noise and does more harm than good.