tl; dr takeaway:

Если вы ищете очень высокий стандарт для себя или команды, JSLint. Но это не обязательно стандарт, просто стандарт, некоторые из которых догматически приходят к нам от Бога javascript по имени Дуг Крокфорд. Если вы хотите быть немного более гибкими или иметь в своей команде старых профессионалов, которые не покупаются на мнения JSLint или регулярно переходят между JS и другими языками C-family, попробуйте У 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 в функции и for-loop var i = 0 декларации и некоторые из принудительных действий пробелов для объявлений функций.

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

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

есть еще зрелые и активно развивается "игрок" на javascript linting front -ESLint:

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

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

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

• eslint-плагин-угловой (применяет некоторые рекомендации из Джон папа угловой Руководство По Стилю)
• eslint-плагин-Жасмин
• eslint-plugin-backbone

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

• грунт-eslint
• глоток-eslint

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

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

непременно используйте JSLint.

или:

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

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

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

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

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

Я бы сделал третье предложение, Компилятор Закрытия Google (а также Закрытие Линтер). Вы можете попробовать его в интернете здесь.

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

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

Подсказки Кода

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

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

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

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

StandardJS.

обновление:

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

Quickstart / TL; DR

добавить standard как зависимость от вас project

npm install --save standard

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

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

для выхода snazzier пока превращающся,npm install --global snazzy и запустите его вместо npm test.

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

мой друг при упоминании дизайна пространства упоминается Вязовая и я призываю вас попробуйте этот язык.

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

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

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

сравнить Main.elm (наборная) ⇔ index.js (нетипизированный, никаких тестов)

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

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

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

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

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

я рекомендую вам посмотреть на LISP (например ClojureScript) для вдохновения и инвестиций в тестирование ваших кодов. Читать путь substack чтобы получить представление.

Мирный.

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

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

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

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

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

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

есть и другая активно разрабатываемая альтернатива -JSCS-JavaScript стиль кода:

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

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

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

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

Смотрите также:

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