AutoCorrect For Non-Formatting Built-In Rulesets

[johnameyer]

Detekt supports creating rules that auto-correct which is very powerful. However, in the standard library of rules only the formatting module currently makes use of that feature. Unfortunately, as far as my searches in documentation and Github have revealed, there doesn't seem to be reasoning for this or feature requests open asking for this in other places.

Many of the Style rules seem to have a simple resolution (and could save a fair bit of developer effort by automatically correcting). In particular the following rules (as a sample) seem to have a clear resolution that could be auto-corrected: ExpressionBodySyntax, OptionalWhenBraces, MayBeConst, UseIfInsteadOfWhen.

I would love to have it documented if the project is open to having autocorrect for these rules or the reasoning if not.

Ref: CLI Option

[schalkms]

Sorry for the late reply. I think I can shed some light on the matter. In early versions detekt included native formatting rules, which manipulated user source code, as ktlint does. However, no-one wanted to reinvent the wheel. That's why the idea came up to natively incorporate ktlint rules in detekt. Consequently, Artur build a wrapper around ktlint, which brings us to the current formatting ruleset. I also found one of the discussions from back then. This was just the executive summary. Surely, the full story is a bit longer. You can find it under the following issue #1304, as well as in the linked issues there. If you have more questions, feel free to put a comment underneath.

Anyways, I can think of two alternatives.

1. You could vote for this idea Suggesting auto fixes for violated parts to fix reports issued by rules #2560, which suggests auto fixes for violated parts of your source code.
2. You could copy the relevant rules of the style ruleset to your own ruleset and implement auto-correct for them as a custom ruleset. We would love to include your custom ruleset in detekt's marketplace. 🙂

[cortinico]

To add to what @schalkms said, we discussed this matter a couple of times with the other @detekt/maintainers. The agreement seems to be that we don't want to implement autoCorrect for other 1st party rules.

The rationale is what @schalkms said + the problem that once you start manipulating the code you might generate code that raises other violations, so we'll have to handle multiple passes of the inspector and so on.

Writing rules under the assumption that the inspected code is never manipulated is a good invariant which allows us to have a leaner core.