Введение, сравнение популярных конфигураций и ресурсы
Что такое ЛИНТЕР?
Линтеры имеют долгую историю разработки программного обеспечения. Stephen C. Johnson (письма) разработал Lint во время отладки Yacc (еще один компилятор-компилятор), который был написан на языке программирования C в Bell Labs в 1978 году.
Подобно тому, как валик для ворса будет проходить по вашей одежде, удаляя нежелательную пыль, волосы и другие нежелательные предметы (например, лего), программный линтер просматривает ваш исходный код и анализирует его на предмет возможных ошибок, передовых методов и стилистических проблем. . Параметры конфигурации позволяют вам выбирать, какие ошибки выявлять, отмечать и, при желании, действовать. Линтер может автоматически исправить код, пометить проблемный код для проверки или ничего не делать.
Я буду использовать линтер ESLint, который представляет собой инструмент линтинга Javascript с открытым исходным кодом. Его используют длинный список компаний и организаций. Вы можете узнать больше о ESLint и их философии на их домашней странице.
Какие есть примеры правил?
Пример правила Возможная ошибка - no-debugger. Он обрабатывает ситуации, когда программист, отягощенный крайними сроками, мог забыть debugger оператор где-то в коде, который будет запущен в производство. Хотя код с оператором debugger откроется и может работать, это не оптимально. Если пользователь откроет в браузере консоль инструментов разработчика, они попадут в отладчик. Выбрав параметр error для этого правила, ESLint пометит блок кода с оператором debugger как ошибку:
// this code block will cause an error
function getUserName(user) {
debugger;
return user.name;
}
ESLint вернет список (пример: пример стильного вывода), содержащий список ошибок. У каждого будет номер строки, номер столбца, уровень severity (например, ошибка, предупреждение) и правило, которое было нарушено.
Примером передового опыта является no-fallthrough, запрещающее case операторы, которые неправильно используют break для предотвращения перехода от одного case оператора к другому.
// this code block will cause an error
switch (bird) {
case 'robin':
playRobinSong();
case 'bluejay':
playBluejaySong();
}
Интересным аспектом этого правила является разрешенный им необязательный аргумент с именем commentPattern. С помощью этой опции мы можем установить комментарий, который говорит ESLint игнорировать конкретный оператор switch.
Если мы используем commentPattern «разрешить провал» (разрешены регулярные выражения) в объекте параметра, то комментарий со значением «разрешить провал» будет разрешен для нарушения правила:
// optional setting for no-fallthrough rule
{ "commentPattern": "allow fallthrough" ]
// this code block will not show an error for case 1
switch(someVariable) {
case 1:
someFunction();
// allow fallthrough
case 2:
anotherFunction();
}
Затем у нас есть правила для переменных, которые связаны с объявлением переменных. Не все эти правила используются всеми компаниями и организациями. Например, Airbnb, Google и Standard JS имеют разные конфигурации и включают одни правила, а другие оставляют выключенными. Одно правило переменной, которое используют все три организации, а также собственная «рекомендуемая» базовая конфигурация ESLint - no-unused-vars.
Это правило сводит к минимуму оставление переменных, функций и параметров функций, которые фактически не используются в коде. Допустим, у нас есть переменная, объявленная как jpSaxe. . Есть четыре способа, которыми переменная может считаться «использованной».
- Когда вызывается как функция или создается:
// function called jpSaxe() // construct a new object new jpSaxe()
2. При чтении или сохранении в виде значения:
let ifTheWorld = jpSaxe;
3. При использовании в качестве параметра при вызове функции:
comeOverRight(jpSaxe);
4. При использовании внутри другой функции:
comeOverRight(()=> { jpSaxe(); });
Обратите внимание, что для этого правила доступны параметры. В конфигурации Airbnb по умолчанию есть необязательный параметр args after-used, в то время как остальные 3 используют none. Это позволяет вам детализировать и действительно указать поведение, которое вы хотите от ESLint.
Перейдем к стилистическим правилам, которые решают более эстетические вопросы. Здесь вы можете увидеть различные варианты выбора, которые сделают разные организации. Airbnb, безусловно, выбрал большинство правил из 4 самых популярных готовых конфигураций. За ним следует Standard JS, затем Google и, наконец, наименее упрямая, рекомендованная реализация ESLint. Фактически, в рекомендуемой конфигурации ESLint включено только одно стилистическое правило. Это также единственное правило, с которым согласны все четверо, no-mixed-spaces-and-tabs. Название говорит само за себя.
И, наконец, есть правила ESLint для ECMAScript 6. Эти правила могут быть такими же синтаксически незначительными, как arrow-spacing, который проверяет, есть ли правильный интервал вокруг стрелочной части стрелочной функции.
// default configuration (options) object{ "before": true, "after": true }// sample code() => {}; // OK()=> {}; // not OK// alternative configuration { "before": false, "after": true } // sample code() => {}; // not OK()=> {}; // OK
Эти правила также могут иметь более функциональное назначение, например, улучшение читаемости или ремонтопригодности кода. Одним из примеров является prefer-const, который проверяет, переназначена (изменена) ли переменная, объявленная с ключевым словом let, где-то в коде. Если нет, он сообщит вам об этом с помощью warning или error в зависимости от того, как вы настраиваете правило (0: выключено, 1: предупреждать, 2: ошибка).
Должен ли я использовать готовую конфигурацию или использовать свою?
Для начала я определенно рекомендую использовать готовую конфигурацию. Из того, что я читал, конфигурация Airbnb (npm) является самой популярной. Я не собираюсь изобретать велосипед здесь и рассказывать, как настроить ESLint, потому что есть несколько отличных руководств.
Полный список интеграций доступен на домашней странице ESLint, а затем есть эти сообщения в блоге с множеством полезной информации:
Для VS Code:
Для Atom:
Для Sublime:
Для Vim:
Для скобок:
Другие готовые конфигурации
После того, как вы познакомитесь с тем, как настроить свой ESLint для приема готовых конфигураций, вы, возможно, захотите изучить другие, менее популярные, чем Airbnb, такие как Google (npm) или Standard JS (веб-сайт). Также есть конфигурации от таких компаний, как Spotify (github), Netflix (github), Palantir (github), Naver (github), Walmart (github), а также некоторых людей, таких как Вес Бос ( Github) и Kent C Dodds (github).
Чем отличаются 4 самые популярные конфигурации?
В моем собственном поиске стиля, который мне кажется подходящим, я искал повсюду, чтобы сравнить правила ESLint, которые каждая конфигурация включала и выключала. Но я не мог найти ни одного. 😐 Сравнения, которые я нашел, в основном ограничивались тем, насколько популярна была конфигурация, как часто она обновлялась, и обобщениями об их различиях.
Чтобы исправить эту ситуацию, я потратил некоторое время на изучение различий и каталогизацию их в файле Markdown. Они доступны на гитхабе и в виде. Я надеюсь, что кто-то сочтет это полезным, так же, как я счел полезным покопаться в правилах ESLint, а также в общих передовых методах и стилях для написания кода Javascript. У меня также была возможность глубже изучить конкретные варианты, которые выбрали разные компании и организации, и лучше понять, почему этот выбор имеет или не имеет значения.
