Почему JQuery не передает JSLint?

Question

Можно создать дубликат:
What good is JSLint if jQuery fails the validation

http://code.jquery.com/jquery-1.4.4.js

Перейти туда и вставить его в www.jslint.com

Не Jquery должен быть действительным. ...

Answer 1

Это слишком много работы, чтобы соответствовать ему И быть кросс-браузерным. JSLint полезен, но его единственный общий парсер. У jQuery есть веские причины для того, чтобы вносить в него ошибки.

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

давайте смотреть на них один за другим:

Проблема в строке 231 символов 20: ожидаемый '===' и вместо этого увидел '=='.

возвращение num == null?

Здесь JQuery использует == на null, чтобы проверить как undefined и null. Поскольку jQuery используется как внешняя библиотека, он не может гарантировать, будет ли вход, который мы передаем в функции, будет undefined или null. Это безопаснее для проверки и того, и другого.

Выполнение num === undefined || num === null, чтобы удовлетворить JSLint, смешно.

Проблема в строке 446 символов 29: Ожидаемое условное выражение и вместо видел задание.

в то время как ((п = готов [я ++])) {

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

Проблема в строке 550 символ 9: пустой блок.

var ключ; for (key in obj) {}
return key === undefined || hasOwn.call (obj, key);

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

Проблема в строке 554 символов 15: Перемещение декларации 'Var' в верхней части функции .

для (имя вар в OBJ) {

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

И затем сидит парсер. Позвольте мне удалить часть кода, разбирая его и посмотреть, могу ли я найти больше жалоб.

Проблема в строке 792 символов 42: '& &' подвыражения должны быть обернуты в круглых скобках.

ua.indexOf ("совместимый") & rmozilla.exec (UA) ||

Я согласен с этим (ua.indexO("compatile") < 0) &&.

Проблема в строке 872 символов 3: Перемещение призывания в круглые скобки, которые содержат функцию.

})();

Для закрытия, как:

(function() { 

})(); 
//}()); 

JSLint предпочитает видеть функцию invokion в скобках как вопрос стиля. Я также согласен с этим, но это действительно не имеет значения.

Проблема в строке 972 символ 13: 'e' уже определен.

} поймать (е) {

Parser жалуется на повторное использование переменной e В этом случае мы знаем, что e будет использоваться только локально в этом поймать блок, так что не имеет значения, если изменить его вне блок catch. Здесь я предпочитаю читаемость повторно используя имя переменной e

Проблема в строке 1097 символов 21: ожидаемый «===» и вместо этого увидел «==».

elem = elem == window?

Хорошо, ты поймал меня на этом.Я stumbed, почему JQuery не использует === на window

Проблема в строке 1621 символов 24: ожидалась назначение или функции вызова, а вместо этого увидел выражение.

parent.selectedIndex;

// Safari mis-reports the default selected property of an option 
// Accessing the parent's selectedIndex property fixes it 
if (name === "selected" && !jQuery.support.optSelected) { 
    var parent = elem.parentNode; 
if (parent) { 
    parent.selectedIndex; 

Вот один из этих кросс-браузерные соответствия нормам ошибок, которые могут быть фиксированными, но приводит к плохой code

Проблема в строке 977 символа 17: Missing «перерыв» после «дела».

случай "последний":

JSLint говорит, что вы должны всегда поломки после ваших дел. Совершенно верно, чтобы пройти через случай. В большинстве случаев вы забыли break, но здесь это намеренно.

Проблема в строке 1099 символов 77: Ожидаемого задания или функции вызова, а вместо этого увидела выражение.

Array.prototype.slice.call ( document.documentElement.childNodes, 0 ) [0] .node ...

// Perform a simple check to determine if the browser is capable of 
// converting a NodeList to an array using builtin methods. 
// Also verifies that the returned array holds DOM nodes 
// (which is not the case in the Blackberry browser) 
try { 
    Array.prototype.slice.call(document.documentElement.childNodes, 0)[0].nodeType; 

Источник здесь говорит само за себя. Это странное утверждение, но если доступ к нему, как это, вызывает ошибку, тогда его можно поймать. Это все еще справедливо, только JSLint говорит вам: «Вы действительно хотели это сделать?»

Проблема в строке 2377 символ 15: Плохая для переменной 'name'.

для (имя в настройках) {

Здесь JSLint жалуется на использование name, которые могут вступать в противоречие с window.name в глобальном масштабе. Это «не совсем зарезервированное ключевое слово будущего, но его следует избегать». Были закрыты, так что это безопасно.

Проблема на линии 2486 символ 29: слишком много ошибок. (60% отсканировано).

Внутренний стек JSLint не может справиться с этим. Сейчас я остановлюсь.

Я думаю, что пункт проиллюстрирован.

JSLint имеет много «Вы уверены, что хотите это сделать» И говорили это да, мы хотим это сделать. Это может показаться ошибкой, но это не так.

Answer 2

Правила, которые использует jslint, являются руководящие принципы, а не нерушимые правила. Есть много причин, по которым вы, возможно, захотите проигнорировать некоторые из них.

Существует немало detailed considerations of jslint rules; многие люди не согласны с этим.

Лично мне это нравится, но используйте комментарии в верхней части каждого файла JS для включения и выключения различных предупреждений, когда я знаю, что то, что я делаю, является подходящим. Затем мы запускаем jslint против всех наших JS как часть тестов CI, и он иногда ловит несколько простых ошибок, не беспокоясь о нас.