Everyone who works a long time on any given project gets this:

I hate this code, it should not exist, I should rewrite it all!

Well, I think this is not the best idea. Although you want to make the code less bad, maybe even ‘good’, but to entirely refactor it, well, that’s a bad idea, and I’ll tell you why in this posting.

First of all: it’s a good idea to look critically at the code you are working on. You should do that all the time. For example: when you open a file you haven’t seen a long time; just browse through it, maybe you’ve started using a new technology recently; retired one. Just look at the file, try to understand what the programmer was thinking; was doing. If there are useful comments: great! Maybe the programmer is still at the company, try to ask him about it. It is possible he doesn’t remember, or he might, and tell you why the code is build the way it is. It could have been time pressured, or it might contain a difficult to understand algorithm because of .. reasons.

If all this isn’t possible, you should be careful, the code you are looking at is probably battle-tested. Even the bugs could be worked around(or even expected by the users). Try to pick your battles, if the coding style isn’t up to scratch, but you need just to comment one line, it would not be helpful to the other programmers to reformat the code.

If you are working on the whole feature/part of the code and need to do a really in depth change, I would suggest to start with a coding-style-commit, even before you change any of the code. That way it feels more like the code is part of the rest.

Good luck!