If you're lucky enough to be working on part of a larger project or organization with defined coding standards, stick to those even if they disagree with your personal taste. People tend to get annoyed when they see you've checked in a two-line substantive change and 50 lines of renaming variables, moving braces, etc.

As an example, many people on my team never learned the lesson about bind variables in DB calls. So if I'm working with code that has this problem, I'll fix the statements involved in the code I'm working on but I'll leave the other ones in the module alone, unless I spot an actual bug in them.

Refactoring, especially within a module, is usually a good idea if it helps you introduce the change you need to make more cleanly. If I find that there's existing code that has two largely identical blocks and my change would require editing both of them, I'll try to combine them first so my new change becomes smaller. But I don't generally refactor code unrelated to the change I'm making even when I'm certain I'll do it better, just because it's not relevant at that moment.

If the change you need to make is more fundamental, or if the existing code is so horribly fragile that it can't accept any further changes, then large-scale rework (if not rewriting) may be called for. But be careful with this. When you see what looks like incomprehensible weirdness in the existing code, remember that it may reflect incompetence or laziness on your predecessor's part, but it may also have been a necessary workaround for some unpleasant real-world scenario.