What I usually aim for is that all new code/commits conforms to style and other requirements like having tests etc. Usually it is possible to configure tools to only flag something as a bad build when the new code doesn't conform to those qualities.

However, this means that as soon as you start mucking about in the legacy code, that code need to be covered by tests and formatted to pass any style checks and linters. That is not an insignificant amount of work so plan accordingly.

Also, I find it useful to remember that even if the code is not to my liking (for whatever reason) it might be consistent. I.e. maybe it uses some coding style I am unfamiliar with and I would rather it used another it is often detrimental to start changing it to be more inline with my preferences. Consistently poor code is often easier to reason about than code that is a mix of different preferences and patterns. This also goes for when thinking about introducing new technology to an existing code base (see the lava flow antipattern).