Заметки:
- Выработайте набор правил форматирования и автоматизируйте их. Подтверждаю, что это просто потрясающе удобная штука. Например, не надо думать, назвать вьюшку в xml через camelCase или в стиле awesome_name.
- От стиля кода и удобочитаемости зависит будущее проекта, поэтому это максимально важно. Если с каждой фичой код будет усложняться и становиться еще запутанней, то в конечном итоге фича будет добавляться месяцами. Просто потому что разобраться в коде будет слишком сложно и вы будете тратить дни на исправление маленького бага.
- Маленькие файлы более понятны, чем большие (речь именно о файлах). Автор приводит пример, что существует много проектов, где типичная длина — 200 строк. К сожалению, лично мне не всегда получается этого придерживаться. В интеракторах еще норм, но в той же ViewModel часто бывает больше. Возможно, это знак, что слишком много логики и надо разделять.
- Файл должен читаться как хорошая газетная статья — удачное название, в начале завязка, потом разворачивание сюжета и финал. В коде аналогично — инициализация, потом — высокоуровневые концепции и алгоритмы. Детализация увеличивается по мере чтения кода и проматывания вниз. В самом конце низкий уровень.
- Разделяйте разные смысловые блоки пустыми строками. Например: инициализация, импорты, методы — между ними ставим пустую строку, потому что так легче читать.
- Не разделяйте один смысловой блок пробелами. Если мы инициализируем репозитории, то не ставьте между ними внезапную пустую строку. Разработчик сразу начнет думать, что в следующих репозиториях что-то особенное и они чем-то отличаются.
- Переменные стоит объявлять как можно ближе к месту использования. Если короткий метод — можно в самом начале.
- Переменные экземпляров надо объявлять в начале класса, потому что они используются в разных местах. Можете объявлять внизу или вверху — главное, знайте где и не смешивайте. Кстати, полезная практика, с которой я периодически путаюсь. Как пример: в прошлой команде было принято companion object писать вверху класса. А у нас — внизу.
- Если одна функция вызывает другую, то они должны находиться рядом. Вызывающая над вызываемой. Нисходящий порядок, чтобы сверху была самая важная информация. Так можно будет быстро прочитать и понять, не погружаясь в подробности.
- Тесно связанные концепции должны находиться рядом, чтобы при чтении не прыгать по разным местам.
- Концептуальное родство — такая штука, когда выполняют похожие действия. Например: assertTrue и assertFalse. Они должны находиться рядом.
- Строка должна быть максимально короткой. У автора лимит — 120 символов.
- Присваивания окружаем пробелами, чтобы была видна левая и правая части и они не сливались. Но скобки не окружаем пробелами, потому что функции тесно связаны со своими аргументами.
- Сами аргументы перечисляем с пробелами и запятыми, чтобы подчеркнуть, что они не зависят друг от друга.
- Никакого выравнивания. Это когда пишут так:
"private String name;". Не делайте так. При чтении внимание рассеивается и код становится сложнее воспринимать. - Если много перечислений и список большой, поэтому хочется вставить выравнивание и пробелы, то уменьшайте список.
- Команды уровня файла должны быть без отступов. Методы должны быть на один уровень справа от классов. Реализация методов еще на один уровень. Реализация блоков на один вправо от своего внешнего блока. Табы или пробелы — на ваш выбор. :)
- Лучше не сворачивать if, else, while и прочее в одну строку. С форматированием легче и быстрее читать.
- Если есть пусть while (любая другая операция), то все равно лучше написать пустые скобки, чтобы не создавалось ощущение, что дальнейший код принадлежит циклу.
- Определитесь командой, где расставляете фигурные скобки, каким будет размер отступов, по какой схеме имена классов и прочее. Задокументируйте и пользуйтесь этим. Никаких разных стиль. Только стиль группы.
