为什么JQuery不通过JSLint？
可能重复：
如果jQuery未通过validation，JSLint有什么用处
http://code.jquery.com/jquery-1.4.4.js
转到那里并将其粘贴到www.jslint.com
不是Jquery应该是有效的….
遵守它并且跨浏览器兼容是太多的工作。 JSLint很有用，但它只是一个通用的解析器。 jQuery有很好的理由在其中抛出错误。
有时你只需要简单的脏黑客就可以让代码在不兼容的浏览器中运行。
我们一个一个地看看它们：
第231行第20个问题：预期’===’而是看到’==’。
return num == null？
这里jquery使用== on null来检查undefined和null 。 由于jQuery被用作外部库，因此无法确定我们传递给函数的输入是undefined还是null 。 检查两者都更安全。
做num === undefined || num === null num === undefined || num === null来满足JSLint是荒谬的。
第446行的问题字符29：预期条件表达式而是看到一个赋值。
while（（fn = ready [i ++]））{
这里JSLint抱怨分配而不是等于检查。 JSLint抛出此错误的原因是因为它错误地键入=而不是== 。 在此while循环中分配是为了使代码更整洁。
第550行的问题字符9：空块。
var键; for（key in obj）{}
返回键=== undefined || hasOwn.call（obj，key）;
JSLint抱怨空的阻塞。 这里的目的是故意的，因为我们不想对key做任何事情，而是想要枚举所有密钥而只关心最后一个密钥。
第554行的问题字符15：将’var’声明移动到函数的顶部。
for（var name in obj）{
JSLint坚持在函数顶部使用变量声明。 这有点傻，如果你愿意可以忽略。 这是一种风格问题。
然后解析器崩溃了。 让我删除一些崩溃的代码，看看我是否能找到更多的投诉。
第792行的问题字符42：’&&’子表达式应该包含在parens中。
ua.indexOf（“compatible”）<0 && rmozilla.exec（ua）||
我(ua.indexO("compatile") < 0) &&同意这个(ua.indexO("compatile") < 0) &&更好。
第872行的问题字符3：将调用移动到包含该函数的parens中。
}）（）;
对于像这样的闭包：
(function() { })(); //}());
JSLint更喜欢在括号中看到函数invokion作为样式的问题。 我也同意这个，但它根本没关系。
第972行的问题字符13：'e'已经定义。
} catch（e）{
解析器抱怨变量e的重用在这种情况下我们知道e只会在catch块中本地使用，所以如果我们在catch块之外改变它就无所谓了。 在这里，我更喜欢重复使用变量名e的可读性
第1097行的问题字符21：预期'==='而是看到'=='。
elem = elem ==窗口？
好的，你抓住了我。 我很沮丧为什么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：在'案例'之后缺少'rest'。
案例“最后”：
JSLint说你应该总是在你的案件后rest。 案件结束后完全有效。 在大多数情况下，你忘了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'不好。
for（选项中的名称）{
这里JSLint抱怨使用name可能与全局范围内的window.name冲突。 这是一个“不太保留的未来关键字，但仍应该避免”。 是关闭所以它是安全的。
第2486行的问题字符29：错误太多。 （60％扫描）。
JSLint的内部堆栈无法处理它。 我现在要停下来。
我认为这一点已经说明了。
JSLint有很多“你确定你想要这样做吗”并告诉它是的我们想要这样做。 这可能看起来像是一个错误，但事实并非如此。
jslint使用的规则是指南 ，而不是牢不可破的规则。 您可能想要忽略其中一些原因的原因有很多。
有很多关于jslint规则的详细考虑因素 ; 很多人不同意这一点。
我个人喜欢它，但是当我知道我正在做的事情是合适的时候，使用每个JS文件顶部的注释来打开和关闭各种警告。 然后，我们对所有JS运行jslint作为CI测试的一部分，它偶尔会发现一些微不足道的错误，而不会给我们带来麻烦。