égalité - Quel opérateur égal(== vs===) devrait être utilisé dans les comparaisons JavaScript?




test égalité en javascript (20)

Cela signifie que l' égalité sans coercition de type coercition de type signifie que JavaScript ne convertit pas automatiquement les autres types de données en types de données chaîne.

0==false   // true,although they are different types

0===false  // false,as they are different types

2=='2'    //true,different types,one is string and another is integer but 
            javaScript convert 2 to string by using == operator 

2==='2'  //false because by using === operator ,javaScript do not convert 
           integer to string 

2===2   //true because both have same value and same types 

https://code.i-harness.com

J'utilise JSLint pour parcourir JavaScript, et il renvoie de nombreuses suggestions pour remplacer == (deux signes égaux) par === (trois signes égaux) lors de la comparaison de idSele_UNVEHtype.value.length == 0 intérieur d'un if déclaration.

Existe-t-il un avantage de performance à remplacer == par === ?

Toute amélioration des performances serait la bienvenue, car de nombreux opérateurs de comparaison existent.

Si aucune conversion de type n'a lieu, y aurait-il un gain de performance supérieur à == ?


Dans les réponses ici, je n'ai rien lu sur ce que signifie l' égalité . Certains diront que === signifie égal et du même type , mais ce n'est pas vraiment vrai. Cela signifie en réalité que les deux opérandes font référence au même objet ou, dans le cas de types de valeur, ont la même valeur .

Alors prenons le code suivant:

var a = [1,2,3];
var b = [1,2,3];
var c = a;

var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true

Pareil ici:

var a = { x: 1, y: 2 };
var b = { x: 1, y: 2 };
var c = a;

var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true

Ou même:

var a = { };
var b = { };
var c = a;

var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true

Ce comportement n'est pas toujours évident. L'histoire ne se résume pas à l'égalité et au même type.

La règle est la suivante:

Pour les types de valeur (nombres):
a === b retourne vrai si a et b ont la même valeur et sont du même type

Pour les types de référence:
a === b retourne vrai si a et b font exactement le même objet

Pour les cordes:
a === b retourne vrai si a et b sont les deux chaînes et contiennent exactement les mêmes caractères

Cordes: le cas particulier ...

Les chaînes ne sont pas des types de valeur, mais en Javascript, elles se comportent comme des types de valeur. Elles sont donc "égales" lorsque les caractères de la chaîne sont identiques et de la même longueur (comme expliqué dans la troisième règle).

Maintenant cela devient intéressant:

var a = "12" + "3";
var b = "123";

alert(a === b); // returns true, because strings behave like value types

Mais qu'en est-il de ça ?:

var a = new String("123");
var b = "123";

alert(a === b); // returns false !! (but they are equal and of the same type)

Je pensais que les chaînes se comportaient comme des types de valeur? Cela dépend de qui vous demandez ... Dans ce cas, a et b ne sont pas du même type. a est de type Object , tandis que b est de type string . Rappelez-vous simplement que la création d'un objet chaîne à l'aide du constructeur String crée quelque chose de type Object qui se comporte la plupart du temps comme une chaîne.


Diagramme de flux d'exécution Javascript pour l'égalité stricte / Comparaison '==='

Diagramme de flux d'exécution Javascript pour l'égalité / comparaison non stricte '=='


En JavaScript, cela signifie de la même valeur et du même type.

Par exemple,

4 == "4" // will return true

mais

4 === "4" // will return false 

Il est peu probable qu'il y ait une différence de performances entre les deux opérations dans votre utilisation. Il n'y a pas de conversion de type à faire car les deux paramètres sont déjà du même type. Les deux opérations auront une comparaison de type suivie d'une comparaison de valeur.


Il vérifie si les mêmes côtés sont de même type et valeur .

Exemple:

'1' === 1 // will return "false" because `string` is not a `number`

Exemple commun:

0 == ''  // will be "true", but it's very common to want this check to be "false"

Un autre exemple courant:

null == undefined // returns "true", but in most cases a distinction is necessary

JavaScript === vs == .

0==false   // true
0===false  // false, because they are of a different type
1=="1"     // true, auto type coercion
1==="1"    // false, because they are of a different type

L'opérateur === est appelé opérateur de comparaison strict, il diffère de l'opérateur == .

Prenons 2 vars a et b.

Pour que "a == b" soit évalué à true, il faut que la valeur soit la même .

Dans le cas de "a === b", a et b doivent avoir la même valeur et le même type pour que l'évaluation soit vraie.

Prenons l'exemple suivant

var a = 1;
var b = "1";

if (a == b) //evaluates to true as a and b are both 1
{
    alert("a == b");
}

if (a === b) //evaluates to false as a is not the same type as b
{
    alert("a === b");
}

En résumé ; L'utilisation de l'opérateur == peut donner la valeur true dans les cas où vous ne le souhaitez pas. L'utilisation de l'opérateur === serait donc plus sûre.

Dans le scénario d'utilisation à 90%, le type d'utilisation importe peu, mais il est utile de connaître la différence lorsqu'un jour ou l'autre vous avez un comportement inattendu.


Permettez-moi d'ajouter ce conseil:

En cas de doute, lisez le specification des specification !

ECMA-262 est la spécification d'un langage de script dont JavaScript est un dialecte. Bien entendu, dans la pratique, le comportement des principaux navigateurs est plus important qu'une définition ésotérique de la manière dont quelque chose est censé être géré. Mais il est utile de comprendre pourquoi la nouvelle chaîne ("a")! == "a" .

Laissez-moi vous expliquer comment lire le cahier des charges pour clarifier cette question. Je vois que dans ce très vieux sujet, personne n’a eu de réponse pour cet effet très étrange. Donc, si vous pouvez lire un cahier des charges, cela vous aidera énormément dans votre profession. C'est une compétence acquise. Alors continuons.

Rechercher le fichier PDF pour === me conduit à la page 56 du cahier des charges: 11.9.4. L'opérateur Strict Equals (===) , et après avoir parcouru le spécalese, je trouve:

11.9.6 Algorithme de comparaison d'égalité stricte
La comparaison x === y, où x et y sont des valeurs, produit true ou false . Une telle comparaison est effectuée comme suit:
1. Si le type (x) est différent du type (y), retournez false .
2. Si Type (x) est Non défini, retournez true .
3. Si Type (x) est null, renvoyer true .
4. Si le type (x) n'est pas un nombre, passez à l'étape 11.
5. Si x est NaN , retourne false .
6. Si y est NaN , retourne false .
7. Si x est le même nombre que la valeur y, renvoyez true .
8. Si x est +0 et y est -0, retourne vrai .
9. Si x est −0 et y est +0, retourne vrai .
10. Retourne faux .
11. Si Type (x) est String, retournez true si x et y sont exactement la même séquence de caractères (même longueur et mêmes caractères aux positions correspondantes); sinon, retourne faux .
12. Si Type (x) est booléen, retourne vrai si x et y sont tous les deux vrais ou tous les deux faux ; sinon, retourne faux .
13. Renvoie true si x et y se rapportent au même objet ou s’ils se rapportent à des objets joints les uns aux autres (voir 13.1.2). Sinon, retourne false .

L'étape 11 est intéressante. Oui, les chaînes sont traitées comme des types de valeur. Mais cela n'explique pas pourquoi new String ("a")! == "a" . Avons-nous un navigateur non conforme à ECMA-262?

Pas si vite!

Vérifions les types des opérandes. Essayez-le vous-même en les enveloppant dans typeof () . Je trouve que new String ("a") est un objet et l’étape 1 est utilisée: renvoyer false si les types sont différents.

Si vous vous demandez pourquoi la nouvelle chaîne ("a") ne renvoie pas de chaîne, pourquoi ne pas vous exercer à lire une spécification? S'amuser!

Aidiakapi a écrit ceci dans un commentaire ci-dessous:

De la spécification

11.2.2 Le nouvel opérateur :

Si Type (constructeur) n'est pas Object, lève une exception TypeError.

En d'autres termes, si String ne serait pas de type Object, il ne pourrait pas être utilisé avec le nouvel opérateur.

new renvoie toujours un objet, même pour les constructeurs String . Et hélas! La sémantique des valeurs pour les chaînes (voir l’étape 11) est perdue.

Et cela signifie enfin: new String ("a")! == "a" .


Une représentation picturale intéressante de la comparaison d'égalité entre == et === .

Source: dorey.github.io/JavaScript-Equality-Table

var1 === var2

Lors de l'utilisation de === pour le test d'égalité JavaScript, tout est tel quel. Rien n'est converti avant d'être évalué.

var1 == var2

Lors de l'utilisation de == pour le test d'égalité JavaScript, certaines conversions géniales ont lieu.

Morale de l'histoire:

Utilisez === moins de bien comprendre les conversions effectuées avec == .


Comparaison d'égalité:

Opérateur ==

Renvoie true lorsque les deux opérandes sont égaux. Les opérandes sont convertis dans le même type avant d'être comparés.

>>> 1 == 1
true
>>> 1 == 2
false
>>> 1 == '1'
true

Égalité et comparaison de types:

Opérateur ===

Renvoie true si les deux opérandes sont égaux et du même type. C'est généralement mieux et plus sûr si vous comparez de la sorte, car il n'y a pas de conversions en arrière-plan.

>>> 1 === '1'
false
>>> 1 === 1
true

=== L’opérateur vérifie l’égalité des valeurs ainsi que des types de variables.

== l'opérateur vérifie simplement la valeur des variables pour l'égalité.


Oui! Ça compte.

===javascript vérifie la valeur ainsi que le type==opérateur vérifie simplement la valeur (la conversion de type est requise si nécessaire) .

Vous pouvez facilement le tester. Collez le code suivant dans un fichier HTML et ouvrez-le dans le navigateur

<script>

function onPageLoad()
{
    var x = "5";
    var y = 5;
    alert(x === 5);
};

</script>

</head>

<body onload='onPageLoad();'>

Vous obtiendrez " faux " en alerte. Maintenant, modifiez la onPageLoad()méthode pour que alert(x == 5);vous deveniez vrai .


Pourquoi == est si imprévisible?

Qu'est-ce que vous obtenez lorsque vous comparez une chaîne vide "" avec le nombre zéro 0 ?

true

Oui, c'est exact selon == une chaîne vide et le nombre zéro sont en même temps.

Et cela ne s'arrête pas là, en voici un autre:

'0' == false // true

Les tableaux deviennent vraiment bizarres.

[1] == true // true
[] == false // true
[[]] == false // true
[0] == false // true

Puis plus bizarre avec des cordes

[1,2,3] == '1,2,3' // true - REALLY?!
'\r\n\t' == 0 // true - Come on!

Ça a empiré:

Quand est égal pas égal?

let A = ''  // empty string
let B = 0   // zero
let C = '0' // zero string

A == B // true - ok... 
B == C // true - so far so good...
A == C // **FALSE** - Plot twist!

Laissez-moi répéter ça:

(A == B) && (B == C) // true
(A == C) // **FALSE**

Et ceci est juste le truc fou que vous obtenez avec les primitifs.

C'est un tout nouveau niveau de fou lorsque vous utilisez == avec des objets.

À ce stade, vous vous demandez probablement ...

Pourquoi cela arrive-t-il?

Eh bien, c’est parce que contrairement à "triple égal" ( === ), qui vérifie si deux valeurs sont identiques.

== fait tout un tas d'autres choses .

Il a un traitement spécial pour les fonctions, un traitement spécial pour les valeurs null, indéfini, les chaînes, vous le nommez.

Ça devient plutôt délirant.

En fait, si vous essayez d’écrire une fonction qui fait quoi == cela ressemblerait à ceci:

function isEqual(x, y) { // if `==` were a function
    if(typeof y === typeof x) return y === x;
    // treat null and undefined the same
    var xIsNothing = (y === undefined) || (y === null);
    var yIsNothing = (x === undefined) || (x === null);

    if(xIsNothing || yIsNothing) return (xIsNothing && yIsNothing);

    if(typeof y === "function" || typeof x === "function") {
        // if either value is a string 
        // convert the function into a string and compare
        if(typeof x === "string") {
            return x === y.toString();
        } else if(typeof y === "string") {
            return x.toString() === y;
        } 
        return false;
    }

    if(typeof x === "object") x = toPrimitive(x);
    if(typeof y === "object") y = toPrimitive(y);
    if(typeof y === typeof x) return y === x;

    // convert x and y into numbers if they are not already use the "+" trick
    if(typeof x !== "number") x = +x;
    if(typeof y !== "number") y = +y;
    // actually the real `==` is even more complicated than this, especially in ES6
    return x === y;
}

function toPrimitive(obj) {
    var value = obj.valueOf();
    if(obj !== value) return value;
    return obj.toString();
}

Qu'est-ce que cela signifie?

Cela signifie que == est compliqué.

Parce que c'est compliqué, il est difficile de savoir ce qui va arriver quand vous l'utilisez.

Ce qui signifie que vous pourriez vous retrouver avec des bugs.

Donc, la morale de l'histoire est ...

Rendez votre vie moins compliquée.

Utilisez === au lieu de == .

La fin.


Le problème est que vous pourriez facilement avoir des problèmes, car JavaScript a beaucoup de conversions implicites, ce qui signifie ...

var x = 0;
var isTrue = x == null;
var isFalse = x === null;

Ce qui devient vite un problème. Le meilleur exemple de la raison pour laquelle la conversion implicite est "diabolique" peut être tiré de ce code en MFC / C ++ qui sera compilé en raison d'une conversion implicite de CString en HANDLE qui est un type de pointeur typedef ...

CString x;
delete x;

Ce qui évidemment pendant l'exécution fait des choses très indéfinies ...

Google pour les conversions implicites en C ++ et STL pour obtenir certains des arguments contre elle ...


Simplement

==signifie comparaison entre opérandes avec type conversion

Et

===signifie comparaison entre opérandes sans type conversion

La conversion de type en javaScript signifie que javaScript convertit automatiquement tous les autres types de données en types de données string.

Par exemple:

123=='123'   //will return true, because JS convert integer 123 to string '123'
             //as we used '==' operator 

123==='123' //will return false, because JS do not convert integer 123 to string 
            //'123' as we used '===' operator 

null et indéfini sont le néant, c'est-à-dire

var a;
var b = null;

Ici aet bne pas avoir de valeurs. Alors que 0, faux et '' sont tous des valeurs. Une chose commune entre tous ceux-ci est que ce sont toutes des valeurs fausses, ce qui signifie qu'elles répondent toutes à des conditions fausses.

Donc, 0, faux et '' ensemble forment un sous-groupe. Et d'autre part, null & indéfini forment le deuxième sous-groupe. Vérifiez les comparaisons dans l'image ci-dessous. null et undefined seraient égaux. Les trois autres seraient égaux. Mais, ils sont tous traités comme des conditions de fausseté en JavaScript.

Ceci est identique à tout objet (comme {}, tableaux, etc.), une chaîne non vide et un booléen vrai sont toutes des conditions de vérité. Mais ils ne sont pas tous égaux.



En règle générale, je voudrais généralement utiliser ===au lieu de ==(et !==au lieu de !=).

Les raisons sont expliquées dans les réponses ci-dessus et Douglas Crockford est assez clair à ce sujet ( JavaScript: The Good Parts ).

Cependant, il y a une seule exception : == nullest un moyen efficace de vérifier 'est nul ou non défini':

if( value == null ){
    // value is either null or undefined
}

Par exemple, jQuery 1.9.1 utilise ce modèle 43 fois, et le vérificateur de syntaxe JSHint fournit même l' eqnulloption de relaxation pour cette raison.

Du guide de style jQuery :

Des contrôles d'égalité stricts (===) doivent être utilisés en faveur de ==. La seule exception concerne la vérification de non défini et null par null.

// Check for both undefined and null values, for some important reason. 
undefOrNull == null;

JSLint vous donne parfois des raisons irréalistes de modifier des éléments. ===a exactement les mêmes performances que ==si les types sont déjà les mêmes.

Il est plus rapide que lorsque les types ne sont pas identiques, auquel cas il ne tente pas de convertir les types mais renvoie directement un false.

Donc, à mon humble avis , JSLint est peut-être habitué à écrire du nouveau code, mais une sur-optimisation inutile devrait être évitée à tout prix.

Signification, il n'y a aucune raison de changer ==d' ===un chèque comme if (a == 'test')quand vous savez pour un fait que ne peut être une chaîne.

Modifier beaucoup de code de cette façon fait perdre du temps aux développeurs et aux relecteurs et ne produit rien.





identity-operator