detekt: New Rule: Forbidden Annotation

ForbiddenAnnotation

Expected Behavior of the rule

  • Allows for certain Annotations to be disallowed at the project level. This is slightly different from ForbiddenImports as there are some times when an import might not also match to the Annotation.
  • If you don’t enumerate ALL imports (ie: allow .* imports)
  • If an Annotation doesn’t require an import (ie: @SuppressWarnings)

Context

Kotlin code should use Kotlin’s @Suppress annotation, not Java’s @SuppressWarnings and there are other annotations that we would like to not have in our code.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 17 (16 by maintainers)

Commits related to this issue

Most upvoted comments

Context from this slack thread: https://kotlinlang.slack.com/archives/C88E12QH4/p1590074412134700

I’m also not entirely sure we need a ForbiddenAnnotations rule.

@gtcompscientist scenario is involving annotations (such as java.lang.SuppressWarning) that don’t have an explicit import and are impossible to catch with the ForbiddenImport rule.

Closed with 028f69e

Thanks David!

For example, I would like to forbid the use of java.lang.Math and java.lang.Runnable

Small side note: there is a ForbiddenMethodCall rule that will most likely cover the use case.

I never open an issue but I would like to support the same for classes too. For example, I would like to forbid the use of java.lang.Math and java.lang.Runnable. And there’s other case: if the class is in the same package. So maybe the rule could be called ForbiddenClass and check all the cases: Classes, annotations and objects.

I know that I would use a rule like that but I don’t know how much value could it bring for the community in general.