Как стать автором
Обновить

Комментарии 22

Это было тяжелое решение — на самом деле тут trade off между camelCase в xml и snake_case в котлин файлах. Мы выбрали второй вариант, хотя тут команда разбилась на два лагеря.

На самом деле — это вкусовщина.
Кстати можете форкнуть наш кодстайл на гитхабе и переписать часть под свою команду и привычки ;)

Если вспомните моменты, которые мы упустили то кидайте пулреквесты / issue

Ну и стаилгайды в общем вкусовщина. Имхо, camelCase в xml меньшее зло. И так пишут те же гугловцы. Например, Reto Mayer в одном видео так писал.

На счет описания ID у вас есть хорошие практики? При Java было удобно именовать ID по описанному в интернете принципу What-Where-Description (textview_authorization_password_hint). В Kotlin Android Extension такое именование выходит чересчур длинное, а дальше кто на что горазд. Как пример: tvPasswordHint, passwordHintTextView.
Мы используем следующее правило: Where-What-Description (fragment_authorization_text_view_password_hint), так оказывается удобнее, т.к. IDE при использовании Kotlin Android Extensions может предлагать все View проекты, которые как-то идентифицированы, а когда мы работаем в контексте AuthorizationFragment и хотим использовать какие-л. View мы заранее знаем с чего начать их писать что бы IDE предлагала более актуальный автокомплит
Не согласен с Вами, учитываю, что вы не объявляете нигде переменную вьюхи в коде, другой стиль именования делает её визуально отличной от остального кода, проще разобраться, сразу понятно что это вьюха и т.п

Как написал ниже yanex можно включить подсветку для них. А использовать в коде имена не по конвенции не очень хорошо.

Не знал, что можно настроить подсветку именно для Kotlin Android Extensions, спасибо!) К сожалению, комментария yanex еще не было, когда я писал свой (мой проходил модерацию)

Если более точно – названия синтетических свойств совпадают с идентификаторами View (для @+id/text_view будет text_view). Это консистентно с R.id.<id>, и дополнительный манглинг имён редко повышает читаемость кода.
Кстати, в Preferences → Color Scheme → Kotlin можно выбрать собственную подсветку для свойств Android Extensions.

вот кстати поэтому я именую id вьюх в lowCamelCase стиле, в IDE и так видно, что это вьюха среди других переменных. Именование с подчеркиванием напоминает устаревшие префиксы m и s, которые стали ненужны с появлением умных IDE с подсветкой.
А какая логика работы для вас была бы более приемлемой? Манглинг имён?

Я считаю абсолютно правильным то как сейчас сделано. То, что имена в файлах такие же как в xml.
И попробовав, считаю, что camelCase в лейаутах гораздо удобнее.

Так как мы рассматриваем класс как некоторый интерфейс, в первую очередь интересно узнать, что он делает — благодаря тому, что все приватные методы располагаются в самом конце, можно быстро понять ответственность этого класса по его интерфейсу.

Гораздо проще оценить интерфейс класса при помощи вкладки Structure (Cmd+7) и тогда не придется отрывать приватные методы от места их использования
Тут дело не только в интерфейсе, но и в структуре класса.

Мы рассматриваи следующие альтернативы:

  1. порядок по модификаторам
  2. порядок по регионам
  3. порядок не регламентируется

Вариант порядок по регионам слабо коррелирует с Single Responsibility из солид
Вариант порядок не регламентируется мы пробовали, но это было неудобно, особенно при переопределении методов ЖЦ Активити код был довольно разнородный и непредсказуемый

В итоге остановились на варианте с порядоком по модификаторам

Если надо оценить структуру типа в среде разработки, то да, проще.


Если смотреть на diff в пул-реквесте вне среды разработки в каком-нибудь веб интерфейсе, когда видны только изменённые строки и не очевидно, что вокруг, и когда идентификаторы, используемые в этих строках, определены где-то в другом месте, то хороший (или для начала хотя бы единообразный) кодстайл очень помогает.

Можете рассказать подробнее какого рода проекты были переписаны?

Интересно по поводу


Избегать использования Destrucion Declaration в лямбда-выражениях.

Были какие-то проблемы?

Это кажется более-менее очевидным.
Лямбды имеют тип со скобками, например (Int, Int) -> Int.
При этом записываются { x, y -> x + y }. Тут нормально желание поставить скобки вокруг аргументов { (x, y) -> x + y }. Но так сделать нельзя, потому что изменится тип лямбды — теперь она принимает аргумент, имеющий как минимум две компоненты, а скобки означают деструктуризацию.
Читать такой код, имхо, сложнее — сразу неочевидно, что происходит деструктуризация, как раз из-за того, что скобки вокруг аргументов, по идее, не должны ничего решать.

А если функция ничего не возвращает, но помещается в одну строку, то можно ее описывать как выражение? Например, так:
fun showMessage(message: String) = toast(message)
Это не противоречит правилу до тех пор пока функция с описанием умещается в 120 символов, на Ваш пример ответ – да.

да, такое ощущние, что вы прочитал Kotlin in action и сделали наоборот)) Ну ладно, действительно дело вкуса - главное чтобы все в вашей компании писали одинаково.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий