Quelle est la différence entre (NaN ! = NaN) et (NaN ! == NaN) ?

Question

Tout d'abord, je tiens à mentionner que je sais comment isNaN() et Number.isNaN() de travail. Je suis de la lecture Définitive du Guide par David Flanagan et il donne un exemple de la façon de vérifier si la valeur est NaN:

x !== x

Ce sera résultat en true si et seulement si x est NaN.

Mais maintenant j'ai une question: pourquoi utilise-t-il une comparaison stricte? Parce qu'il semble que

x != x

se comporte de la même manière. Est-il sécuritaire d'utiliser les deux versions, ou il me manque une certaine valeur(s) dans le JavaScript qui sera de retour true pour x !== x et false pour x != x?

Answer 1

...je manque un peu de valeur en JavaScript qui retourne true, pour x !== x et fausse pour x != x?

Non, vous n'êtes pas. La seule différence entre !== et != , c'est que ce dernier va faire de ce type de coercition si nécessaire pour obtenir les types des opérandes de même. En x != x, les types des opérandes sont les mêmes, et donc c'est exactement la même que x !== x.

C'est clair depuis le début de la définition de l' Abstrait, de l'Égalité de l'Opération:

1. ReturnIfAbrupt(x).
2. ReturnIfAbrupt(y).

3. Si le Type(x) est le même que le Type(y), alors

   Retourner le résultat de l'exécution Stricte Comparaison d'Égalité x === y.

4. ...

Les deux premières étapes sont à la base de la plomberie. En effet, la première étape de == est de voir si les types sont les mêmes et, si oui, à n' === à la place. != et !== sont tout simplement annulés versions de l'.

Donc, si Flanagan est exact que seulement NaN donne le vrai pour x !== x, on peut être sûr que c'est vrai aussi que seulement NaN donne le vrai pour x != x.

De nombreux programmeurs JavaScript par défaut à l'aide d' === et !== pour éviter quelques pièges autour de la contrainte de type souple, opérateurs de le faire, mais il n'y a rien à lire dans Flanagan utilisation de la stricte vs loose opérateur dans ce cas.

Answer 2

Pour les fins de l'NaN, != et !== faire la même chose.

Cependant, de nombreux programmeurs éviter == ou != en JavaScript. Par exemple, Douglas Crockford considère parmi les "mauvais" du langage JavaScript, car ils se comportent dans l'inattendu et déroutant façons:

JavaScript a deux ensembles d'opérateurs d'égalité: === et !==, et leurs jumeaux maléfiques == et !=. Les bons de travail de la façon que vous attendez.

...Mon conseil est de ne jamais utiliser les evil twins. Au lieu de cela, utilisez toujours === et !==.

Answer 3

Juste pour le plaisir, laissez-moi vous montrer un exemple artificiel où x n'est pas NaN mais les opérateurs se comportent différemment de toute façon. Définissez d'abord:

 Object.defineProperty(
  self,
  'x',
  { get: function() { return self.y = self.y ? 0 : '0'; } }
);
 

Ensuite nous avons

 x != x // false
 

mais

 x !== x // true
 

Answer 4

Je veux juste souligner NaN n'est pas la seule chose qui produit de l' x !== x sans l'aide de l'objet global. Il y a beaucoup de moyens astucieux pour déclencher ce problème. Ici est en utilisant les méthodes de lecture:

var i = 0, obj = { get x() { return i++; }};
with(obj) // force dynamic context, this is evil. 
console.log(x === x); // false

Comme d'autres réponses point, == effectue ce type encore de la contrainte, mais aussi dans d'autres langues et par la norme - NaN indique un calcul d'échec, et pour de bonnes raisons, n'est pas égale à elle-même.

Pour une raison quelconque au-delà de moi des gens qui ocnsider-ce un problème avec JS, mais la plupart des langues qui ont des doubles (à savoir, C, Java, C++, C#, Python et autres) présentent ce comportement exact et les gens sont juste très bien avec elle.

Answer 5

Parfois, les images valent mieux que des mots, cochez cette table (qui est la raison pour moi de faire une réponse au lieu d'un commentaire, c'est parce qu'il obtient une meilleure visibilité).

Là vous pouvez voir que la stricte égalité de comparaison (===) ne renvoie vrai si le type et le contenu du match, donc

var f = "-1" === -1; //false

Tout abstrait comparaison d'égalité (==) vérifie seulement le contenu* par conversion de types, puis strictement les comparer:

var t = "-1" == -1; //true

Si ce n'est pas clair, sans consultation de l' ECMA, du JavaScript qui considère que lors de la comparaison, de manière à ce que le code soufflet est évaluée à true.

 var howAmISupposedToKnowThat = [] == false; //true