|There's more than one way to do things|
I had to write a little blog application to integrate into our companies flagship site. All new work is done in PHP (that's a seperate rant), but prior to me being hired, they had one Perl programmer. Since she did all the initial work for the site, all the old code is in Perl.
For various reasons, mostly having to do with her maintaining the code, I was asked to write this little blog tool in Perl. Looking back over some of my code, I was appalled at how I had immitated much of the code that my program had to interact with. Globals everywhere, using a crappy internal library for parsing cookies, stuff I never do in fresh code. This was made worse by the fact that the senior Perl programmer doesn't write this way either anymore. Just the core (and therefore oldest) parts of the code are written that way.
I spent a week refactoring and rewriting the codebase, and created a list of things I would not fall into the habit of doing as I added new features. It was hard initially. For example, I need to require some definitions in from elsewhere, but this pisses strict and warnings off horribly. I had to wrap the include in some protective declarations, and then push the setup code into a subroutine to get the illegible mess out of my eyes. But being able to rely on compiler warnings has already saved my butt a few times since.
The key I think is to do what I did. Keep style imitation (and bug imitation) in old code. Don't be too subtle - when the original programmer does something dumb COMMENT IT! You'll be less likely to imitate it later, and more likely to find the subtle bugs that it creates. Keep a list of common mistakes and look it back over when transitioning between the two. Talk to the original programmers and see if their own style has changed enough to make it viable for you to correct some mistake in their old code.
Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet