I think maintaining the coding style (indentation, brace styles, etc.) is perfectly reasonable, as it helps legibilty by not taking the programmer 'outside' the content to consider a new style.

Maintaining the semantic content in the face of badly written code is a more tricky issue. When I am tasked with fixing buggy code that is badly written, I usually consider how much time I have available and the amount of code that needs to be changed. Refactoring ugly code is an almost palpable desire among good programmers, but that has to be balanced against time pressures and the introduction of new bugs in the refactored code.

If time is short and the change is a line or two, it is probably just best to make the change fit the surrounding code, along with a comment as to what was changed, and a corresponding test in the suite.

If there is more time available and/or the bug is more fundamental, I'll try to refactor the subroutine(s) that contain the bug. If this is a personal project with no time limit, I might refactor the whole program :)

No matter what the size of the change, it is good to add a test to check your work; larger refactorings may need multiple tests.

I'd check with the boss or owner of the code as well. I once joined a physics lab as a new grad student and the lab space was a complete disaster. While waiting for parts for my expt, I organized and cleaned up the place. My advisor took one look, and had a full-blown conniption: eyes popping, orange smoke coming out of his ears, the works. I had messed up his organization. We spent hours getting it back to it's original state.