Posting here for discussion. I assume there isn't...

# detekt

[Ty Smith]

Posting here for discussion.

I assume there isn't a current way to do this, but I wanted to verify.

We have a custom detekt rule used to have very granular banning of things in different ways. Like methods, imports, classes usage, inheriting classes, and several other use cases we may find problematic. This detekt rule's list is shared between a custom Errorprone rule and our detekt rule.

Occasionally people Suppress this rule by it's key, but then for the scope of suppression, everything in the shared banner is allowed. I would like something like @Suppress("SharedBanner:com.foo.x", "SharedBanner:com.bar.y") to allow specific suppressions without doing the entire thing. Any thoughts on approaching this with the current detekt APIs or would this need to be a change upstream? I imagine the scenario might exist today using config files with the default rules if someone suppresses banned imports, but only for 1 import and then they accidentally get a second one they are not warned about.

[Brais Gabin]

The are a lot of layers here. Out of the box that's not doable. Maybe a baseline would help you here instead of a suppress.

[Brais Gabin]

But, luckly detekt is extensible and not only in the rule section. You could create your own suppression system and look for those type of suppress annotations.

[Brais Gabin]

There is not too much documentation about it but the entire baseline feature is based on that api.

[Brais Gabin]

So there you have a good example to start with. You will get a list of detektions and you can filter that list in the way you want.

[gammax]

My 2 c: you should split your rule.
Ideally refactor it, have some custom infra shared between rules, but the inspection itself is performed by distinct rules.

This will give you all sorts of benefits, like more granularity on the config, on the suppression, on the baseline, etc.

[Ty Smith]

The maintainability of a dedicated checker for a list of hundreds of banned methods, classes, etc.. seems like a pretty nasty situation to deal with, even if some is shared. @gammax is that what you were thinking in your recommendation?

[gammax]

I don’t know how ‘big’ is your single checker file, but I’d personally go with one of those two alternatives:

[gammax]

1. Keep the single checker and inside it define different issue with different IDs (see https://github.com/detekt/detekt-custom-rule-template/blob/1066ffd07e0d41d3d9e54f059c9a790efebdff4c/src/main/kotlin/org/example/detekt/MyRule.kt#L13-L18) That will allow you to still keep a single checker but report distinct issues for distinct codesmells
2. Just refactor the checked to have some shared Infra (which I suspect you’ll need) in a separate class, and have separate classes reporting different inspections. The pro of this approach is that if you raise a SmellyStatement detekt report, most likely you’ll have a SmellyStatementRule.kt somewhere in your codebase that folks can contribute to (so you’ll have a 1:1 relationship between report ID and filename of the rule).