Есть среди разработчиков такая спорная тема, как соглашения по разработке. Спорная она потому, что помогает делать код красивым, а программисты - люди в какой-то степени творческие, каждый со своими опытом, багажом знаний и любимыми книжками про качество кода. Поэтому представление о красоте у каждого из них своё.
В таких условиях, чтобы кодовая база не превратилась во что-то малопривлекательное, а работа работалась командой более продуктивно, команде нужно соглашение о разработке. Это необязательно должен быть документ на 200 страниц с описанием всего, вплоть до допустимого цвета обоев на рабочем столе разработчика. Достаточно пары-тройки десятков пунктов, умещающихся на листе формата А4 десятым кеглем.
Планирую написать несколько статей на эту тему, в которых - коротко рассказать о своём представлении о красоте и даже попытаться объяснить свою точку зрения. Речь будет идти о разработке вообще и на Котлине, в частности. Если у кого-нибудь появится желание подискутировать на эту тему - всегда пожалуйста.
Начнём.
1. Использовать соглашение о стиле кода, настроенное в ИДЕ по умолчанию. Пример для IntelliJ IDEA.
Почему? Потому что большинство котлинистов пишет код в ИДЕ. Потому что любое соглашение о разработке нужно с чего-то начинать и лучше делать это как можно более лениво. То есть так, чтобы от команды требовался минимум усилий по его соблюдению. Для этого нужны:
- подсветка синтаксиса,
- автоформатирование,
- авторефакторинг.
В ИДЕ всё это есть. Команде нужно только прийти к соглашению о том, какую ИДЕ использовать и сразу за неё будет решено 90% вопросов, связанных со стилем кода.
2. Использовать везде одинарный импорт, вместо '*'.
Потому что так нагляднее (и больше строк кода, за которые нам платят, да) и не нарвёмся на конфликт имён зависимостей из разных пакетов. Мелочь, но приятно.
3. Добавляем запятую в конце последнего параметра функции (trailing comma) для удобного просмотра истории в git.
Так, код
fun execute(
user: CurrentUser
) = FiltersResponse(user)
отличается от кода
fun execute(
user: CurrentUser,
) = FiltersResponse(user)
всего одной запятой.
Но при добавлении ещё одного параметра в эту функцию, git в первом случае покажет, что вы изменили две строки, а во втором - одну строку. В первом случае, через какое-то время, ваш коллега или вы сами вынуждены будете лезть в историю коммитов, чтобы понять:
- какие и зачем изменения первого параметра вы сделали, если нужно было всего лишь добавить второй параметр,
- кто и в рамках какой задачи добавил первый параметр.
Продолжение следует...