Переходя от комментирования и документации, что можно представить оберткой вокруг конфеты, называемой без метафор проектом, мы встречаем нужду в слое глазури, называемой стилизация кода.
Со стилизацией начинающие разработчики, как правило, сталкиваются на своем первом командном проекте, и этот опыт может либо привести к выводу: "Видимо, пока я писал свои тестовые проекты и приложения в одиночку, я делал это всё неправильно", - либо же к другому, практически диаметрально противоположному выводу: "Я же как то писал код раньше, и всё работало, так что, чтобы не терять в скорости, продолжу писать как писал".
Ожидаемо, что оба таких вывода в корне неверны. Неверны по-разному и приводят к разным последствиям. Сперва рассмотрим второй вывод, так как пояснение к первому будут понятнее с понимаем неверности второго.
Итак, уже полюбившийся нам по прошлой статье Альфредо пришел на проект разработки онлайн-биржи с командой из десяти разработчиков. Альфредо уже написал три приложения для App Store (два калькулятора и напоминалку, чтобы не забывать регулярно пить воду с электролитами). У приложений нет проблем с багами, написаны они крайне быстро, да и людям нравятся. Так почему успешному разработчику Альфредо нужно жертвовать скоростью и качеством своей разработки ради какого-то общего стиля?
Ответ кроется в ситуации, с которой началось его размышление: он пришел в команду из десяти человек. Десять разных человек, каждый из которых начинал писать код и делает это по-разному. Каждый имеет свои навыки и свои привычки в написании кода, что помогает и ускоряет его. Но в таких проектах самое главное к чему разработчику надо привыкнуть - он пишет код не для себя, а для других. Если Альфредо написал двести строк кода и помнит принцип их работы, то Саймон, который должен поменять поведение этого кода, кроме задачи внесения изменений будет иметь ещё одну задачу - понять, что вообще написал Альфредо и как оно работает. И, зачастую, именно эта задача может занять куда больше времени, чем само внесение изменений.
Здесь и появляется общий стиль. Общая структура и предсказуемость кода, наряду с его читаемостью крайне упрощает понимание написанного, сводя чтение кода к прохождению вдоль цепочки предсказуемых шагов. Также, общий стиль хоть и требует самоконтроля и подбора решения, по итогу приводит к упрощению, а иногда и переиспользованию решений, сделанных командой разработки.
Однако самоконтроль - дело субьективное и неблагодарное. Где-то не уследил, где-то понял стиль неверно и сделал наоборот, и как итог: код в первой половине понятен, а вторая половина походит на джунгли Амазонки.
В этом месте появляется наш герой-тиран - линтер. Линтер занимается выявлением отступлений от заданного стиля, возможные проблемы (как пример, строка кода длиной 200+), а также может выявлять неудачные практики в коде. Под контролем такого инструмента новички легко понимают требования стиля и привыкают соответствовать им, а гуру программирования не будут тратить время на проверку соответствия стилю кода.
Примеры линтеров для различных языков: SwiftLint для Swift, pylint для Python, ESLint для Javascript.
Линтер занимается не только отловом нарушений стиля, такие, как излишние пробелы или, например, принудительное извлечение переменных. Он также часто даёт рекомендации о предпочтении одного метода над другим. Например, SwiftLint заблокирует проверку:
array.count == 0Так как внутри Swift имеется способ проверки массива на отсутствие элементов, который оптимизирован для работы с большими массивами:
// returns Bool
array.isEmptyЛинтер хоть и тиран, но тиран управляемый. С помощью настроек, имеющихся в нем, можно смягчить некоторые правила или подправить под предпочтения команды. Главное, что после установки этих правил, многие вопросы по стилю решаются судьей, для которого код или соответствует, или нет.
И всё же в любом проекте бывают моменты, где без магического костыля, который нарушает даже правила мироздания, не создать очень важную часть приложения. В такие моменты тирана-линтера можно убедить не обращать внимания на некий сегмент кода или же пренебречь несколькими правилами, чтобы заставить всё работать.
Теперь можно вернуться к первому из двух выводов, что делают разработчики, знакомящиеся со стилизацией проекта - "Видимо, пока я писал свои тестовые проекты и приложения в одиночку, я делал это всё неправильно". Важно понимать, что стиль не некий ГОСТ, по которому должны быть написаны все приложения, а способ упрощения восприятия кода для команды. И чем меньше эта команда, тем, по факту, меньше смысла в соблюдении жесткой стилизации, и тем больше смысла появляется в написании кода в более быстром темпе, без соблюдения правил количества пробелов и иерархии файлов. Главное - ваш код должен быть таким, что если вы откроете его через год или два, то вы всё ещё сможете понять, как он устроен, и работать с ним.
Итак, время подведения очередных итогов. Стиль - очередной, хоть и неявный, инструмент для упрощения понимания и работы с кодовой базой вашего проекта. Для упрощения работы со стилем кода можно использовать линтеры, следящие за стилизацией и корректным использованием доступного функционала, но готовые закрыть глаза на особые случаи, когда другого выхода нет. И всё же, стиль - возможный инструмент, который надо применять тогда, когда его наличие позитивно повлияет на продуктивность команды разработки.
