detekt/detekt

A rule to handle the scope polution

Offen

#2.863 geöffnet am 12.07.2020

 (4 Kommentare) (4 Reaktionen) (0 zugewiesene Personen)Kotlin (834 Forks)batch import
featurehelp wantedrules

Repository-Metriken

Stars
 (6.942 Sterne)
PR-Merge-Metriken
 (Durchschn. Merge 4T 9h) (65 gemergte PRs in 30 T)

Beschreibung

The scope polution is a problem that the extension functions have. It should be great to have a rule to detect this problem and flag this kind of functions. An example of this type of extension functions:

fun String.toUser() {
  Gson.fromJson(this, User::class) // this code doesn't compile, but you get the idea
}

This function can be handy in some scopes but it polutes the scope of String. If you only have this one is not a problem, but if you have multiple the problem is bigger. And if you add this in a library the problem is even bigger because you are poluting the client scope too.

This is a really difficult problem to address because the extension functions are really handy.

My first idea: A rule that have a list of classes (we should allow all classes in a package too, for example java.lang.*) and it will flag any public top level extension function over those classes. And we should thing to add a flag so the user could decide if internal top level extension functions are ok or not.

Problems that I see: This rule will have false positives. For example:

fun Any?.exhaustive() = Unit

Do you have any other ideas to help with the scope polution problem? Is it worth it?

Contributor Guide