My suggestion is to change his code and comment it as much as possible. Sometimes people don't get the point and if you have to live with their mess, do yourself a favor and fix it. I do this everyday, fix other people's code, mumble to myself and then move on.
DO NOT DO THIS. Seriously, whether you like their coding style or not, there's better things you can be doing - for example your own work. But reformatting someone else's code (or even worse, restructuring it) can make it impossible for them if they're still working on the code and need to merge their code back in to what you've turned it in to, or for them to fix bugs in that code later on.
There's also the very strong likelihood that you won't actually understand all the subtleties of the code and you'll break something in the process. I remember a junior programmer doing this at a previous company who refactored and reformatted the code of a colleague who was about 20 years older, so basically the same situation. The younger guy's check-in comment: "Refactored code to look nicer". The older guy's next check-in comment: "Refactored code back to working" (he reverted the entire changeset back to his version).
So, the upshot is that at best you're just going to make the other's guy's life harder, at worst you're going to break the code in the process.
Personally, my golden rule is to change the minimum possible with each check-in, unless the task is specifically to refactor or rewrite a big chunk of code. If that means temporarily abandoning your preferred code style to work in a style that's consistent with the code area you're working in, then do so. Of course, that's what coding standards are for - to try to ensure the style is uniform is the same across a project, but that's often not possible across language boundaries or on projects that have merged.