Должен ли я использовать JSLint или JSHint JavaScript проверки? [закрыто]


454

В настоящее время я проверяю свой JavaScript на соответствие JSLint и развиваюсь, он помогает мне лучше писать JavaScript - в частности, в работе с библиотекой Jquery.

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

  • JSLint или JSHint?

Я хочу сейчас определиться с механизмом проверки и двигаться вперед, используйте его для проверки на стороне клиента.

А разница между jshint и jslint? Пожалуйста, объясните в одном примере JavaScript.

Ссылки:

  1. jshint - http://www.jshint.com/

  2. jslint - http://jslint.com/


4
Как насчет ESLint ? Хотя это несовершенно: Combine this with the previous 'var' statement-> Do not mix 'require' and other declarations, парадокс.
nyuszika7h



Не разработчик JS. Но я нашел JSHint очень полезным в процессе нашего обзора кода. Я рекомендую это.
Четан Вашист

Ответы:


156

[РЕДАКТИРОВАТЬ]
Этот ответ был отредактирован. Я оставляю оригинальный ответ ниже для контекста (иначе комментарии не имели бы смысла).

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

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

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

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

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


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

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

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

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


3
Лучшая часть jsHint состоит в том, что он имеет флаги для принятия jQuery и не раздражает / строг как jslint. Например: for (i = 0; i < dontEnumsLength; i++)бросает, Unexpected '++'где все в порядке. и т.д.
RaphaelDDL

2
Пожалуйста, не игнорируйте правила, это худшее, что вы можете сделать с линтером. Просто настройте это, или, если вы не можете сделать это, измените. Сочетание JSHint и JSCS просто фантастическое
AuthorProxy

JSHint говорит: «Ожидал присваивания или вызова функции и вместо этого увидел выражение». к тройной используется только для операций. Документация Mozilla: «Вы также можете использовать троичные вычисления в свободном пространстве для выполнения различных операций». developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/… @AuthorProxy Я собираюсь использовать Mozilla и игнорирую JSHint. Сожалею.
роса

1
К настоящему времени, похоже, ESLint - это направление, в котором движется индустрия в целом, наряду с такими популярными конфигурациями, как airbnb.
Джинглстхула

369

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é.


11
... Должен признать, я был разочарован непрофессиональным качеством советов, которые я недавно видел, распространенных в отношении стилей кодирования для JS (и CSS тоже, кстати). Это как если бы увлечение конкретным языком перевесило потребности неопытных практиков (то есть целевой аудитории). Это такой позор, учитывая, что им нужен хороший совет, и они будут слепо следовать и увековечивать то, что преподносится как лучшая практика, не зная ничего лучшего. Часто это несовместимо с другими стандартами, принятыми более устоявшимися сообществами пользователей для других языков. :(
Ли Ковальковски

67
@LeeKowalkowski Причина, по которой JSLint обескураживает, for (var i = 0; ...; i++)заключается в том, что он не делает цикл самодостаточным. Сфера iявляется функцией. Синтаксис выглядит так, как будто он создает область видимости блока, но это не так, и это приводит к тому, что менее опытные программисты на JavaScript и люди, пишущие на нескольких языках, неправильно понимают область действия переменной, что может привести к незначительным ошибкам. Многим из нас (включая меня) может не понравиться то, как выглядит все объявления вверху, но это хорошее напоминание о том, что JavaScript не имеет блочной области видимости.
Марк Эванс

25
@MarkEvans Самостоятельно считает, что если вы переместили только цикл в другую функцию, iон не станет случайно глобальным. Тот факт, что iобласть действия функции не является областью действия блока, не является достаточной причиной для объявления переменных вверху, переменные всегда должны быть объявлены как можно ближе к месту их использования ( programmers.stackexchange.com/questions/56585/… ).
Ли Ковальковски

17
@MarkEvans Я думаю, вы слишком много внимания уделяете деталям языковой реализации. Стандарты программирования должны быть для людей, а не для компиляторов. Опора на инструмент статического анализа кода для выявления распространенных ошибок не является заменой для принятия хороших привычек, которые в первую очередь избегают их. Я не могу понять причину, по которой переменная итератора для простого цикла должна быть объявлена ​​на любом расстоянии от цикла, который требует этого. Многие стандарты кодирования для других языков говорят, что переменные объявляются как можно ближе к месту их использования для удобства чтения. Я не видел веских причин не делать этого в JS.
Ли Ковальковски

11
Использование переменной итератора вне цикла - это то, что нужно проверять линтеру.
Ли Ковальковски

61

На переднем крае javascript есть еще один зрелый и активно развивающийся «игрок» ESLint:

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

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

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

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


1
Нельзя недооценивать значение наличия linter, который запускается в вашем редакторе при вводе. ESLint используется таким образом широко. Я никогда не слышал о поддержке редактора JSLint или JSHint (1 случайная точка данных).
Джинглстхула

17

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

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

Обязательно используйте JSLint.

Или:

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

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

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

Мы наконец решили использовать JSHint по следующим причинам:

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

1
Спасибо за короткий и краткий ответ. Это решило мои пробелы в вопросе.
akauppi

13

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

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


4
Что компилятор Closure обнаруживает, что не линтер?
Джеймс МакМэхон

4
Я не вижу ни одного предупреждения, генерируемого этим инструментом, когда оно обязательно должно появиться. JSLint и JSHint выдают столько предупреждений для одного и того же ввода, что оба они выдают «слишком много ошибок».
Wallyk

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

4
Это не относится к Google Closure Comepiler как таковому, но инструменты Google всегда должны рассматриваться с недоверием. Они созданы для решения конкретных задач Google и могут не совпадать с вашими целями.
Pacerier

@RobertLevy, спасибо, что прокомментировали ваш опыт, который у вас был ... Я читал руководство по стилю google для javascript, и он порекомендовал closure-compiler в качестве программы lint. но теперь я вижу, что есть и другие, такие как jslint и jshint
Тревор Бойд Смит

13

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

Я немного увлекся здесь

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

Хотя 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 ) для вдохновения и инвестировать в тестирование ваших кодов. Прочитайте способ подсистемы, чтобы получить представление.

Мир.


Почему отрицательный голос? Я, конечно, не против, но, поскольку OP написал «это помогает мне лучше писать JavaScript», я думаю, что это полезный ответ? Что вы думаете?
провода

1
не связанные с отрицательными голосами, но ваши ссылки Main.elm и index.js имеют
404s

1
Вопрос был явно jslint или jshint, не спрашивая альтернативы.
jzacharuk

1
GIF заслуживает возражения.
sr9yar

8

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

Объявите все глобальные переменные в этом файле следующим образом:

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

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

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

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


1

Существует также другая активно развивающаяся альтернатива - JSCS - JavaScript Code Style :

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

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

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

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

Также см:

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.