Ответ 1

[EDIT]
Этот ответ был отредактирован. Я оставляю исходный ответ ниже для контекста (иначе комментарии не имеют смысла).

Когда этот вопрос изначально был задан, JSLint был основным инструментом для перебора текста JavaScript. JSHint был новой вилкой JSLint, но еще не расходился с оригиналом.

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

В моем первоначальном ответе я сказал, что вы не должны заставлять себя придерживаться правил JSLint; до тех пор, пока вы понимаете, почему оно бросает предупреждение, вы можете сами судить о том, следует ли изменять код для разрешения предупреждения или нет.

С ультра-строгим набором правил JSLint с 2011 года это был разумный совет - я видел очень мало кодов JavaScript, которые могли бы пройти тест JSLint. Однако с более прагматичными правилами, доступными в сегодняшних инструментах JSHint и ESLint, гораздо более реалистичным предложением является попытка получить код, проходящий через них с нулевыми предупреждениями.

Иногда могут появляться случаи, когда linter будет жаловаться на то, что вы сделали намеренно - например, вы знаете, что вы всегда должны использовать ===, но только один раз у вас есть веская причина для использования ==. Но даже тогда, с ESLint, у вас есть возможность указать eslint-disable вокруг рассматриваемой строки, чтобы вы все еще могли проходить тест на линт с нулевыми предупреждениями, а остальная часть вашего кода подчинялась правилу. (просто не делайте этого слишком часто!)

[ОРИГИНАЛЬНЫЙ ОТВЕТ ПОСЛЕДУЕТ]

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

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

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

Ответ 2

tl; dr вынос:

Если вы ищете очень высокий уровень для себя или команды, JSLint. Но это не обязательно стандарт, просто стандарт, некоторые из которых догматически доходят до нас с божества javascript по имени Дуг Крокфорд. Если вы хотите быть немного более гибким или иметь некоторые старые профи в своей команде, которые не покупают в JSLint-мнений или регулярно ходят между JS и другими языками C-семьи, попробуйте JSHint.

длинная версия:

Обоснование вилки объясняет, почему JSHint существует:

http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to-jshint/

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

В качестве примера, если вы считаете, что оба A и B ниже в порядке, или если вы хотите написать код с одним или несколькими аспектами A, которые недоступны в B, JSHint для вас. Если вы считаете, что B - единственный правильный вариант... JSLint. Я уверен, что есть другие отличия, но это подчеркивает несколько.

A) Пропускает JSHint из коробки - сбой JSLint

(function() {
  "use strict";
  var x=0, y=2;
  function add(val1, val2){
    return val1 + val2;
  }
  var z;
  for (var i=0; i<2; i++){
    z = add(y, x+i);
  }
})();

B) Пропускает как JSHint, так и JSLint

(function () {
    "use strict";
    var x = 0, y = 2, i, z;
    function add(val1, val2) {
       return val1 + val2;
    }
    for (i = 0; i < 2; i += 1) {
        z = add(y, x + i);
    }
}());

Лично я нахожу код JSLint, на который очень приятно смотреть, и единственными сложными чертами, с которыми я не согласен, является его ненависть от более чем одного объявления var в функции и для -loop var i = 0 деклараций и некоторые из элементов управления пробелами для объявлений функций.

Несколько пробельных вещей, которые JSLint применяет, я считаю, что это не обязательно плохо, но не синхронизирован с некоторыми довольно стандартными соглашениями с пробелами для других языков семейства (C, Java, Python и т.д.), которые часто следуют как соглашения в Javascript. Поскольку я пишу на разных языках в течение дня и работая с членами команды, которые не любят пробелы в стиле Lint в нашем коде, я нахожу JSHint хорошим балансом. Он ловит материал, который является законной ошибкой или действительно плохой формой, но не лает на меня, как JSLint (иногда, таким образом, что я не могу отключить) для стилистических мнений или синтаксических нитпиков, которые мне не нужны.

Много хороших библиотек не Lint'able, что для меня демонстрирует, что есть некоторая правда в том, что некоторые из JSLint просто просто подталкивают 1 версию "хорошего кода" (который, действительно, хороший код). Но опять же, те же самые библиотеки (или другие хорошие), вероятно, тоже не Hint'able, так что touché.

Ответ 3

На фронте javascript есть еще один зрелый и активно развитый "игрок" - ESLint:

ESLint - это инструмент для выявления и отчетности по шаблонам, найденным в Код ECMAScript/JavaScript. Во многом это похоже на JSLint и JSHint за несколькими исключениями:

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

Что действительно важно, так это то, что он расширяется через пользовательские плагины/правила. Уже есть несколько плагинов, написанных для разных целей. Среди других есть:

• eslint-plugin-angular (применяет некоторые рекомендации из John Papa Angular Руководство по стилю)
• eslint-plugin-jasmine
• eslint-plugin-backbone

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

• grunt-eslint
• gulp-eslint

Ответ 4

У меня был тот же вопрос пару недель назад и оценивал как JSLint, так и JSHint.

В отличие от ответов в этом вопросе, мой вывод не был:

В любом случае используйте JSLint.

Или:

Если вы ищете очень высокий уровень для себя или команды, JSLint.

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

Итак, причины выбора одного над другим более политичны, чем технические.

Наконец, мы решили пойти с JSHint по следующим причинам:

• Кажется, что более настраиваемый JSLint.
• Выглядит определенно более ориентированный на сообщества, а не на шоу с одним человеком (независимо от того, насколько крут человек).
• JSHint сопоставляет наш стиль кода OOTB лучше, чем JSLint.

Ответ 5

Я бы сделал третье предложение, Google Closure Compiler (а также Closure Linter). Вы можете попробовать его онлайн здесь.

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

Ответ 6

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

Подсказка по коду

Хотя JSLint и JSHint являются хорошими инструментами для использования, на протяжении многих лет я осознавал, что мой друг @ugly_syntax называет:

меньшее дизайнерское пространство.

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

Поэтому мой любимый стиль кода JS с нулевой конфигурацией:

Стандартные JS.

ОБНОВЛЕНИЕ:

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

Быстрый старт /TL; DR

Добавить standard в качестве зависимости от вашего проекта

npm install --save standard

Затем в package.json добавьте следующий тестовый скрипт:

"scripts": {
    "test": "node_modules/.bin/standard && echo put further tests here"
},

Для получения более яркого вывода при разработке, npm install --global snazzy и запустите его вместо npm test.

Примечание: проверка типа по сравнению с эвристикой

Мой друг, упоминая пространство дизайна, упомянул Elm, и я призываю вас попробовать этот язык.

Зачем? JS на самом деле вдохновлен LISP, который представляет собой особый класс языков, который, как правило, не типизирован. Такие языки, как Elm или Purescript, являются типизированными функциональными языками программирования.

Тип ограничивает вашу свободу, чтобы компилятор мог проверять и направлять вас, когда вы в конечном итоге нарушаете язык или правила вашей собственной программы; независимо от размера (LOC) вашей программы.

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

Сравните Main.elm (напечатано) ⇔ index.js (нетипизировано, без тестов)

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

Последнее замечание,

реальность такова, что JS нетипизирован. Кто я такой, чтобы предлагать вам типизированное программирование?

Видите ли, с JS мы находимся в другой области: освобожденные от типов, мы можем легко выразить вещи, которые трудно или невозможно дать правильный тип (что, безусловно, может быть преимуществом).

Но без типов практически невозможно контролировать наши программы, поэтому мы вынуждены вводить тесты и (в меньшей степени) стили кода.

Я рекомендую вам взглянуть на LISP (например, ClojureScript) для вдохновения и инвестировать в тестирование ваших кодов. Прочитайте способ подсистемы, чтобы получить представление.

Мир.

Ответ 7

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

Объявите все глобальные переменные в этом файле, например:

/*global require,dojo,dojoConfig,alert */

Объявите все настройки lint как:

/*jslint browser:true,sloppy:true,nomen:true,unparam:true,plusplus:true,indent:4 */

Надеюсь, это поможет вам:)

Ответ 8

Существует и другая активно развитая альтернатива - АОС - стиль кода JavaScript:

АОС - это стиль кода для программирования для вашего стиля руководство. Вы можете сконфигурировать АОС для своего проекта, используя 150 правил проверки, включая пресеты из популярных руководств стиля, таких как jQuery, Airbnb, Google и т.д.

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

{
    "preset": "jquery",
    "requireCurlyBraces": null
}

Существуют также плагины и расширения, созданные для популярных редакторов.

Также смотрите:

• Идеальный код, нулевое усилие