First off, test thoroughly. You won't get a lot of mileage out of finding and fixing a bug your seniors don't think will ever fire, but if you introduce a noisy one you're dead in the water. A test which shows the code violates spec or can realistically fail should lead to the next point.

If you can identify who wrote something you want to alter, take it to them privately and ask some questions leading up to a discussion of alternatives, and finally to a "How about we . . . ?" question. Extra points for leading the guy to propose the solution. Now he's on your side. Remember that the guy has experience; you won't fool him if you try to lead him around too much. You'll annoy him if you won't get to the point in a straightforward way.

Style isn't a good enough reason. The rationale behind the style should be the focus, whether it's prophylactic, like strict and warnings, or for readability and maintainability.

Most coders will respond well to a collegial approach, but will bite back at a cocky, breezy, or confrontational junior.

Added: Use a version control system!! You then get to keep breakage brief and private, and you can back out of mistakes accurately.