javascript - SonarQube 建议 an!==a 而不是 a===MaN

Question

有一个 SonarQube JavaScript 规则 (javascript:S2688) 表明使用 a === NaN 是一个错误，因为它总是 false。

我同意这一点，但我认为使用 a !== a 代替(这是 SonarQube 建议的)是一个非常糟糕的主意。这是一个有趣的 JavaScript 事实，但肯定不是“最佳实践”。

Number.isNaN(a) 呢？为什么这不是建议的解决方案？是否有任何我遗漏的差异或问题？

Answer 1

the use of a === NaN is a bug because it's always false.

此行为 不是错误，因为它是 NaN 的方式已被定义为工作。但是如果你真的使用了a === NaN在程序中，那 将是一个错误，因为总是- false结果。

a !== a instead ... is a very bad idea. It's a funny JavaScript fact but certainly not a "best practice".

我不同意你的“当然”。由于原全局问题isNaN()函数(我稍后会解释)，a !== a从历史上看，这是测试 NaN 的最佳方式.所以实际上使用该技术是一种非常普遍的做法，我希望绝大多数有经验的 JavaScript 开发人员都熟悉它。

NaN 是唯一测试为不等于自身的值。

What about isNaN(a)? Why is this not the suggested solution? Are there any differences or problems which I've missed?

原创，全局 isNaN() function 实际上并不测试其参数是否为 NaN . 它也不会测试它的参数是否是其他一些非数字值。它所做的是首先尝试将其参数转换为数字，然后测试该转换的结果是否等于 NaN。 .这种隐式转换意味着，例如 isNaN("test")返回 true即使字符串不等于值 NaN .和 isNaN("")返回 false因为可以将空字符串强制转换为 0 .如果您正在寻找这种行为，那么是的，请使用 isNaN() .

因此，所有这些都是 ECMAScript 6/2015 引入新函数 Number.isNaN() 的原因，它专门测试值NaN ，给出了与老派相当的结果a !== a .

如评论中所建议，对于不支持 Number.isNaN() 的旧版浏览器(基本上是旧版 IE) , 如果你想要比 a !== a 更清楚的东西不要介意更长的代码，你可以这样做:

typeof a == "number" && isNaN(a)

...这是两个 Number.isNaN() polyfills suggested by MDN 之一. (另一个只使用 a !== a 。)