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 в функции и var i = 0
объявлениям цикла for , а также некоторые принудительные пробелы для объявлений функций ,
Я нахожу, что некоторые из пробелов, которые применяются в JSLint, не обязательно плохие, но не совпадают с некоторыми довольно стандартными соглашениями о пробелах для других языков семейства (C, Java, Python и т. Д.), Которые часто следовал как соглашения в Javascript, а также. Поскольку я пишу на разных этих языках в течение дня и работаю с членами команды, которым не нравятся пробелы в стиле Lint в нашем коде, я считаю JSHint хорошим балансом. Он ловит вещи, которые являются законной ошибкой или действительно плохой формой, но не лает на меня, как делает JSLint (иногда, способами, которые я не могу отключить) за стилистические мнения или синтаксические придирки, которые меня не волнуют.
Многие хорошие библиотеки не являются Lint'able, что для меня демонстрирует, что есть некоторая правда в идее, что некоторые из JSLint просто выдвигают одну версию «хорошего кода» (который действительно является хорошим кодом). Но опять же, те же самые библиотеки (или другие хорошие), вероятно, тоже не могут быть Hint'able, так что, touché.
Combine this with the previous 'var' statement
->Do not mix 'require' and other declarations
, парадокс.