Kotlin Extensions для Android проекта (не надо так)

Мне попалась на глаза статья с хабра про "опыт использования одной из главных фишек котлина" и, как водится, я триггернулся.

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

Давайте по порядку.

  • show, invisible, hide уже есть в androidx.core-ktx в виде экстеншн полей isVisible, isInvisible, isGone. Велосипед.
  • View.showIf, View.invisibleIf, View.hideIf фактически бесполезны, т.к. делают то же самое что и предыдущие. И более того, первый и последний отличаются только тем что if внутри инвертирован. Не создавайте новые сущности (типа новых методов), если это не приносит пользы.
  • View.setBackgroundColorRes, TextView.setTextColorRes не привносят ничего, но добавляют когнитивную нагрузку по запоминанию новых экстеншнов. Новые разрабы на проекте по умолчанию будут писать как они привыкли.
  • TextView.makeLinks в таком виде - плохая практика, с несколькими локалями работать не будет, ссылки нужно размечать прямо в ресурсах.
  • TextView?.getDistanceText интересный, экстеншны на nullable типы не нужны примерно никогда, поверьте, нервы целее будут. И причины делать эту логику экстеншном к TextView нет никакой. Чем хуже textView.text = getDistanceString(distance)?
  • Context.showToast не имеет смысла, т.к. в студии даже live шаблон есть чтобы это не писать - напишите toast + Tab. А зачем передавать null в этот метод если с пустой строкой он не должен показываться - загадка.
  • Context.vibratePhone мог бы быть не экстеншном и не засорять неймспейс. В котлине всё ещё можно делать классы!
  • String?.htmlDecode. Экстеншны к стрингам, интам, и т. д. - это очень плохо, ничего так не засоряет неймспейс как это. А, вру, глобальные функции и переменные хуже.
  • EditText.onChange есть всё в том же androidx.core-ktx. Велосипед.
  • ImageView.setTint, Context.hasPermissions имеют место быть.
  • Конец.

Какие выводы можно сделать? (У автора в конце мысли правильные, но он этому сам не следует)

  • Добавление новых штуковин на глобальный уровень увеличивает сложность проекта и онбординг в него
  • Ситуации когда вместо отдельного класса хочется написать глобальный экстеншн - редкость.
  • Экстеншны к простейшим классам почти всегда плохая идея
  • В коробке уже многое есть.
  • Нужно стараться уменьшать скоуп, чтобы в любой момент времени приходилось помнить о меньшем количестве вещей
  • Из предыдущих пунктов можно вывести финальный - десять раз подумайте перед тем как писать глобальный экстеншн. То что у вас есть молоток - не значит что им нужно решать все