in reply to Maintenance vs. Programming style
As most posters here agree, if $work imposes standard style and coding practice, follow that! If I find colleage-code that doesn't follow these rules, I fix it and remind that person about the style we agreed and why. <rant>It cannot be denied that some people care less about small things like indentation and whitespace use than others</rant>.
If I get a project as a new and only owner, the very first thing I do is rewrite every single line to adhere to my style. Not only will the new code be very consistent and beautifull layed out in my perception, but it has proven a great way to understand what the original author had meant with the code in the first place. By reformatting, renaming, and reordering, you get a very good grip on the complete project and you can add the comments of your findings while you are at it, giving the next maintainer (in case you die) an even better base to start from.
Once style issues are `fixed', and of course all tests still pass, the first thing to do then is to put the project in git (fill in your favourite VCS) and find open/outstanding bugs. Now you understand the code, and have no excuse about not able to read it, fixing those should be easy^Wless difficult. Add tests for all the things that were unclear on this journey through code and for all the shiny new features you just added and release it.