Как исправить ошибки линтера

Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

System.out.println("alala

|  Error:
|  unclosed string literal
|  System.out.println("alala

System.out.println( "Hello, World!" ); System.out.println("I'm a developer!") ;

System.out.println("Hello, World!");
System.out.println("I'm a developer!");

Разрешение сообщений линтера документации

В этой теме описаны различные способы разрешения распространенных сообщений,которые выдает линтер документации.

Анатомия сообщения линтера документации

Это пример сообщения,выдаваемого линтером документации.

Линтерное сообщение документации содержит следующие элементы.Начиная с верхней строки:

• Серьезность.Один из этих значков указывает на серьезность сообщения:
• Сообщение правила стиля. Сообщение правила стиля в этом примере: Вы действительно имели в виду ‘sdfdsfsdfdfssd’? В нашем словаре его не было.
• Ссылка на стиль. Некоторые ссылки связаны с разделом руководства по стилю, в котором объясняется правило. Ссылка на стиль в этом примере: Vale(Angular.Angular_Spelling) .
• Расположение проблемного текста в документе определяется исходной строкой и столбцом как можно точнее. В некоторых сообщениях может не быть точного местоположения текста, вызвавшего сообщение. Расположение в этом примере: [Ln 8, Col 1] .
• Файл определения теста стиля, создавший сообщение, связанное с файлом. Определение теста стиля в этом примере: Angular_Spelling.yml[Ln 1, Col 1]: View rule .

Стратегии улучшения документации

Эти советы помогут вам улучшить документацию и удалить сообщения об ошибках в документации.

Обратитесь к руководствам по стилю

Инструмент lint проверяет стили,содержащиеся в этих руководствах по стилю.Большинство тестов стиля включают ссылки на соответствующие разделы этих документов для получения дополнительной информации.

• Руководство по стилю угловой документации
• Руководство по стилю документации для разработчиков Google

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

Разделяйте длинные предложения

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

Подумайте о том,чтобы перестроить длинное предложение и разбить отдельные идеи на отдельные предложения или пункты.

Используйте списки и таблицы

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

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

Используйте более распространенные слова

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

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

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

Используйте меньше слов

Если вы можете убрать слово и не потерять смысл предложения,оставьте его.

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

Подробнее о конкретных сообщениях линтера документации

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

Слово too-wordy или должно быть заменено другим

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

Angular.WriteGood_TooWordy-Проверьте,сможете ли вы переписать предложение…

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

В следующей таблице приведены некоторые распространенные слова,обнаруживаемые этим типом сообщений,и более простые слова,которые можно попробовать вместо них.

WordList messages

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

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

Proselint messages

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

Перепишите текст,заменив жаргонные или оскорбительные выражения на более инклюзивные.

Starting a sentence сообщения предложения

Некоторые слова, такие как so и there is/are , не обязательны в начале предложения. Предложения, которые начинаются со слов, обозначенных этим сообщением, обычно можно сделать короче, проще и яснее, переписав их без этих окончаний.

Cliches

Клише следует заменить более буквальным текстом.

Клише затрудняют понимание документации людьми,не понимающими английский язык.Когда клише переводятся онлайн-инструментами,такими как Google translate,они могут привести к запутанным результатам.

Если все остальное не помогает

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

Линтер документации проверяет только то содержимое,которое отображается как текст.Он не проверяет текст,отформатированный в виде кода.Одним из распространенных источников ложных проблем являются ссылки на код,которые не отформатированы как код.

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

При необходимости вы можете применить эти исключения к своему контенту.

1. General exception

   Общее исключение позволяет исключить указанный текст из всех проверок на ворсинки.

   Чтобы применить общее исключение, окружите текст, который вы не хотите, чтобы линтер тестировал, элементами comment HTML , показанными в этом примере.

   Text the linter does not check for any style problem.
   
   

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

2. Style exception

   Исключение стиля позволяет исключить текст из отдельного теста стиля.

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

   Замените Style.Rule в комментариях ссылкой на правило стиля из сообщения о проблеме, отображаемого в среде IDE. Например, представьте, что вы получили это сообщение о проблеме и хотите использовать слово, обозначенное как проблема.

   Did you really mean 
   Angular_Spelling.yml[Ln 1, Col 1]: View rule

   Style.Rule для этого сообщения — это текст в круглых скобках: Angular.Angular_Spelling данном случае Style.Rule Чтобы отключить этот тест стиля, используйте комментарии, показанные в этом примере. Angular.Angular_Spelling

   'inlines' does not display a problem because this text is not spell-checked.
   Remember that the linter does not check any spelling in this block of text.
   The linter continues to test all other style rules.
   
   

Angular

15.0

Руководства для разработчиков Angular

Как фреймворк для приложений,Angular включает в себя коллекцию хорошо интегрированных библиотек,которые охватывают широкий спектр возможностей.

DevTools Overview

Angular DevTools-это расширение для браузера,которое предоставляет возможности отладки и профилирования приложений.

Руководство по стилю угловой документации

Это руководство по стилю охватывает стандарты написания документации по Angular angular.io.

Отображение части файла кода

Чтобы включить фрагмент кода в образец файла, а не целиком, используйте атрибут региона <code-example>.

Поскольку JavaScript — это интерпретируемый язык, ошибки, допущенные в коде, выявляются во время его выполнения. Чтобы увидеть ошибки до запуска кода, используется инструмент, который называется линтер. Для поиска ошибок применяется статический анализ и используются особые правила.

Что такое ESLint

ESLint — это инструмент для поиска и исправления ошибок в коде JavaScript и ECMAScript. Он находит синтаксические ошибки, проблемы в шаблонах проектирования и отклонения от стиля. Наряду с большим количеством встроенных правил в нем можно использовать собственные правила или готовые плагины с правилами. Благодаря модульной структуре и множеству возможностей настройки можно настроить ESLint именно так, как нужно для вашего проекта.

Как работать с ESLint: шаг за шагом

Перед установкой ESLint нужно установить Node.js с поддержкой SSL и npm. Предположим, что вы уже сделали это заранее.

Для начала создайте каталог для проекта и поместите в него файл index.js с таким содержимым:

let i = 0;
do {
    alert( i );
    i++;

} while (true);

Затем инициализируйте npm в этом каталоге, если еще этого не сделали:

npm init

В результате будет создан файл package.json с параметрами пакета.

Установите ESLint в каталоге проекта. Для этого запустите в терминале следующую команду:

npm install eslint --save-dev

ESLint будет установлен локально. Существует возможность глобальной установки (с помощью команды npm install eslint --global), но не рекомендуем использовать такой подход. Все модули и совместно используемые файлы конфигурации в любом случае следует устанавливать локально.

Для настройки файла конфигурации выполните следующую команду:

npx eslint --init

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

Укажем, что будут использованы модули JavaScript:

В примере мы не используем ни React, ни Vue.js, ни TypeScript:

Предположим, код будет выполняться в браузере:

Укажем, что будем применять инструкции по стилю и выберем Airbnb:

Пусть файл конфигурации будет создан в формате JSON:

Установим зависимости:

В результате в каталоге проекта будет создан файл .eslintrc.json (или с другим расширением — в зависимости от выбранного вами формата).

В нем будет находиться примерно такой код:

module.exports = {
    'env': {
        'browser': true,
        'es2021': true
    },
    'extends': 'eslint:recommended',
    'parserOptions': {
        'ecmaVersion': 12,
        'sourceType': 'module'
    },
    'rules': {
    }
};

Проверяем проект

Теперь можно проверить проект, вызвав линтер для какого-либо файла или каталога. Вызовем eslint, передав в качестве аргумента текущий каталог (обозначенный точкой): node_modules.bineslint .

В результате получим:

Мы видим четыре ошибки и два предупреждения с указанием их позиций в файле. Также в таблице приведены описания и указаны нарушенные правила.

В сообщении указано, что три ошибки можно исправить, указав опцию --fix. Давайте так и сделаем: введем ту же команду и укажем эту опцию:

node_modules.bineslint . --fix

Вывод будет таким:

Видим, что линтер сам справился с тремя ошибками, а нам оставил остальные. Код в файле изменен:

let i = 0;
do {
    alert(i);
    i++;

} while (true);

Обратите внимание: вставлен символ новой строки и убраны пробелы в скобках.

Rules: правила проверки кода

В конфигурации примера выше мы использовали имеющиеся правила проверки. Но можно добавить и свои правила. В файле .eslintrc.json есть раздел rules.

Если при создании проекта указать не имеющийся набор инструкций, а задать свои правила (выбрав пункт Answer questins about your style), то в разделе правил в файле .eslintrc.json можно будет увидеть примерно такие правила:

'rules': {
        'indent': [
            'error',
            4
        ],
        'linebreak-style': [
            'error',
            'unix'
        ],
        'quotes': [
            'error',
            'single'
        ],
        'semi': [
            'error',
            'always'
 ]
    }

Структура правила проста. Рассмотрим первое правило из приведенного выше примера.

Слово indent — это имя правила. Первый элемент в списке обозначает уровень ошибки и может принимать следующие значения:

• off или 0 — выключить правило;
• warn или 1 — включить правило как предупреждение (не влияет на код выхода);
• error или 2 — включить правило как ошибку (с кодом выхода 1).

Второй элемент в этом случае означает количество пробелов. Второй аргумент зависит от правила.

Итак, приведенные выше правила указывают, что следует использовать отступ в четыре пробела, завершение строк в стиле UNIX, одинарные кавычки и не пропускать точку с запятой.

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

• getter-return (обязательное применение оператора возврата в методах чтения);
• no-setter-return (запрет применения оператора возврата в методах изменения значения);
• no-dupe-args (запрет дублирующихся аргументов в определениях функций).

Есть правила проверки соблюдения передовой практики, например, accessor-pairs (обязательное применение пар методов чтения и изменения значений в объектах и классах).

Правила относительно переменных (no-unused-vars — запрет на неиспользуемые переменные), стилистические правила (eol-last — разрешение или запрет символа новой строки в конце файла) и правила для ECMAScript 6.

Вернемся к коду, немного изменим файл index.js и отправим его на проверку:

let i = 0
do {
    alert("Loop " + i);
    i++;

} while (true);

Будут выданы такие сообщения об ошибках:

Здесь сообщается, что пропущена точка с запятой, используется отступ в два пробела вместо четырех и двойные кавычки вместо одинарных, а в цикле использовано константное условие.

Полный список правил ESLint можно просмотреть по этой ссылке.

Чтобы не вводить одни и те же команды каждый раз, можно в разделе scripts в файле package.json указать сценарий для запуска eslint. Он может выглядеть так:

"scripts": {

    "lint": "eslint . --fix"

  },

Вывод будет примерно таким:

Эти сообщения об ошибках можно проигнорировать.

Проверку можно отключать как для отдельных строк, так и для нескольких.

Для отключения отдельной строки ее нужно завершить комментарием:

// eslint-disable-line

Чтобы отключить проверку для нескольких строк, перед ними следует вставить комментарий /* eslint-disable */, а после — /* eslint-enable */:

let i = 0;

do {

    alert('Loop ' + i);

    i++;

/* eslint-disable */

} while (true);

/* eslint-enable */

Также можно отключить одно или несколько конкретных правил. Для этого в комментарии /* eslint-disable */ их перечисляют через запятую:

/* eslint-disable semi, quotes */

Заключение

ESLint — эффективный инструмент, который можно настраивать и расширять в соответствии с потребностями разных проектов.

ESLint продолжает активно развиваться и интегрируется с Sublime Text 3, Vim, Visual Studio Code, IntelliJ IDEA, Emacs, Eclipse и многими другими средами разработки.

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

Поскольку JavaScript — это интерпретируемый язык, ошибки, допущенные в коде, выявляются во время его выполнения. Чтобы увидеть ошибки до запуска кода, используется инструмент, который называется линтер. Для поиска ошибок применяется статический анализ кода и используются особые правила.

Файл конфигурации eslint

Перед установкой расширения «ESLint» устанавливаем пакет eslint — локально (рекомендуется) или глобально (не рекомендуется). Расширение будет сначала искать локальный пакет, а в случае неудачи — глобальный.

$ npm install eslint --save-dev # локальная установка

$ npm install eslint --global # глобальная установка

После установки расширения создаем файл конфигурации с правилами проверки кода:

$ npx eslint --init # если пакет установлен локально

$ eslint --init # если пакет установлен глобально

How would you like to use ESLint?
    To check syntax only
    To check syntax and find problems √
    To check syntax, find problems, and enforce code style
What type of modules does your project use?
    JavaScript modules (import/export) √
    CommonJS (require/exports)</li>
    None of these
Which framework does your project use?
    React
    Vue.js
    None of these √
Does your project use TypeScript? No / Yes
Where does your code run?
    Browser √
    Node.js √
What format do you want your config file to be in?
    JavaScript
    YAML
    JSON √

После этого будет создан json-файл конфигурации .eslintrc.json:

{
    "env": { // предоставляет предопределенные глобальные переменные
        "browser": true,
        "es2021": true,
        "node": true
    },
    "extends": "eslint:recommended", // рекомендуемый набор правил
    "parserOptions": {
        // версия синтаксиса ECMAScript: 5 (по умолчанию), 6 (или 2015), ..., 12 (2021), 13 (2022)
        "ecmaVersion": "latest",
        // script (значение по умолчанию) или module (если используются модули ECMAScript)
        "sourceType": "module"
    },
    "rules": {
        // можно переопределять recommended правила и добавлять правила, которых нет в recommended
    }
}

Если выбрать js-формат файла конфигурации — получим .eslintrc.js:

module.exports = {
    env: {
        browser: true,
        es2021: true,
        node: true,
    },
    extends: 'eslint:recommended',
    parserOptions: {
        ecmaVersion: 'latest',
        sourceType: 'module',
    },
    rules: {},
}

Рекомендуемый набор правил eslint:recommended выгллядит следующим образом:

{
"constructor-super": "error", // проверка вызова super() в конструкторе
"for-direction": "error", // проверка цикла for на конечное число итераций
"getter-return": "error", // требовать return в getter
"no-async-promise-executor": "error", // запрет async функции-исполнителя в Promise
"no-case-declarations": "error", // запрет объявления переменных, функций и классов в case
"no-class-assign": "error", // class A {} — запрет на приваивание нового значения A
"no-compare-neg-zero": "error", // запрет на сравнение x === -0
"no-cond-assign": "error", // запрет на присваивание в условиях
"no-const-assign": "error", // запрет на изменение константы
"no-constant-condition": "error", // запрет на константу в условии
"no-control-regex": "error", // запрет на упр.символы в регулярках (ASCII от 0 до 31)
"no-debugger": "error", // запрет на использование debugger
"no-delete-var": "error", // запрет на использование delete с переменной
"no-dupe-args": "error", // запрет одинаковых параметров в объявлений ф-ции
"no-dupe-class-members": "error", // запрет повторяющихся членов класса
"no-dupe-else-if": "error", // запрет повторяющихся условий в цепочках if-else-if
"no-dupe-keys": "error", // запрет повторяющихся ключей в литералах объектов
"no-duplicate-case": "error", // запрет повторяющихся значений case
"no-empty": "error", // запрет пустых блоков кода — if(…) {пусто}
"no-empty-character-class": "error", // запрет на пустые символьные классы [] в регулярках
"no-empty-pattern": "error", // запрет пустых шаблонов деструктурирования let {} = foo
"no-ex-assign": "error", // запрет переназначения err в catch — try {…} catch (err) {err = 1}
"no-extra-boolean-cast": "error", // запрет лишних логических приведений — if (!!a) {…}
"no-extra-semi": "error", // запрет лишних точек с запятой — let x = 5;;
"no-fallthrough": "error", // запрет case без break и без комментария «fall through»
"no-func-assign": "error", // запрет переназначения объявления function
"no-global-assign": "error", // запрет переназначения глобальных переменных — window = {}
"no-import-assign": "error", // запрет переназначения импорта — import a from …; a = 1
"no-inner-declarations": "error", // запрет объявления ф-ций и переменных внутри блоков кода
"no-invalid-regexp": "error", // запрет недопустимых строк регулярных выражений в RegExp()
"no-irregular-whitespace": "error", // запрет неправильных пробельных символов
"no-loss-of-precision": "error", // запрет литеральных чисел, которые теряют точность
"no-misleading-character-class": "error", // запрет проблемных регулярных выражений
"no-mixed-spaces-and-tabs": "error", // запрет смешанных отступов из пробелов и табуляций
"no-new-symbol": "error", // запрет new Symbol()
"no-nonoctal-decimal-escape": "error", // запрет 8 и 9 в строковых литералах
"no-obj-calls": "error", // запрет вызова свойств глобального объекта как функций — Math()
"no-octal": "error", // запрет восьмеричных литералов — x = 071 (теперь х равен 57)
"no-prototype-builtins": "error", // запрет вызова некоторых методов прототипа на объекте
"no-redeclare": "error", // запрет повторного объявления переменной
"no-regex-spaces": "error", // запрет использования нескольких пробелов в регулярках
"no-self-assign": "error", // запрет присваивания переменной самой себе — x = x
"no-setter-return": "error", // // запрет на return в setter
"no-shadow-restricted-names": "error", // запрет имен переменных и ф-ций типа NaN, undefined
"no-sparse-arrays": "error", // запрет разреженных массивов
"no-this-before-super": "error", // запрет в конструкторе использовать this до вызова super()
"no-undef": "error", // запрет на использование необъявленных переменных
"no-unexpected-multiline": "error", // запрет запутанных многострочных выражений
"no-unreachable": "error", // запрет недостижимого кода после return, throw, continue и break
"no-unsafe-finally": "error", // запрет return, throw, break и continue внутри блока finally
"no-unsafe-negation": "error", // запрет отрицания левого операнда в операторах отношения
"no-unsafe-optional-chaining": "error", // запрет использования foo?.bar в некоторых ситуациях
"no-unused-labels": "error", // запрет неиспользуемых меток
"no-unused-vars": "error", // запрет неиспользуемых переменных
"no-useless-backreference": "error", // запрет бесполезных обратных ссылок в регулярках
"no-useless-catch": "error", // запрет ненужных catch
"no-useless-escape": "error", // запрет ненужных escape-символов
"no-with": "error", // запрет использования with
"require-yield": "error", // требовать yield для функции-генератора
"use-isnan": "error", // требовать isNaN() для проверки NaN
"valid-typeof": "error" // требовать для typeof допустимых строк "string", "undefined", "object"
}

Давайте добавим в файл конфигурации еще несколько правил:

{
"env": {
"browser": true,
"es2021": true,
"node": true
},
"extends": "eslint:recommended",
"parserOptions": {
"ecmaVersion": "latest",
"sourceType": "module"
},
"rules": {
"linebreak-style": ["error", "unix"], // символ(ы) конца строки
"quotes": ["error", "single"], // использовать одинарные кавычки
"semi": ["error", "never"], // точка с запятой в конце операторов
"indent": ["error", 4, { "SwitchCase": 1 }], // отступы в коде из 4 пробелов с учетом switch...case
"arrow-parens": ["error", "as-needed"], // скобки вокруг единственного параметра стрелочной функции
"object-curly-spacing": ["error", "always"], // пробелы между скобками в литералах объектов
"array-bracket-spacing": ["error", "never"], // пробелы между скобками в массивах
"quote-props": ["error", "as-needed"], // свойства объекта в кавычках или без кавычек
"no-trailing-spaces": "error", // не должно быть пробелов в конце строки
"no-tabs": "error", // символы табуляции в коде запрещена везде
"comma-dangle": ["error", { // запятая после последнего элемента массива или объекта
"arrays": "always-multiline",
"objects": "always-multiline",
"imports": "never",
"exports": "never",
"functions": "never"
}],
"brace-style": ["error", "1tbs"], // правила для фигурных скобкок для блоков кода
"keyword-spacing": "error", // пробел слева и справа для ключевых слов
"no-multi-spaces": "error", // не допускается несколько пробелов подряд
"eqeqeq": "error", // использовать === и !== вместо == и !=
"camelcase": "error", // имена переменных и функций в стиле camelCase
"max-len": ["error", 100], // максимальная длина строки
"no-multiple-empty-lines": "error" // не больше 2 пустых строк подряд
}
}

Внутри rules можно не только добавлять новые правила, но и переопределять правила, заданные в наборе eslint:recommended (или вовсе отключить некоторые правила установкой значения off).

ESLint будет искать файл конфигурации сначала в рабочей директории проекта, и далее — во всех родительских директориях вплоть до корневой. При этом директивы из первого найденного .eslintrc.json будут дополняться директивами из следующих найденных файлов. Если директивы противоречат друг другу, приоритет будет у того файла конфигурации, который был найден раньше. Поиск вверх по иерархии прекращается, когда найден файл конфигурации, содержащий настройку root в значении true. Так что мы можем использовать один файл конфигурации для всех проектов — только желательно добавить в него директиву root.

[projects]
.eslintrc.json содержит {"root":true, …}
[one-project]
index.js
package.json
..........
[two-project]
index.js
package.json
..........

Файл конфигурации VS Code

Это файл settings.json, здесь нужно разрешить работу расширения и указать, какие файлы проверять и форматировать:

{
..........
// По умолчанию форматирование кода запрещено
"editor.formatOnSave": false, // форматировать код при сохранении файла
"editor.formatOnPaste": false, // форматировать при вставке фрагмента кода
"editor.codeActionsOnSave": [], // набор действий при сохранении файла
"editor.defaultFormatter": null,
// Разрешить или запретить расширения eslint и prettier
"prettier.enable": true, // нужен рестарт vs code
"eslint.enable": true,
// Настройки форматирования javascript
"eslint.format.enable": false, // запретить или разрешить форматирование
"eslint.run": "onType", // запускать проверку кода по мере печати кода
"eslint.probe": [ // какие файлы нужно проверять
"javascript"
],
"[javascript]": {
// formatOnSave считается устаревшей, рекомендуется использовать codeActionsOnSave
"editor.formatOnSave": false,
"editor.formatOnPaste": true,
"editor.codeActionsOnSave": [
"source.formatDocument", // форматирование prettier
"source.fixAll.eslint" // исправление ошибок eslint
],
// "editor.defaultFormatter": "dbaeumer.vscode-eslint"
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
..........
}

Вообще говоря, расширение «ESLint» может решать две задачи — проверка кода и форматирование. Проверка кода — это поиск таких мест в коде, которые могут привести к ошибкам. Устранение таких узких мест — задача разработчика, эту нельзя поручить машине. Форматирование — это удаление пробелов, замена табуляций, перенос фигурных скобок. Такие действия не меняют логику работы кода, это можно поручить машине.

Но в примере выше расширение «ESLint» только проверяет код, а форматированием занимается расширение «Prettier» (см. здесь). Опция eslint.format.enable имеет значение false, а опция editor.defaultFormatter имеет значение esbenp.prettier-vscode. Форматирование у «ESLint» странное — например, в отличие от «Prettier», не выполняется разбиение длинных строк на две или три. Так что эту работу лучше оставить расширению «Prettier».

Проблема в том, что такая конфигурация толком не работает — расширения «ESLint» и «Prettier» для VS Code мешают друг другу.

Расширение «Prettier» не работает при сохранении, если editor.formatOnSave имеет значение false. То есть, «Prettier» вообще никак не реагирует на source.formatDocument — хотя в документации написано, что codeActionsOnSave заменяет и расширяет настройку formatOnSave.

С другой стороны, если выставить formatOnSave в true — перестает работать source.fixAll.eslint. Точнее говоря — внесенные «ESLint» изменения в код тут же затираются форматированием «Prettier» — formatOnSave срабатывает после codeActionsOnSave.

Можно форматировать (Alt+Shift+F) с использованием «Prettier». И можно исправить ошибки при сохранении (Ctrl+S) с использованием «ESLint». Возможно, причина этого в том, что VS Code активно развивается, постоянно добавляются новые возможности — и это просто временный баг, который пропадет при очередном обновлении.

ESLint и Prettier вместе, первый способ

У нас две проблемы. Первая — расширения «ESLint» и «Prettier» для VS Code мешают друг другу. Вторая — правила форматирования prettier могут противоречить правилам форматирования eslint. Давайте отредактируем файлы конфигурации .prettierrc и .eslintrc.json таким образом, чтобы спровоцировать такую ситуацию.

{
"arrowParens": "avoid",
"bracketSpacing": true,
"endOfLine": "lf",
"htmlWhitespaceSensitivity": "css",
"insertPragma": false,
"jsxBracketSameLine": false,
"jsxSingleQuote": false,
"printWidth": 80,
"proseWrap": "preserve",
"quoteProps": "as-needed",
"requirePragma": false,
"semi": false, // без точки с запятой в конце оператора
"singleQuote": true,
"tabWidth": 4,
"trailingComma": "es5",
"useTabs": false,
"vueIndentScriptAndStyle": true,
"embeddedLanguageFormatting": "auto"
}

{
"env": {
"browser": true,
"es2021": true,
"node": true
},
"extends": "eslint:recommended",
"parserOptions": {
"ecmaVersion": "latest",
"sourceType": "module"
},
"rules": {
"arrow-parens": ["error", "as-needed"],
"object-curly-spacing": ["error", "always"],
"array-bracket-spacing": ["error", "never"],
"quote-props": ["error", "as-needed"],
"semi": ["error", "always"], // точка с запятой в конце оператора
"quotes": ["error", "single"],
"linebreak-style": ["error", "unix"],
"indent": ["error", 4, { "SwitchCase": 1 }],
"no-trailing-spaces": "error",
"no-tabs": "error",
"comma-dangle": ["error", {
"arrays": "always-multiline",
"objects": "always-multiline",
"imports": "never",
"exports": "never",
"functions": "never"
}],
"brace-style": ["error", "1tbs"],
"keyword-spacing": "error",
"no-multi-spaces": "off",
"eqeqeq": "error",
"camelcase": "error",
"max-len": ["error", 100],
"no-multiple-empty-lines": "error"
}
}

После форматирования с использованием prettier (Alt+Shift+F) — получим множество сообщений «Missing semicolon» от eslint:

Чтобы скрестить ежа и ужа — установим пакет eslint-plugin-prettier, который позволит запускать prettier как правило eslint. Также потребуется установить пакет prettier — если он не был установлен ранее. То есть, мы вообще не будем использовать расширение VS Code «Prettier» при работе с js-файлами.

$ npm install prettier eslint-plugin-prettier --save-dev

{
"devDependencies": {
"eslint": "^8.20.0",
"eslint-plugin-prettier": "^4.2.1",
"prettier": "^2.7.1"
}
}

Редактируем файл конфигурации .eslintrc.json:

{
"root": true,
"env": {
"browser": true,
"es2021": true,
"node": true
},
"extends": [
"eslint:recommended"
],
"parserOptions": {
"ecmaVersion": "latest",
"sourceType": "module"
},
"plugins": ["prettier"],
"rules": {
"prettier/prettier": "error"
}
}

Мы убрали из .eslintrc.json все правила, связанные с форматированием. Правила форматирования теперь только в .prettierrc — противоречий больше нет. И теперь это работает так — формально defaultFormatter теперь расширение «ESLint». Но фактически форматированием занимается prettier. Проблемы с форматированием будут подчеркнуты зеленой волнистой линией. А правила из eslint:recommended будут подчеркнуты оранжевой или красной волнистой линией.

{
..........
// По умолчанию форматирование кода запрещено
"editor.formatOnSave": false, // форматировать код при сохранении файла
"editor.formatOnPaste": false, // форматировать при вставке фрагмента кода
"editor.codeActionsOnSave": [], // набор действий при сохранении файла
"editor.defaultFormatter": null,
// Разрешить или запретить расширения eslint и prettier
"prettier.enable": true, // нужен рестарт vs code
"eslint.enable": true,
// Настройки форматирования javascript
"eslint.format.enable": true, // NEW запретить или разрешить форматирование
"eslint.run": "onType", // запускать проверку кода по мере печати кода
"eslint.probe": [ // какие файлы нужно проверять
"javascript"
],
"eslint.rules.customizations": [
// для проблем форматирования кода уровень info
{"rule": "prettier/prettier", "severity": "info"}
],
"[javascript]": {
// NEW устаревшая настройка editor.formatOnSave больше не нужна
"editor.formatOnPaste": true,
"editor.codeActionsOnSave": [
"source.fixAll.eslint"
],
"editor.defaultFormatter": "dbaeumer.vscode-eslint" // NEW форматирование eslint
},
..........
}

Работает форматирование и исправление по сочетанию клавиш Alt+Shift+F + проверка кода по мере печати + форматирование и исправление при сохранении Ctrl+S. Теперь нет необходимости использовать устаревшую настройку formatOnSave. Впрочем, можно сделать и по старинке, с использованием formatOnSave.

{
..........
// По умолчанию форматирование кода запрещено
"editor.formatOnSave": false, // форматировать код при сохранении файла
"editor.formatOnPaste": false, // форматировать при вставке фрагмента кода
"editor.codeActionsOnSave": [], // набор действий при сохранении файла
"editor.defaultFormatter": null,
// Разрешить или запретить расширения eslint и prettier
"prettier.enable": true, // нужен рестарт vs code
"eslint.enable": true,
// Настройки форматирования javascript
"eslint.format.enable": true, // запретить или разрешить форматирование
"eslint.run": "onType", // запускать проверку кода по мере печати кода
"eslint.probe": [ // какие файлы нужно проверять
"javascript"
],
"eslint.rules.customizations": [
// для проблем форматирования кода уровень info
{"rule": "prettier/prettier", "severity": "info"}
],
"[javascript]": {
"editor.formatOnPaste": true,
"editor.formatOnSave": true,
"editor.defaultFormatter": "dbaeumer.vscode-eslint"
},
..........
}

{ .......... "workbench.colorCustomizations": { "editorError.foreground": "#FF0000", "editorWarning.foreground": "#FF9933", "editorInfo.foreground": "#00AA00", }, .......... }

Исходные коды здесь, директория eslint-prettier-together-one.

$ npm install @typescript-eslint/parser @typescript-eslint/eslint-plugin --save-dev

{ "root": true, "env": { "browser": true, "es2021": true, "node": true }, "extends": [ "eslint:recommended", "plugin:@typescript-eslint/recommended" ], "parser": "@typescript-eslint/parser", "parserOptions": { "ecmaVersion": "latest", "sourceType": "module" }, "plugins": [ "@typescript-eslint", "prettier" ], "rules": { "prettier/prettier": "error" } }

{ .......... // По умолчанию форматирование кода запрещено "editor.formatOnSave": false, // форматировать код при сохранении файла "editor.formatOnPaste": false, // форматировать при вставке фрагмента кода "editor.codeActionsOnSave": [], // набор действий при сохранении файла "editor.defaultFormatter": null, // Разрешаем работу расширений prettier и eslint "prettier.enable": true, // разрешить работу расширения prettier (нужен рестарт vs code) "eslint.enable": true, // разрешить работу расширения eslint // Настройки prettier и eslint для файлов javascript, typescript и react "eslint.format.enable": true, // запретить или разрешить форматирование "eslint.run": "onType", // запускать проверку кода по мере печати кода "eslint.probe": ["javascript", "typescript"], // какие файлы нужно проверять "eslint.rules.customizations": [ // для проблем форматирования кода уровень info {"rule": "prettier/prettier", "severity": "info"} ], "[javascript]": { "editor.formatOnPaste": true, "editor.formatOnSave": true, "editor.defaultFormatter": "dbaeumer.vscode-eslint", }, "[javascriptreact]": { "editor.formatOnPaste": true, "editor.formatOnSave": true, "editor.defaultFormatter": "dbaeumer.vscode-eslint", }, "[typescript]": { "editor.formatOnPaste": true, "editor.formatOnSave": true, "editor.defaultFormatter": "dbaeumer.vscode-eslint", }, "[typescriptreact]": { "editor.formatOnPaste": true, "editor.formatOnSave": true, "editor.defaultFormatter": "dbaeumer.vscode-eslint", }, .......... }

Набор правил Standard

Кроме набора правил eslint:recommended есть еще несколько популярных наборов — Standard, Airbnb, Google и другие. Давайте для примера посмотрим, как использовать правила Standard — этот набор гораздо больше eslint:recommended и предупреждений об ошибках будет больше.

$ npm install eslint-config-standard eslint-plugin-promise eslint-plugin-import eslint-plugin-n --save-dev

{
"devDependencies": {
"eslint": "^8.20.0",
"eslint-config-standard": "^17.0.0",
"eslint-plugin-import": "^2.26.0",
"eslint-plugin-n": "^15.2.4",
"eslint-plugin-prettier": "^4.2.1",
"eslint-plugin-promise": "^6.0.0",
"prettier": "^2.7.1"
}
}

{
"root": true,
"env": {
"browser": true,
"es2021": true,
"node": true
},
"extends": [
"standard"
],
"parserOptions": {
"ecmaVersion": "latest",
"sourceType": "module"
},
"rules": {}
}

Standard включает в себя не только правила поиска ошибок, но и правила форматирования — так что мы опять упираемся в проблему противоречий с правилами prettier. Давайте установим модуль eslint-config-prettier, который отключит все правила, которые противоречат prettier.

$ npm install eslint-config-prettier --save-dev

{
"devDependencies": {
"eslint": "^8.20.0",
"eslint-config-prettier": "^8.5.0",
"eslint-config-standard": "^17.0.0",
"eslint-plugin-import": "^2.26.0",
"eslint-plugin-n": "^15.2.4",
"eslint-plugin-prettier": "^4.2.1",
"eslint-plugin-promise": "^6.0.0",
"prettier": "^2.7.1"
}
}

{   
"root": true,
"env": {
"browser": true,
"es2021": true,
"node": true
},
"extends": [
"standard",
"plugin:prettier/recommended"
],
"parserOptions": {
"ecmaVersion": "latest",
"sourceType": "module"
},
"rules": {}
}

Настройка plugin:prettier/recommended на самом деле делает следующее:

{
"root": true,
"env": {
"browser": true,
"es2021": true,
"node": true
},
"extends": [
"standard",
"prettier"
],
"parserOptions": {
"ecmaVersion": "latest",
"sourceType": "module"
},
"plugins": ["prettier"],
"rules": {
"prettier/prettier": "error",
"arrow-body-style": "off",
"prefer-arrow-callback": "off"
}
}

Исходные коды здесь, директория eslint-prettier-standard-one.

Особенности конфигурации

Программисты обожают наводить тень на плетень — и разработчики ESLint не исключение. Два фрагмента ниже из файла конфигурации эквивалентны.

"plugins": [
"react",       // npm module eslint-plugin-react
"prettier"     // npm module eslint-plugin-prettier
]

"plugins": [
"eslint-plugin-react",
"eslint-plugin-prettier"
]

Еще запутаннее, когда имена плагинов начинаются с @ (пространство имен). Нужно учитывать, что @foo и @foo/bar находятся в одном пространстве имен, но это два разных плагина (npm-модуля). Два фрагмента ниже из файла конфигурации эквивалентны.

"plugins": [
"@foo",               // npm module @foo/eslint-plugin
"@foo/bar"            // npm module @foo/eslint-plugin-bar
]

"plugins": [
"@foo/eslint-plugin",
"@foo/eslint-plugin-bar"
]

И еще один важный момент — когда в extends используется префикс plugin:

"extends": [
"plugin:foo/bar",
],

Это значит, что плагин eslint-plugin-foo содержит в себе набор правил bar:

// код плагина eslint-plugin-foo
module.exports = {
configs: {
bar: {
plugins: ["foo"], // допускается foo вместо eslint-plugin-foo
env: ["browser"],
rules: {
semi: "error",
"foo/one": "error", // допускается foo вместо eslint-plugin-foo
"foo/two": "error",
"eslint-plugin-foo/three": "error",
}
},
baz: {
plugins: ["foo"], // допускается foo вместо eslint-plugin-foo
env: ["node"],
rules: {
semi: "warn",
"foo/one": "off", // допускается foo вместо eslint-plugin-foo
"foo/two": "error",
"eslint-plugin-foo/three": "off",
}
}
}
};

Поиск:
IDE • JavaScript • Web-разработка • Конфигурация • Настройка • Плагин • Установка • Файл • ESLint • Prettier

Как исправить предупреждение линтера «Ошибка возвращаемого значения не проверено»?

//for example, same method may be called from imported entity func foo() error { if err := someFunction(); err != nil { return err } return nil } func process() { //linter doesn't like this foo() //this way leads to unused variable error err := foo() //is this clean way? _ = foo() return } 

Перейти к ответу
Данный вопрос помечен как решенный

Ответы
3

err := foo() if err != nil { // handle your error here } 

В идеале вы должны обработать ошибку, но если она вас раздражает, вы можете отключить линтер в goland (который вы все равно должны использовать):

Другие вопросы по теме