Мы используем cookie-файлы. Оставаясь на сайте роботов, человек соглашается на использование cookie-файлов.
Подробнее — в «Условиях использования cookie-файлов».

Код-стайл роботов для Kotlin

За полтора года работы с языком Kotlin, мы перевели на него все свои проекты и фреймворки. Чтобы разработчики могли быстрее включаться в работу над проектом, а код ревью не превращался в бесконечный спор, мы решили формализовать накопленный опыт и разработали собственный код-стайл.

Автор: Дмитрий Самарьян
Android-разработчик

Зачем

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

И даже если сейчас вы единственный разработчик на проекте, не забывайте — когда-нибудь это закончится. И только от вас зависит, будет ли новый человек в команде вам благодарен или первым делом попытается разузнать ваш адрес.Наличие единого стиля написания кода решает все эти проблемы.

Почему Kotlin

Kotlin довольно популярен в сообществе Android-разработчиков и с каждым днем собирает все больше сторонников. Но отыскать стиль написания кода, которым можно руководствоваться, по-прежнему проблема, а соглашения, опубликованные на официальном сайте языка не дают исчерпывающих ответов, так как то количество правил, которые там присутствуют, едва ли могут покрыть большинство потребностей команды. Например, не содержат правил форматирования функций, их вызов и описания.

Во время написания статьи вышел официальный гайд от Google с ответами на вопросы о написании кода на Kotlin, что в некоторой степени повлияло на статью. Нам было интересно сравнить результаты и проанализировать, в чем наши мнения сошлись и с чем мы оказались не согласны. При более внимательном просмотре заметно, что большинство правил Google взяты из их  же style guide по Java, мы же старались учитывать опыт и других смежных языков программирования, но в большей степени отталкивались от применения разных подходов к стилям, и как раз такой подход позволил нам раскрыть некоторые пункты (структуру класса, описание, вызов функций и другие правила).

Как закалялся стайл

Процесс выработки единого стиля, с которым была бы согласна такая большая команда как наша, не из простых: собрать идеи и предложения, учесть мнение каждого, вспомнить, какие моменты вызывают споры на код ревью. Ожидаемо, что единого вердикта по всем вопросам добиться будет практически нереально, но важно, чтобы все осознавали важность и пользу процесса, были готовы идти на уступки и соблюдать принятые решения. Каким должен быть код-стайл
— понятным каждому (почему мы решили так, а не иначе);
— не экстравагантным (чем проще ваш код, тем лучше);— покрывающим большинство ситуаций;
— в идеале не привязанным к внешним решениям (этот пункт мы нарушили, добавив в свой код-стайл Kotlin Android Extensions).

Конечно, с течением времени конкретный набор правил может пересматриваться и дополняться — мы планируем поддерживать свой набор соглашений в актуальном состоянии.

Что дальше

Даже после принятия единого стандарта написания кода могут возникать проблемы: кто-то может забыть правила, или что еще хуже – начать саботировать их. Хорошо, если этот код будет забракован на этапе code review, но проверяющий может не заметить этих ошибок или даже участвовать в подрывной деятельности. Несмотря на молодость Kotlin, для него уже существуют инструменты по статическому анализу кода, для которых имеется возможность описать все правила и отслеживать любое нарушение автоматически, что уже на подходе в нашем бэклоге.

Сервис поможет разработчикам быть более дисциплинированными и освободит Reviewer’а от необходимости проверять соответствие кода принятому стандарту, и тогда эти инструменты станут помощниками в поддержании чистоты на проекте.