[archevel]

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).

[ainiriand]

Tank you for the reply. How do you configure those tools to only flag something as a bad build when the new code doesn't conform to those qualities? Is it something specific to you build workflow?

[cimmanom]

Some will let you specify files or directories to exclude. Others let you enable/disable one rule at a time.

It took us about 18 months of gradual chipping away to get our codebase to pass a linter, enabling one rule or class of rules at a time.

We're still working on test coverage. The key is to make sure all new code is covered (enforce in code review) and then very gradually backfill the rest. Add reproduction before fixing a bug. Add end to end coverage before a refactoring.

[archevel]

That depends on the tooling used. One way for linters and static analysers is to only run them on files touched by commits. For test coverage (if that is important) you can use something similar to detect the coverage for those relevant files. It really depends on your setup though.