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

Я думаю, что Александр Поуп выразился лучше всех.

Ах, никогда не было так ужасно хвастаться Жажда славы,
И в Критике не позволяй Человеку погибнуть!
Добродушие и Разум всегда должны соединяться;
Ошибаться гуманно; Прощать, Боже.

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

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

Подчеркните это правилом

Уже существует множество существующих правил, которые вы должны использовать прямо сейчас. Если вы используете eslint, вы, вероятно, уже используете некоторые из этих правил, обычно используя eslint:recommended или airbnb. Большинству команд следует добавить свои собственные правила или использовать overrides, чтобы изменить или удалить airbnb / рекомендуемые правила, с которыми они не согласны.

Хороший подход к использованию при первом введении правил eslint - регулярное обсуждение их текущего использования и того, насколько хорошо они поддерживают стандарты вашего кода; правильно ли настроены параметры (какой уровень цикломатической сложности следует вы сочтете приемлемым? только ваша команда будет знать…), должны ли они быть предупреждениями или ошибками, и какие новые правила следует ввести, и какие возникают в пути и должны быть удалены. В конце концов, повторное посещение конфигурации eslint станет для вас редкостью.

Не нарушайте правила - создавайте свои

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

  • Селекторы AST
  • написание правильного правила eslint

Правила согласовываются в команде и строятся в команде.

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

Кроме того, что более важно, если за написание правил линтинга отвечает небольшое количество людей, виноват будут они, а не код - каким бы иррациональным это ни было!

Можно ли использовать фрагменты кода для обеспечения соблюдения стандартов?

Да, но нет.

Фрагменты кода хороши, но имеют ряд недостатков. Главный камень преткновения, на мой взгляд, - это аффорданс; разработчикам необходимо знать, что сниппеты есть, и им нужно знать, как их использовать.

Кроме того, это усугубляется тем фактом, что многие команды не требуют использования единой IDE. Например, моя команда использует смесь Webstorm, VS Code и Sublime. Накладные расходы на добавление, поддержание и документирование фрагментов кода для каждого из этих редакторов - это лишь дополнительные препятствия для принятия фрагментов кода.

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

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

Знать свое место

Короче говоря, чтобы облегчить вашу жизнь, сократить количество проверок кода (немного) и способствовать гармонии и доброжелательности в вашей команде (ну, возможно), позвольте правилам связать вас и преклонить колени перед властителями eslint!