Комментарии 22
Для полей View из Kotlin Android Extension используется стиль именования lower_snake_case
Печаль.
На самом деле — это вкусовщина.
Если вспомните моменты, которые мы упустили то кидайте пулреквесты / issue
Ну и стаилгайды в общем вкусовщина. Имхо, camelCase в xml меньшее зло. И так пишут те же гугловцы. Например, Reto Mayer в одном видео так писал.
Если более точно – названия синтетических свойств совпадают с идентификаторами View
(для @+id/text_view
будет text_view
). Это консистентно с R.id.<id>
, и дополнительный манглинг имён редко повышает читаемость кода.
Кстати, в Preferences → Color Scheme → Kotlin можно выбрать собственную подсветку для свойств Android Extensions.
Так как мы рассматриваем класс как некоторый интерфейс, в первую очередь интересно узнать, что он делает — благодаря тому, что все приватные методы располагаются в самом конце, можно быстро понять ответственность этого класса по его интерфейсу.
Гораздо проще оценить интерфейс класса при помощи вкладки Structure (Cmd+7) и тогда не придется отрывать приватные методы от места их использования
Мы рассматриваи следующие альтернативы:
- порядок по модификаторам
- порядок по регионам
- порядок не регламентируется
Вариант порядок по регионам слабо коррелирует с Single Responsibility из солид
Вариант порядок не регламентируется мы пробовали, но это было неудобно, особенно при переопределении методов ЖЦ Активити код был довольно разнородный и непредсказуемый
В итоге остановились на варианте с порядоком по модификаторам
Если надо оценить структуру типа в среде разработки, то да, проще.
Если смотреть на diff в пул-реквесте вне среды разработки в каком-нибудь веб интерфейсе, когда видны только изменённые строки и не очевидно, что вокруг, и когда идентификаторы, используемые в этих строках, определены где-то в другом месте, то хороший (или для начала хотя бы единообразный) кодстайл очень помогает.
Интересно по поводу
Избегать использования Destrucion Declaration в лямбда-выражениях.
Были какие-то проблемы?
Это кажется более-менее очевидным.
Лямбды имеют тип со скобками, например (Int, Int) -> Int.
При этом записываются { x, y -> x + y }. Тут нормально желание поставить скобки вокруг аргументов { (x, y) -> x + y }. Но так сделать нельзя, потому что изменится тип лямбды — теперь она принимает аргумент, имеющий как минимум две компоненты, а скобки означают деструктуризацию.
Читать такой код, имхо, сложнее — сразу неочевидно, что происходит деструктуризация, как раз из-за того, что скобки вокруг аргументов, по идее, не должны ничего решать.
fun showMessage(message: String) = toast(message)
да, такое ощущние, что вы прочитал Kotlin in action и сделали наоборот)) Ну ладно, действительно дело вкуса - главное чтобы все в вашей компании писали одинаково.
Kotlin code style