Kotlin Extensions for Android Projects (don't do this)

I came across a Habr article about "experience using one of Kotlin's main features" and, as usual, I got triggered.

https://habr.com/ru/post/697908/

Let's go in order.

  • show, invisible, hide already exist in androidx.core-ktx as extension properties isVisible, isInvisible, isGone. Reinventing the wheel.
  • View.showIf, View.invisibleIf, View.hideIf are basically useless, since they do the same thing as the previous ones. Moreover, the first and last differ only in that the if inside is inverted. Don't create new entities (like new methods) if it doesn't bring value.
  • View.setBackgroundColorRes, TextView.setTextColorRes don't add anything, but add cognitive load to remember new extensions. New developers on the project will write the way they're used to by default.
  • TextView.makeLinks in this form is a bad practice, won't work with multiple locales, links need to be marked directly in resources.
  • TextView?.getDistanceText is interesting, extensions on nullable types are almost never needed, believe me, it'll save your nerves. And there's no reason to make this logic an extension to TextView. What's wrong with textView.text = getDistanceString(distance)?
  • Context.showToast makes no sense, since there's even a live template in Studio to avoid writing this - type toast + Tab. And why pass null to this method if it shouldn't show with an empty string - a mystery.
  • Context.vibratePhone could not be an extension and not pollute the namespace. You can still make classes in Kotlin!
  • String?.htmlDecode. Extensions to strings, ints, etc. - this is very bad, nothing pollutes the namespace like this. Oh, I lied, global functions and variables are worse.
  • EditText.onChange exists in the same androidx.core-ktx. Reinventing the wheel.
  • ImageView.setTint, Context.hasPermissions have a place to be.
  • The end.

What conclusions can be drawn? (The author has the right thoughts at the end, but doesn't follow them himself)

  • Adding new things at the global level increases project complexity and onboarding to it
  • Situations when you want to write a global extension instead of a separate class are rare.
  • Extensions to the simplest classes are almost always a bad idea
  • Many things already exist out of the box.
  • You need to try to reduce scope, so at any moment you have to remember fewer things
  • From the previous points you can derive the final one - think ten times before writing a global extension. Just because you have a hammer doesn't mean you need to solve everything with it