Frontender Magazine

Почему стиль кода имеет значение

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

Если вы вдруг пропустили нужные комментарии или даже ошиблись в написании слова в паре комментариев, он вычитал баллы. Если ваш код был «неопрятным» (по его стандартам), он вычитал баллы. Его посыл был ясен: качество кода не только в том, как он запускается, но и в том, как он выглядит. Тогда я впервые столкнулся со стилем кода.

А что вообще такое, стиль?

Стиль кода — это то, как ваш код выглядит, вот так просто. И говоря «ваш», я имею в виду именно вас, того человека, который сейчас читает эту статью. Стиль кода — вещь очень личная, и у каждого есть свой излюбленный стиль. Вы можете прочувствовать свой личный стиль, изучив код, который вы же и написали когда не придерживались определенного руководства по стилю. У каждого свой собственный стиль, зависящий от того, кто как учился программированию. Если вы использовали интегрированную среду разработки (IDE) вроде Visual Studio для обучения, ваш стиль, возможно, совпадает с тем, который навязан редактором. Если вы учились используя обычный тектовый редактор, ваш стиль, вероятно, развился из того, что вы считали более читаемым.

Руководство по стилю

Руководства по стилю нужны не только издательским домам. Если вы хотите, чтобы код можно было по прежнему легко читать и редактировать даже после нескольких лет после того, как вы закончили проект, руководство по стилю полезно и необходимо. (Автор изображения Wikidave)

Вы даже можете заметить, что ваш стиль меняется от языка к языку. Решения, которые вы принимаете в JavaScript, могут не распространяться на ваш CSS. К примеру, вы можете решить, что в JavaScript строки должны быть в двойных кавычках, а в CSS следует использовать одинарные. В этом нет ничего необычного, мы склонны к переключению контекста в то время как переключаемся взад-вперед между языками. Но всё же, это интересное упражнение по самонаблюдению.

Стиль кода создается из множества маленьких решений в зависимости от языка:

Этот список ни в коем случае не полон, стиль кода может быть чрезвычайно подробным, таким как руководство по стилю JavaScript от Google, или более общим, вроде рекомендаций по стилю ядра jQuery.

Это личное

Личный характер стиля кода в условиях командной работы превращается в испытание. Зачастую, избегая долгих рассуждений, команды откладывают создание руководства по стилю в долгий ящик под предлогом того, что они не хотят «препятствовать инновациям и выражениям». Кто-то видит в командных руководствах по стилю принуждение всех разработчиков быть одинаковыми. Кто-то из разработчиков возмущается, когда им предлагают руководства по стилю, дескать, они не могут нормально работать, если кто-то будет говорить им, как писать код.

Ситуация примерно такая же, как если бы несколько музыкантов собирали группу. Каждый свято уверен, что их способ делать вещи непременно самый лучший (их «метод» или «процесс»). В группе будут неурядицы пока все будут пытаться делать всё по-своему. Невозможно играть хорошую музыку, пока все в группе не согласятся насчет темпа, стиля и того, кто будет задавать ритм. Всякий, кто слышал хоть раз группу из старшеклассников, знает, это правда. Пока все не окажутся на одной волне, ничего путного не выйдет.

Вот почему я настоятельно рекомендую руководства по стилю для команд разработчиков ПО. Настраиваться на одну волну сложно, и руководство по стилю — отличное начало. Если все будут писать код, который выглядит одинаково, это убережёт от множества проблем впоследствии.

Взаимодействие — ключевой момент

«Программы должны писаться для того, чтобы их читали люди, и лишь во вторую очередь для выполнения машиной.» — Х. Абельсон, Дж. Сассман («Структура и интерпретация компьютерных программ»)

Самая важная вещь при работе в команде — взаимодействие. Людям нужна возможность работать вместе эффективно, и единственный способ добиться этого — взаимодействие. Как разработчики мы взаимодействуем в первую очередь через код. Мы взаимодействуем с другими частями программы при помощи кода, и мы взаимодействум с другими разработчиками при помощи кода.

В то время как программному обеспечению, с которым взаимодействует ваш код, наплевать на то, как код выглядит, другим разработчикам в вашей команде определённо не всё равно. То, как код выглядит, влияет на то, как мы его понимаем. Сколько раз вы открывали кусок чужого кода и, прежде чем работать с ним, правили отступы так, как вам удобно? Это ваш мозг неспособен воспринять код из-за того, как он выглядит. Когда все пишут код, который выглядит по-разному, все постоянно пытаются визуально распознать код, прежде чем поймут его. Когда все пишут одинаково, ваш мозг может немного расслабиться, и понимание приходит быстрее.

BBC GEL

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

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

Мне недавно пришло письмо от кого-то, кто работал над кодом, который я написал 10 лет назад. Очевидно, к моему удивлению и ужасу, мой код до сих пор используется в продукте. Он счёл необходимым послать мне письмо и рассказать, что ему нравится работать с моим кодом. Я улыбнулся. Мой коллега из будущего высоко оценил стиль моего кода.

Оставляйте себе подсказки

«Если вы знаете своих врагов и знаете самого себя, вам не стоит опасаться и сотни битв» — Сунь-цзы («Военное искусство»)

Знание самого себя очень важно в жизни и в программировании. Однако невозможно знать себя настолько, чтобы помнить, о чём конкретно вы думали когда писали каждую строчку кода. Большинство разработчиков сталкивалось с тем, что рассматривая свои давнишние куски кода, они не понимали, зачем их написали. Это не потому что ваша память плохая, это из-за множества маленьких решений, принятых во время написания, за которыми просто невозможно уследить.

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

Как однажды сказал Крис Эпштейн, будьте добры по отношению к будущему самому себе.

Делайте ошибки очевидными

Одна из главных причин иметь ясное руководство по стилю — возможность сделать ошибки более очевидными. Руководства по стилю делают это приучая разработчиков к определённым паттернам. А когда вы привыкли, незнакомые паттерны в коде сразу бросаются в глаза. Незнакомые паттерны не обязательно ошибки, но они определённо требуют более пристального исследования, чтобы убедиться в том, что всё в порядке.

Например, рассмотрим конструкцию switch в JavaScript. Распространённая ошибка в том, что случайно один case проваливается в другой, как тут:

switch(value) {
    case 1:
        doSomething();

    case 2:
        doSomethingElse();
        break;

    default:
        doDefaultThing();
}

Первый case проваливается во второй, так что если value равно 1, то выполнятся и doSomething(), и doSomethingElse(). Возникает вопрос: а нет ли тут ошибки? Возможно, что разработчик забыл поставить break в первом case, но ровно настолько же вероятно, что так оно и задумывалось, и case должен проваливаться. Глядя на код, это сказать наверняка не получится.

А теперь представим, что у нас есть руководство по стилю JavaScript, и в нём значится следующее:

«Все case в конструкции switch должны заканчиваться break, throw, return или комментарием, указывающим на то, что он проваливается.»

В соответсвии с таким руководством, тут явно присутствует стилистическая ошибка, а значит, что возможно есть и логическая ошибка. Если ожидается, что первый case проваливается во второй, код выглядел бы так:

switch(value) {
    case 1:
        doSomething();
        //falls through

    case 2:
        doSomethingElse();
        break;

    default:
        doDefaultThing();
}

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

Если вы используете руководство по стилю, невинно выглядящий код сразу же обращает на себя внимание, потому как не соблюдается стиль. Это одно из самых недооценённых преимуществ руководств по стилю, ведь определяя, как должен выглядеть правильный код, вы можете гораздо легче распознать неправильный код, а значит, и потенциальные баги до того, как они проявятся.

Дьявол кроется в деталях

Когда я со своими клиентами занимаюсь разработкой для них руководств по стилю, меня часто спрашивают, действительно ли так важна мелочёвка. Обычный вопрос: «А разве это не те незначительные мелочи, которые ничего толком не значат?» Ответ и да, и нет. Да, стиль кода ничего не значит для компьютера, на котором он выполняется; нет, мелкие детали много значат для разработчиков, которым нужно поддерживать код. Считайте так: одна опечатка в книге не испортит понимание рассказа и удовольствие от него. Но если опечаток много, впечатление от чтения быстро испортится по мере того, как вы будете расшифровывать то, что автор имел в виду, из слов, которые напечатаны.

Стиль кода в этом отношении очень похож. Вы определяете эквиваленты правописания и грамматики, обязательные для всех. Ваше руководство по стилю может оказаться довольно многословным, в зависимости от того, на каких аспектах языка вы хотите заострить внимание. По моему опыту, стоит команде начать разрабатывать собственное руководство по стилю, как они углубляются дальше и дальше в детали, потому что это помогает им организовать и понять тот код, который у них уже имеется.

Порядок в коде

В искусстве числа обычно хаотичны и служат для декоративных целей. Но в вашем коде вам нужен порядок. (Автор изображения Alexflx54)

Я ещё не видел руководства по стилю, которое было бы излишне насыщено деталями, но я видел такие, в которых деталей слишком мало. Поэтому для команды важно разрабатывать стиль сообща. Если собрать всех в одной комнате с целью обсудить то, что действительно важно для команды, то это станет хорошей основой для создания руководства по стилю. И имейте в виду, руководство по стилю должно развиваться. Оно должно продолжать расти по мере того, как члены команды становятся всё более знакомыми друг с другом и с программой, над которой они работают.

Полезные утилиты

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

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

Заключение

Руководства по стилю кода — важная часть написания кода профессионалами. Неважно, пишете ли вы на JavaScript, CSS, или каком другом языке, решение насчёт того, как должен выглядеть код — это важная часть общего качества кода. Если у вас ещё нет руководства по стилю, начните его создавать, это стоит затраченного времени. Есть немало готовых руководств по стилю доступных в интернете, с изучения которых вы могли бы начать. Вот несколько из них:

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

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом Антону Немцеву в skype ravencry.

Nicholas C. Zakas
Автор:
Nicholas C. Zakas
Twitter:
@slicknet
Сaйт:
http://www.nczonline.net/
GitHub:
nzakas
Антон Хлыновский
Переводчик:
Антон Хлыновский
GitHub:
subzey
Twitter:
@subzey

Комментарии (3 комментария, если быть точным)

Автар пользователя
radist2s

Еще хотел бы посоветовать годный js-style-guide без чепухи - https://github.com/airbnb/javascript и перевод к нему - https://github.com/uprock/javascript

Автар пользователя
dsheiko

В список утилит можно добавить https://github.com/dsheiko/jscodesniffer и соответственно задача Grunt https://github.com/dsheiko/grunt-jscs

Автар пользователя
spamforhope

https://github.com/mdevils/node-jscs