为啥 JQuery 不通过 JSLint？ [复制]

Posted 2023-02-22

【中文标题】为啥 JQuery 不通过 JSLint？ [复制]

【英文标题】：How come JQuery doesn't pass JSLint? [duplicate]为什么 JQuery 不通过 JSLint？ [复制]

【发布时间】：2011-06-18 07:48:42

【问题描述】：

可能重复：What good is JSLint if jQuery fails the validation

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

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

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

【问题讨论】：

之前有人问过这个问题。 ***.com/questions/505251/…

JSLint 与有效性无关。它更多地是关于编码约定。这就是我的观点。

【参考方案1】：

要遵守它并且要跨浏览器兼容，工作量太大了。 JSLint 很有用，但它只是一个通用解析器。 jQuery 有充分的理由在其中抛出错误。

有时您只需要简单的肮脏技巧就可以让代码在不兼容的浏览器中运行。

让我们一一来看：

第 231 行字符 20 处的问题： 应为“===”，但看到的是“==”。

返回 num == null ?

这里 jQuery 在null 上使用== 来检查undefined 和null。由于 jQuery 被用作外部库，它不能保证我们传递给函数的输入是undefined 还是null。两者都检查比较安全。

为了满足 JSLint 而做num === undefined || num === null 是荒谬的。

第 446 行字符 29 处的问题： 期望一个条件表达式和 而是看到了一个作业。

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

这里 JSLint 抱怨分配而不是等于检查。 JSLint 抛出此错误的原因是错误地键入 = 而不是 == 很常见。在这个while循环中赋值是为了让代码更整洁。

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

变量键； for ( obj 中的键) 返回键 === 未定义 || hasOwn.call(obj, key);

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

第 554 行字符 15 处的问题：移动 'var' 声明到顶部 功能。

for（obj 中的变量名）

JSLint 坚持在函数顶部声明变量。这有点愚蠢，如果您愿意，可以忽略。这是风格问题。

然后解析器崩溃了。让我删除一些导致它崩溃的代码，看看我是否能找到更多的抱怨。

第 792 行字符 42 处的问题： '&&' 子表达式应该被包装 在括号中。

ua.indexOf("兼容")

我其实同意这个(ua.indexO("compatile") < 0) &&更好。

第 872 行字符 3 处的问题：移动 对括号的调用 包含函数。

)();

对于像这样的闭包：

(function() 
  
)();
//());

JSLint 更喜欢将括号中的函数调用视为样式问题。我也同意这一点，但这根本不重要。

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

捕捉（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 处的问题： 在“case”之后缺少“break”。

案例“最后一个”：

JSLint 说你应该总是在你的案件之后休息。在案件发生后放弃是完全有效的。在大多数情况下，您忘记了break，但这是故意的。

第 1099 行字符 77 处的问题： 期望分配或功能 调用，而是看到了一个表达式。

Array.prototype.slice.call( 文档.documentElement.childNodes，0 )[0].节点...

// 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 处的问题：错误 用于变量“名称”。

for（选项中的名称）

这里 JSLint 抱怨 name 的使用可能与全局范围内的 window.name 冲突。这是一个“不完全保留的未来关键字，但仍应避免”。处于封闭状态，因此很安全。

第 2486 行字符 29 处的问题：太 许多错误。 （60% 已扫描）。

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

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

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

【讨论】：

我不同意这是邪恶的； jslint 很有用，您只需记住它遵循的规则是指导方针，以了解错误和警告的含义以及何时可以忽略它。

@ElYobo 你的权利。我对 JSLint 有点苛刻。

这是否意味着每个浏览器中都有(null == undefined) === true？

这是一个非常详细的细分，+1：D

我知道我已经落后于时代了，但是……“做 num === undefined || num === null 来满足 JSLint 是荒谬的。”我认为除了满足 JSLint 之外，还有其他理由这样做。相等运算符可能会令人困惑，我认为更明确会使代码更具可读性。根据我的经验，新开发人员从未意识到 undefined == null。

【参考方案2】：

jslint 使用的规则是准则，而不是牢不可破的规则。您可能想忽略其中的一些原因有很多。

那里有很多detailed considerations of jslint rules；很多人不同意。

就个人而言，我喜欢它，但是当我知道我正在做的事情是合适的时候，使用每个 JS 文件顶部的 cmets 来打开和关闭各种警告。然后，作为 CI 测试的一部分，我们针对所有 JS 运行 jslint，它不时地捕捉到一些琐碎的错误，而通常不会打扰我们。

【讨论】：

即使打开和关闭各种设置，JSLint 仍然会在某些事情上引发错误，但这些事情是您真正想要做的。您对 JSLint 没有足够的控制权。

我在我们的测试中添加了一个额外的标志，以便完全跳过 jslint 在我想要做的事情的组件上，它真的不喜欢 :) 我发现，无论如何，根据我的口味，次要的遵守 jslint 的开销是值得的，因为它捕获的东西以及以与 phpcs 对我们的服务器端代码相同的方式强制执行一致的样式

迟来的更新：jshint 提供类似的检查，但灵活性更大。