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

Tout d'abord, je tiens à mentionner que je sais comment isNaN()et Number.isNaN()travaille. Je lis le guide défini de David Flanagan et il donne un exemple pour savoir comment vérifier si la valeur est NaN:

x !== x

Cela se traduira par truesi et seulement si xest 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ûr d'utiliser les deux versions, ou il me manque une ou plusieurs valeurs dans JavaScript qui retourneront truepour x !== xet falsepour x != x?

Tout d'abord, permettez-moi de souligner que NaNc'est une valeur très spéciale: par définition, elle n'est pas égale à elle-même. Cela vient de la norme IEEE-754 sur laquelle s'appuient les numéros JavaScript. La valeur "pas un nombre" n'est jamais égale à elle-même, même lorsque les bits correspondent exactement. (Ce qu'ils ne sont pas nécessairement dans IEEE-754, cela permet plusieurs valeurs différentes "pas un nombre".) C'est pourquoi cela arrive même; toutes les autres valeurs en JavaScript sont égales à elles-mêmes, NaNc'est juste spécial.

... est-ce que je manque une valeur dans JavaScript qui retournera true pour x! == x et false pour x! = x?

Non, tu ne l'es pas. La seule différence entre !==et !=est que ce dernier effectuera une coercition de type si nécessaire pour que les types des opérandes soient identiques. Dans x != x, les types d'opérandes sont les mêmes, et donc exactement les mêmes que x !== x.

Ceci est clair dès le début de la définition de l' opération abstraite d'égalité :

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

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

   Renvoie le résultat de la comparaison d'égalité stricte x === y.

4. ...

Les deux premières étapes sont la plomberie de base. Donc, en fait, la toute première étape ==est de voir si les types sont les mêmes et, si c'est le cas, de le faire à la ===place. !=et ne !==sont que des versions niées de cela.

Donc, si Flanagan a raison, cela ne NaNdonnera vrai que pour x !== x, nous pouvons être sûrs qu'il est également vrai que seul NaNdonnera vrai pour x != x.

De nombreux programmeurs JavaScript utilisent par défaut ===et !==pour éviter certains pièges autour de la contrainte de type que font les opérateurs lâches, mais il n'y a rien à lire dans l'utilisation par Flanagan de l'opérateur strict vs lâche dans ce cas.

Pour les besoins de NaN, !=et !==faites la même chose.

Cependant, de nombreux programmeurs évitent ==ou !=en JavaScript. Par exemple, Douglas Crockford les considère parmi les « mauvaises parties » du langage JavaScript car ils se comportent de manière inattendue et déroutante:

JavaScript a deux ensembles d'opérateurs d'égalité: ===et !==, et leurs jumeaux diaboliques ==et !=. Les bons fonctionnent comme vous vous attendez.

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

Juste pour le plaisir, laissez-moi vous montrer un exemple artificiel où il xn'y en a pas, NaNmais les opérateurs se comportent de toute façon différemment. 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

Je veux juste souligner que ce NaNn'est pas la seule chose qui produit x !== xsans utiliser l'objet global. Il existe de nombreuses façons intelligentes de déclencher ce comportement. En voici un utilisant des getters:

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 le soulignent, ==effectue la coersion de type, mais comme dans d'autres langages et par la norme - NaN indique un échec de calcul, et pour de bonnes raisons n'est pas égal à lui-même.

Pour une raison autre que moi, les gens considèrent que c'est un problème avec JS, mais la plupart des langages qui ont des doubles (à savoir, C, Java, C ++, C #, Python et autres) présentent ce comportement exact et les gens sont très bien avec cela.

Comme parfois, les images valent mieux que les mots, vérifiez ce tableau (ce qui est la raison pour laquelle j'en fais une réponse plutôt qu'un commentaire, c'est parce qu'il obtient une meilleure visibilité).

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

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

Alors que la comparaison d'égalité abstraite (==) vérifie uniquement le contenu * en convertissant des types puis en les comparant strictement:

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

Bien que ce ne soit pas clair, sans consulter l' ECMA , ce que JavaScript prend en compte lors de la comparaison, d'une manière que le code ci-dessous évalue à vrai.

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