Best way to migrate a highly non-compliant project to Detekt

[JohnLKramer]

Hi, we are starting to use Detekt here and are pleased but we'd like to apply it in a larger project with a lot of violations. We'd like to break up fixing the violations into more than one task so that we don't have to fix them all at once as that is too heavy a lift.

What are some strategies people have used to do this? Off the top of my head, I can think of three options:

Suppressing issues on class/file basis and then removing the Suppressions as we fix them. But I don't really think this is workable because you'd have to suppress all of the rules.

Start with all rules disabled and gradually enable them. I don't really like this either because it is less clear where we are at in terms of fixing issues. Also, some rules (for example max line length) will be relatively easy fixes. Others (complexity rules) may require a lot of work.

Path based exclusion. This I think is the most workable option. It isn't as visible as the Suppress annotations but at least it divides the work up and is relatively easy to manage.

Thoughts?

[schalkms]

Do you know about the baseline feature in detekt?
https://detekt.dev/docs/introduction/baseline

The intention of the baseline feature is that only new code smells are printed on further analysis.
You could start with generating a baseline and then improve gradually by managing the total debt count. By regenerating the baseline again you then have a new base to improve your code base further on.

[BraisGabin]

On my project we use this. Some times we have tasks force to remove certain errors and other the code is refactor by the daily job.

We don't allow to add anything new to the baseline. And we regenerate it every night. This way the baseline is always going down.

[JohnLKramer]

Do you know about the baseline feature in detekt? https://detekt.dev/docs/introduction/baseline

I did actually. We might use it...but that isn't really how we want to structure the work. We'd rather chunk up fixing the code rather than say we're okay with what currently exists.

[schalkms]

I did actually. We might use it...but that isn't really how we want to structure the work. We'd rather chunk up fixing the code rather than say we're okay with what currently exists.

You could filter the entries of the generated baseline file based on the path. Let's assume you would like to remove a number of violations each month. Each month, you could filter more entries until the baseline is finally empty. Since the baseline file contains machine readable text in XML format, you could write a script to automate this process.