Чи варто використовувати перевірку 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 дуже корисним під час нашого процесу перегляду коду. Рекомендую.
Chetan Vashistth

Відповіді:


156

[EDIT]
Цю відповідь відредаговано. Я залишаю оригінальну відповідь нижче для контексту (інакше коментарі не мали б сенсу).

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

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

У своїй оригінальній відповіді я сказав, що не слід змушувати себе дотримуватися правил JSLint; до тих пір, поки ви зрозуміли, чому це накидання попередження, ви могли самі прийняти рішення про те, чи потрібно змінювати код, щоб усунути попередження чи ні.

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

Ще можуть іноді траплятися випадки, коли лайнер скаржиться на те, що ви зробили навмисно - наприклад, ви знаєте, що завжди слід користуватися, ===але тільки в цей раз у вас є вагомі причини використовувати ==. Але навіть тоді з ESLint у вас є можливість вказати eslint-disableнавколо відповідної лінії, щоб ви все ще могли пройти тест на підошву з нульовими попередженнями, а решта коду підкоряється правилу. (просто не робіть подібних речей занадто часто!)


[ОРИГІНАЛЬНІ ВІДПОВІДИ]

У будь-якому випадку використовуйте 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.
jinglesthula

369

tl; dr takeaway :

Якщо ви шукаєте дуже високий стандарт для себе чи команди, 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-loop , а також деякі застосунки білого простору для декларацій функції. .

Декілька речей білого простору, які застосовує JSLint, я вважаю не обов’язково поганим, але не синхронізований з деякими досить стандартними умовами пробілів для інших мов у сім'ї (C, Java, Python тощо), які часто є слідують конвенціям і в Javascript. Оскільки я пишу на різних цих мовах протягом дня і працюю з членами команди, які не люблять пробіл у стилі Lint у нашому коді, я вважаю, що JSHint є гарним балансом. Він ловить речі, які є законною помилкою або дуже поганою формою, але не гавкає на мене, як це робить JSLint (іноді таким чином, я не можу відключити) за стилістичні думки або синтаксичні нитки, які мені не цікаві.

Дуже багато хороших бібліотек не є Lint'able, що, на мій погляд, демонструє, що є деяка правда в думці про те, що деякі JSLint просто просто просувають 1 версію "хорошого коду" (що, справді, хороший код). Але знову ж таки, ті самі бібліотеки (або інші хороші), ймовірно, теж не підкажуть, тож, 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
Значення наявності літера, який працює у вашому редакторі під час введення, не може бути заниженим. ESLint використовується таким чином широко. Я ніколи не чув про підтримку редактора JSLint або JSHint (1 анекдотична точка даних).
jinglesthula

17

У мене було те саме питання пару тижнів тому, і я оцінював JSLint і JSHint.

Всупереч відповідям у цьому питанні, мій висновок не був:

У будь-якому випадку використовуйте JSLint.

Або:

Якщо ви шукаєте дуже високий стандарт для себе чи команди, JSLint.

Як можна налаштувати майже ті самі правила в JSHint, як і в JSLint. Тому я б заперечував, що в правилах, яких ви могли досягти, немає великої різниці.

Тож причини вибирати одне над іншим є більш політичними, ніж технічними.

Ми нарешті вирішили піти з JSHint з наступних причин:

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

1
Дякую за коротку і стислу відповідь. Це вирішило мої недоліки щодо проблеми.
акауппі

13

Я б запропонував третю пропозицію - компілятор закриття Google (а також лінк закриття ). Ви можете спробувати його онлайн тут .

Компілятор закриття - це інструмент для швидшого завантаження та запуску JavaScript. Це справжній компілятор для JavaScript. Замість компіляції з вихідної мови в машинний код вона компілюється з JavaScript на кращий JavaScript. Він аналізує ваш JavaScript, аналізує його, видаляє мертвий код і переписує та мінімізує те, що залишилося. Він також перевіряє синтаксис, змінні посилання та типи та попереджає про загальні підводні камені JavaScript.


4
Що робить компілятор закриття, який не має лайнера?
Джеймс Макмахон

4
Я не бачу жодного попередження, створеного цим інструментом, коли це, безумовно, повинно. JSLint і JSHint створюють стільки попереджень за один і той же вхід, що вони обидва дають "занадто багато помилок".
wallyk

6
ми використовували закриття недавнього проекту і більше не зробили цього. вкладиш не може бути налаштований на вимкнення певних чеків (багато з яких - речі, які вас не хвилюють), і компілятор справді окупається лише у тому випадку, якщо ви працюєте виключно із зручними для закриття бібліотеками (яких насправді немає будь-яка поза Google).
Роберт Леві

4
Це не стосується Google Clopi Comepiler як такої, але інструменти Google завжди повинні дивитися на зерно солі. Вони створені для вирішення конкретних цілей Google, і вони можуть не збігатися з вашими цілями.
Pacerier

@RobertLevy дякую за коментар до вашого досвіду, який у вас був ... Я читав посібник зі стилю google для JavaScript, і рекомендував закривати компілятор, оскільки це програма для ворсу. але тепер я бачу, що є інші, як jslint та jshint
Тревор Бойд Сміт

13

Вступне слово: Добре, що швидко наростало. Але вирішив витягнути це. Нехай ця відповідь буде корисною вам та іншим читачам.

Я тут трохи захопився

Підказки коду

Хоча JSLint і JSHint - хороші інструменти для використання, я протягом багатьох років оцінював те, що називає мій друг @ugly_syntax :

менший дизайн-простір .

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

Тому мій поточний улюблений стиль коду JS:

StandardJS .

ОНОВЛЕННЯ :

Потік значно покращився. З його допомогою ви можете додавати типи до свого JS, що допоможе вам запобігти багато помилок. Але це також може не виходити, наприклад, при взаємодії нетипового JS. Спробувати!

Quickstart / TL; DR

Додайте standardяк залежність до свого проекту

npm install --save standard

Потім package.jsonдодайте наступний тестовий сценарій:

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

Для виходу snazzier під час розробки npm install --global snazzyта запустіть його замістьnpm test .

Примітка: Перевірка типу порівняно з евристикою

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

Чому? Насправді JS натхненний LISP, це особливий клас мов, який, як правило, не типований . Мова , такі як в'яз або Purescript є набрані функціональними мовами програмування.

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

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

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

(п. зауважте, що код React не є ідіоматичним і його можна вдосконалити)

Одне заключне зауваження,

реальність така , що JS є Нетипізовані. Хто я, щоб запропонувати вам набране програмування ?

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

Але без типів мало що може контролювати наші програми, тому ми змушені впроваджувати тести та (в меншій мірі) стилі коду.

Я рекомендую подивитися на LISP (наприклад, ClojureScript ), щоб отримати натхнення та інвестувати у тестування своїх кодів. Прочитайте Шлях підстанції щоб отримати уявлення.

Мир.


Чому потік? Я, звичайно, не заперечую, але оскільки ОП написав: "це допомагає мені писати краще JavaScript", я думаю, це корисна відповідь? Як ти гадаєш?
дроти

1
не пов’язане з поніжними записами, але як ваші посилання Main.elm, так і index.js мають
404s

1
Питання було чітко jslint чи jshint, не вимагаючи альтернатив.
jzacharuk

1
Гіф заслуговує виграшу.
sr9yar

8

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

Заявіть про весь глобальний var у цьому файлі, як:

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

Оголосіть усі параметри ворсу на зразок:

/*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.