Kotlin Best Practices

[ITurchenko]

Здесь фактически значение null могло бы появиться только в том случае, когда animatedView равен null. Добавление простой проверки if (animatedView != null) избавит нас от цепочки безопасных вызовов. Но в данном примере вообще нет необходимости в том, чтобы animatedView принимало значение null. Поэтому лучше его сделать lateinit переменной, и тогда код вообще не будет содержать проверок на null

Конечно необходимости нет. Пока однажды не отстрелите себе ногу из-за того, что инициализация почему-то не прошла либо метод вызвался до инициализации.

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

lateinit не стоит бездумно лупить куда попало, обязательно нужно держать в голове порядок инициализации и использования переменной, иначе потом будет больное ой в виде UninitializedPropertyAccessException.

[mobileSimbirSoft]

Конечно, вы правы. Обязательно нужно учитывать то, в какие моменты может произойти обращение к переменной, прежде чем делать ее lateinit.

[Neikist]

А кроме этого lateinit переменные фрагмента для вью прекрасное место для утечки памяти. Как и вообще переменные фрагмента вью хранящие если им null не присваивать.

[mad_nazgul]

ИМХО по возможности лучше использовать «by lazy», вместо «lateinit». :-)

[zagayevskiy]

В данном случае by lazy не подходит точно так же как lateinit. Есть вариант написать свой делегат, который будет отпускать вьюху в соответствующем методе ЖЦ.

[Floydovich]

Спасибо за статью и за наглядные примеры.

[mobileSimbirSoft]

Мы рады, что эти примеры оказались для вас полезны)

[anegin]

запрет на использование префикса _ для теневых полей

А какие еще бывают варианты именования для backing properties?

[mobileSimbirSoft]

Для теневых полей можно использовать название в обычном формате, например, val state и private val currentState. Это скорее субъективное предпочтение, связанное с тем, что код с обилием символов _ может казаться «замусоренным». Кому-то наоборот больше нравится _ из-за краткости. Самое главное, чтобы в команде эти детали были согласованы и специалисты писали код проекта в одном стиле.

[anegin]

Да, мне самому не нравится _ в именах полей, но я пока не придумал как по-другому их называть, поэтому часто ViewModel состоит из таких конструкций, только из соображений инкапсуляции

private val _data = MutableLiveData<Data>()
val data: LiveData<Data> = _data