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




différence égalité (25)

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.

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 à == ?


Utilisation de l'opérateur == ( égalité )

true == 1; //true, because 'true' is converted to 1 and then compared
"2" == 2;  //true, because "2" is converted to 2 and then compared

Utilisation de l'opérateur === ( identité )

true === 1; //false
"2" === 2;  //false

En effet, l' opérateur d'égalité == contrainte , ce qui signifie que l'interpréteur tente implicitement de convertir les valeurs avant la comparaison.

D'autre part, l' opérateur d'identité === ne fait pas de contrainte de type et ne convertit donc pas les valeurs lors de la comparaison.


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 PHP et JavaScript, c'est un opérateur d'égalité stricte. Ce qui signifie qu’il comparera à la fois le type et les valeurs.


Les deux premières réponses à la fois mentionnées == signifie l'égalité et === signifie identité. Malheureusement, cette déclaration est incorrecte.

Si les deux opérandes de == sont des objets, ils sont comparés pour voir s’ils sont le même objet. Si les deux opérandes pointent sur le même objet, l'opérateur égal renvoie true. Sinon, les deux ne sont pas égaux.

var a = [1, 2, 3];  
var b = [1, 2, 3];  
console.log(a == b)  // false  
console.log(a === b) // false  

Dans le code ci-dessus, == et === deviennent faux car a et b ne sont pas les mêmes objets.

Autrement dit: si les deux opérandes de == sont des objets, == se comporte comme ===, ce qui signifie également identité. La différence essentielle de ces deux opérateurs concerne la conversion de type. == a une conversion avant de vérifier l’égalité, mais pas ===.


J'ai testé cela dans Firefox avec Firebug utilisant un code comme celui-ci:

console.time("testEquality");
var n = 0;
while(true) {
    n++;
    if(n==100000) 
        break;
}
console.timeEnd("testEquality");

et

console.time("testTypeEquality");
var n = 0;
while(true) {
    n++;
    if(n===100000) 
        break;
}
console.timeEnd("testTypeEquality");

Mes résultats (testés cinq fois chacun et moyennés):

==: 115.2
===: 114.4

Je dirais donc que la différence minuscule (plus de 100 000 itérations, rappelez-vous) est négligeable. La performance n'est pas une raison pour faire === . Tapez la sécurité (enfin, aussi sûr que vous allez obtenir en JavaScript), et la qualité du code est.


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

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.


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 == .


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 

C'est un test de contrôle strict.

C'est une bonne chose, surtout si vous vérifiez entre 0 et false et null.

Par exemple, si vous avez:

$a = 0;

Ensuite:

$a==0; 
$a==NULL;
$a==false;

Tout retourne vrai et vous ne voudrez peut-être pas cela. Supposons que vous ayez une fonction pouvant renvoyer le 0ème index d'un tableau ou false en cas d'échec. Si vous vérifiez avec "==" false, vous pouvez obtenir un résultat déroutant.

Donc, avec la même chose que ci-dessus, mais un test strict:

$a = 0;

$a===0; // returns true
$a===NULL; // returns false
$a===false; // returns false

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

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;

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" .


L'opérateur d'identité ( === ) se comporte de manière identique à l'opérateur d'égalité ( == ), sauf qu'aucune conversion de type n'est effectuée et que les types doivent être identiques pour être considérés comme égaux.

Référence: tutoriel Javascript: opérateurs de comparaison

L'opérateur == comparera pour l'égalité après avoir effectué les conversions de type nécessaires . L'opérateur === ne fera pas la conversion. Par conséquent, si deux valeurs ne sont pas du même type, === renverra simplement false . Les deux sont également rapides.

Pour citer l'excellent JavaScript de Douglas Crockford : The Good Parts ,

JavaScript a deux ensembles d'opérateurs d'égalité: === et !== , et leurs jumeaux diaboliques == et != . Les bons fonctionnent comme vous le souhaiteriez. Si les deux opérandes sont du même type et ont la même valeur, === produit true et !== produit false . Les jumeaux maléfiques font ce qui est juste quand les opérandes sont du même type, mais s’ils sont de types différents, ils tentent de contraindre les valeurs. les règles par lesquelles ils font cela sont compliquées et immuables. Voici quelques cas intéressants:

'' == '0'           // false
0 == ''             // true
0 == '0'            // true

false == 'false'    // false
false == '0'        // true

false == undefined  // false
false == null       // false
null == undefined   // true

' \t\r\n ' == 0     // true

Le manque de transitivité est alarmant. Mon conseil est de ne jamais utiliser les jumeaux maléfiques. Au lieu de cela, utilisez toujours === et !== . Toutes les comparaisons que nous venons de montrer produisent false avec l'opérateur === .

Mettre à jour:

@Casebash a soulevé un bon point dans les commentaires et dans la answer @Phillipe Laybaert concernant les types de référence. Pour les types de référence == et === agissent de manière cohérente (sauf dans des cas particuliers).

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

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

var e = "text";
var f = "te" + "xt";

a == b            // false
a === b           // false

c == d            // false
c === d           // false

e == f            // true
e === f           // true

Le cas particulier se présente lorsque vous comparez un littéral avec un objet dont la valeur correspond au même littéral, en raison de sa toString ou valueOf . Par exemple, considérons la comparaison d'un littéral de chaîne avec un objet de chaîne créé par le constructeur String .

"abc" == new String("abc")    // true
"abc" === new String("abc")   // false

Ici, l'opérateur == vérifie les valeurs des deux objets et renvoie true , mais === constate qu'ils ne sont pas du même type et renvoie false . Laquelle est correcte? Cela dépend vraiment de ce que vous essayez de comparer. Mon conseil est de contourner entièrement la question et de ne pas utiliser le constructeur String pour créer des objets string.

Référence
http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3


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 .


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 '=='


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

Un exemple simple est

2 == '2'  -> true, values are SAME because of type conversion.

2 === '2'  -> false, values are NOT SAME because of no type conversion.

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 

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.


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.



Je sais qu'il existe déjà de nombreuses solutions, mais je suppose que ce script simple et petit peut être utile pour illustrer le concept:

// makeSequencer will return a "sequencer" function
var makeSequencer = function() {
    var _count = 0; // not accessible outside this function
    var sequencer = function () {
        return _count++;
    }
    return sequencer;
}

var fnext = makeSequencer();
var v0 = fnext();     // v0 = 0;
var v1 = fnext();     // v1 = 1;
var vz = fnext._count // vz = undefined




javascript operators equality equality-operator identity-operator