为什么JQuery不通过JSLint？ [英] How come JQuery doesn't pass JSLint?

问题描述

可能重复：

如果jQuery验证失败，JSLint有什么用？

Possible Duplicate:
What good is JSLint if jQuery fails the validation

http://code.jquery.com/jquery-1.4 .4.js

转到那里并将其粘贴到www.jslint.com

Go to there and paste it in www.jslint.com

是不是Jquery应该是有效的....

Isn't Jquery supposed to be valid....

推荐答案

遵守它是太多的工作 AND 符合跨浏览器标准。 JSLint很有用，但它只是一个通用的解析器。 jQuery有很好的理由在其中抛出错误。

It's far too much work to comply with it AND be cross-browser compliant. JSLint is useful but its only a generic parser. jQuery has good reasons to throw errors in it.

有时你只需要简单的脏黑客就可以让代码在不兼容的浏览器中运行。

Sometimes you just need simple dirty hacks to get code working in non-compliant browsers.

让我们一个一个地看看它们：

let's look at them one by one :

第231行问题字符20：
预计' ==='而是看到'=='。

Problem at line 231 character 20: Expected '===' and instead saw '=='.

return num == null？

return num == null ?

这里jquery在 null 上使用 == 来检查 undefined 和 null 。由于jQuery被用作外部库，因此无法确认我们传递给函数的输入是 undefined 还是 null 。检查两者都更安全。

Here jquery uses == on null to check for both undefined and null. Since jQuery is used as an external library it can't garantuee whether the input we pass to functions will be undefined or null. It is safer for it check for both.

执行 num === undefined || num === null 来满足JSLint是荒谬的。

Doing num === undefined || num === null to satisfy JSLint is ridiculous.

第446行问题29：
预期条件表达式和
而不是看到一个赋值。

Problem at line 446 character 29: Expected a conditional expression and instead saw an assignment.

while（（fn = ready [i ++]））{

while ( (fn = ready[ i++ ]) ) {

这里JSLint抱怨赋值而不是equals check。 JSLint抛出此错误的原因是错误地输入 = 而不是 == 。在此while循环中分配是为了使代码更整洁。

Here JSLint complains about assignment instead of equals check. The reason JSLint throws this error is because its common to type = instead of == by mistake. Assigning in this while loop is done on purpose to make the code neater.

第550行的问题字符9：清空
块。

Problem at line 550 character 9: Empty block.

var key; for（key in obj）{}

return key === undefined ||
hasOwn.call（obj，key）;

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

JSLint抱怨空的块。这里的目的是故意的，因为我们不想对 key 做任何事情，而是想要枚举所有键，只关心最后一个键。

JSLint complains about an empty for block. This here has been done on purpose because we don't want to do anything with key instead we want to enumerate over all the keys and only care about the last one.

第554行的问题字符15：将
'var'声明移到
函数的顶部。

Problem at line 554 character 15: Move 'var' declarations to the top of the function.

for（var ob name in obj）{

for ( var name in obj ) {

JSLint坚持要求变量声明功能的顶部。这有点傻，如果你愿意可以忽略。这是一个风格问题。

JSLint insists on having variables declaration at the top of functions. This is a bit silly and can be ignored if you want to. It's a matter of style.

然后解析器崩溃了。让我删除一些崩溃的代码，看看我是否能找到更多的投诉。

And then the parser crashes. Let me remove some of the code crashing it and see if I can find more complaints.

第792行问题42：
'&&'子表达式应包含
的parens。

Problem at line 792 character 42: The '&&' subexpression should be wrapped in parens.

ua.indexOf（compatible）< 0&&
rmozilla.exec（ua）||

ua.indexOf("compatible") < 0 && rmozilla.exec( ua ) ||

我真的同意这个（ua。 indexO（compatiblele）< 0）&& 更好。

第872行的问题字符3：将
的调用移动到
包含该函数的parens中。

Problem at line 872 character 3: Move the invocation into the parens that contain the function.

}）（）;

对于以下闭包：

(function() {

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

JSLint更喜欢在方括号中看到括号中的函数invokion。我也同意这一点，但它确实无关紧要。

JSLint prefers to see the function invokion in the brackets as a matter of style. I also agree with this one but it really doesn't matter at all.

第972行的问题字符13：'e'
已经定义。

Problem at line 972 character 13: 'e' is already defined.

} catch（e）{

} catch(e) {

Parser抱怨重用变量 e 在这种情况下，我们知道 e 只会在本地使用因此，如果我们在catch块之外改变它就无所谓了。在这里，我更喜欢重复使用变量名的可读性 e

Parser is complaining about the reuse of variable e In this case we know that e will only be used locally in that catch block so it doesnt matter if we alter it outside the catch block. Here I prefer the readability of re-using the variable name e

问题所在第1097行第21行：
预期'==='而是看到'=='。

Problem at line 1097 character 21: Expected '===' and instead saw '=='.

elem = elem == window？

elem = elem == window ?

好的，你抓住了我。我很遗憾为什么jQuery不在窗口上使用 ===

Ok, you caught me on this one. I'm stumbed as to why jQuery doesn't use === on window

第1621行的问题字符24：
预期分配或函数
调用而是看到一个表达式。

Problem at line 1621 character 24: Expected an assignment or function call and instead saw an expression.

parent.selectedIndex;

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;

以下是可以修复但导致错误的跨浏览器合规性错误之一代码

Here's one of those cross-browser compliancy bugs that can be fixed but causes bad code

第977行的问题字符17：
在案例之后缺少休息 。

Problem at line 977 character 17: Missing 'break' after 'case'.

案例最后：

JSLint说你应该总是打破在您的案件之后。案件结束后完全有效。在大多数情况下，你忘了 break 但这里是故意的。

JSLint says you should always break after your cases. It's perfectly valid to drop through after a case. In most cases you forgot to break but here this is intentional.

问题在于第1099行第77行：
预期赋值或函数
调用而是看到一个表达式。

Problem at line 1099 character 77: Expected an assignment or function call and instead saw an expression.

Array.prototype.slice.call（
document.documentElement.childNodes，0
）[0] .node ...

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告诉你你真的有意这样做吗？

The source here speaks for itself. It's a weird statement but if accessing it like this throws an error then it can be caught. It's still valid just JSLint tells you "did you really mean to do this?"

第2377行问题15：Bad
代表变量'name'。

Problem at line 2377 character 15: Bad for in variable 'name'.

for（选项中的名称）{

for ( name in options ) {

这里JSLint抱怨使用 name ，这可能与全局范围内的 window.name 冲突。这是一个不太保留的未来关键词，但仍应该避免。处于关闭状态，所以它是安全的。

Here JSLint complains about the use of name which can conflict with window.name in global scope. It's a "not quite reserved future keyword but still should be avoided". Were in a closure so it's safe.

2486行问题29：太多b $ b很多错误。 （60％扫描）。

Problem at line 2486 character 29: Too many errors. (60% scanned).

JSLint的内部堆栈无法处理它。我现在要停下来。

JSLint's internal stack can't handle it. I'm going to stop now.

我认为这一点已经说明了。

I think the point is illustrated.

JSLint有很多你确定要这么做吗并告诉它是的我们想要这样做。它可能看起来像是一个错误，但事实并非如此。

JSLint has a lot of "Are you sure you want to do this" And were telling it yes we want to do this. It might look like a mistake but it's not.

这篇关于为什么JQuery不通过JSLint？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！