while Quale operatore uguale(== vs===) dovrebbe essere utilizzato nei confronti JavaScript?




javascript istruzioni condizionali (24)

Come regola generale, generalmente utilizzerei ===invece di ==(e !==non di !=).

Le ragioni sono spiegate nelle risposte sopra e anche Douglas Crockford ne è abbastanza chiaro ( JavaScript: The Good Parts ).

Tuttavia c'è una sola eccezione : == nullè un modo efficace per verificare che 'sia nullo o indefinito':

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

Ad esempio, jQuery 1.9.1 utilizza questo modello 43 volte e il correttore di sintassi JSHint fornisce anche l' eqnullopzione di relax per questo motivo.

Dalla guida allo stile di jQuery :

I controlli rigorosi sull'uguaglianza (===) dovrebbero essere usati a favore di ==. L'unica eccezione è quando si cerca undefined e null per mezzo di null.

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

Sto usando JSLint per passare attraverso JavaScript, e restituisce molti suggerimenti per sostituire == (due segni di uguale) con === (tre segni di uguale) quando si fanno cose come confrontare idSele_UNVEHtype.value.length == 0 all'interno di un if dichiarazione.

C'è un vantaggio in termini di prestazioni nel sostituire == con === ?

Qualsiasi miglioramento delle prestazioni sarebbe gradito dato che esistono molti operatori di confronto.

Se non avviene alcuna conversione di tipo, si otterrebbe un aumento delle prestazioni su == ?


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

Diagramma di flusso di esecuzione Javascript per rigorosa uguaglianza / confronto '==='

Diagramma di flusso di esecuzione Javascript per uguaglianza non rigida / confronto '=='


L'operatore === è chiamato operatore di confronto rigoroso, differisce dall'operatore == .

Prendiamo 2 varsetti a e b.

Perché "a == b" per valutare a vero a eb devono essere lo stesso valore .

Nel caso di "a === b" aeb deve essere lo stesso valore e anche lo stesso tipo da valutare a vero.

Prendi il seguente esempio

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");
}

In sintesi ; l'utilizzo dell'operatore == potrebbe valere come true in situazioni in cui non si desidera che l'utilizzo dell'operatore === sia più sicuro.

Nello scenario di utilizzo del 90% non importa quale si utilizza, ma è utile conoscere la differenza quando si verifica un comportamento imprevisto un giorno.


È un test di controllo rigoroso.

È una buona cosa soprattutto se stai controllando tra 0 e false e null.

Ad esempio, se hai:

$a = 0;

Poi:

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

Tutto ritorna vero e tu potresti non volerlo. Supponiamo che tu abbia una funzione che può restituire l'indice 0 di un array o falso in caso di fallimento. Se controlli con "==" false, puoi ottenere un risultato confuso.

Quindi con la stessa cosa di cui sopra, ma un test severo:

$a = 0;

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

Il problema è che potresti facilmente metterti nei guai dato che JavaScript ha un sacco di conversioni implicite che significano ...

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

Che ben presto diventa un problema. Il miglior esempio del perché la conversione implicita è "malvagia" può essere preso da questo codice in MFC / C ++ che in realtà verrà compilato a causa di una conversione implicita da CString a HANDLE che è un tipo typedef puntatore ...

CString x;
delete x;

Che ovviamente durante il runtime fa cose molto indefinite ...

Google per le conversioni implicite in C ++ e STL per ottenere alcuni degli argomenti contro di esso ...


In uno script tipico non ci saranno differenze di prestazioni. Più importante potrebbe essere il fatto che migliaia "===" è 1 KB più pesante di mille "==" :) I profiler JavaScript possono dirti se c'è una differenza di prestazioni nel tuo caso.

Ma personalmente farei quello che suggerisce JSLint. Questa raccomandazione non è lì a causa di problemi di prestazioni, ma perché il tipo di coercizione significa ('\t\r\n' == 0) è vero.


In JavaScript significa lo stesso valore e tipo.

Per esempio,

4 == "4" // will return true

ma

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

=== operatore === controlla i valori e i tipi delle variabili per l'uguaglianza.

== operatore == controlla il valore delle variabili per l'uguaglianza.


Utilizzo dell'operatore == ( uguaglianza )

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

Utilizzo dell'operatore === ( Identità )

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

Questo perché l' operatore di uguaglianza == esegue la coercizione , nel senso che l'interprete cerca implicitamente di convertire i valori prima di confrontarli.

D'altra parte, l' operatore di identità === non esegue la coercizione di tipo e quindi non converte i valori durante il confronto.


Lasciatemi aggiungere questo consiglio:

In caso di dubbio, leggi le specification !

ECMA-262 è la specifica per un linguaggio di scripting di cui JavaScript è un dialetto. Ovviamente nella pratica conta più come si comportano i browser più importanti di una definizione esoterica di come una cosa dovrebbe essere gestita. Ma è utile capire perché nuova String ("a")! == "a" .

Per favore lasciami spiegare come leggere le specifiche per chiarire questa domanda. Vedo che in questo argomento molto vecchio nessuno aveva una risposta per lo strano effetto. Quindi, se puoi leggere una specifica, questo ti aiuterà moltissimo nella tua professione. È un'abilità acquisita. Quindi, continuiamo.

La ricerca del file PDF per === mi porta alla pagina 56 della specifica: 11.9.4. The Strict Equals Operator (===) , e dopo aver attraversato il specificationalese trovo:

11.9.6 Algoritmo di confronto rigoroso di uguaglianza
Il confronto x === y, dove xey sono valori, produce vero o falso . Tale confronto viene eseguito come segue:
1. Se Type (x) è diverso da Type (y), restituisce false .
2. Se Type (x) non è definito, restituisce true .
3. Se Type (x) è Null, restituisce true .
4. Se Type (x) non è Number, andare al passaggio 11.
5. Se x è NaN , restituisce falso .
6. Se y è NaN , restituisci falso .
7. Se x è lo stesso valore numerico di y, restituisce true .
8. Se x è +0 e y è -0, restituisce true .
9. Se x è -0 e y è +0, restituisce true .
10. Restituisci falso .
11. Se Type (x) è String, restituisce true se xey sono esattamente la stessa sequenza di caratteri (stessa lunghezza e stessi caratteri nelle posizioni corrispondenti); altrimenti, restituire false .
12. Se Type (x) è booleano, restituisce true se xey sono entrambi veri o entrambi falsi ; altrimenti, restituire false .
13. Restituisce vero se xey si riferiscono allo stesso oggetto o se si riferiscono ad oggetti uniti tra loro (si veda 13.1.2). Altrimenti, restituisci falso .

Interessante è il passaggio 11. Sì, le stringhe sono trattate come tipi di valore. Ma questo non spiega perché new String ("a")! == "a" . Abbiamo un browser non conforme all'ECMA-262?

Non così in fretta!

Controlliamo i tipi di operandi. Provalo tu stesso avvolgendoli in typeof () . Trovo che la nuova stringa ("a") sia un oggetto e che venga utilizzata la fase 1: restituisce false se i tipi sono diversi.

Se ti chiedi perché la nuova stringa ("a") non restituisce una stringa, che ne dici di un esercizio fisico che legge una specifica? Divertiti!

Aidiakapi ha scritto questo in un commento qui sotto:

Dalle specifiche

11.2.2 Il nuovo operatore :

Se Type (costruttore) non è Object, genera un'eccezione TypeError.

Con altre parole, se String non fosse di tipo Object non potrebbe essere utilizzato con il nuovo operatore.

new restituisce sempre un oggetto, anche per i costruttori di stringhe . E ahimè! La semantica del valore per le stringhe (vedere il punto 11) viene persa.

E questo significa finalmente: nuova stringa ("a")! == "a" .


Una rappresentazione pittorica interessante del confronto di uguaglianza tra == e === .

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

var1 === var2

Quando si utilizza === per il test di uguaglianza JavaScript, tutto è così com'è. Nulla viene convertito prima di essere valutato.

var1 == var2

Quando si utilizza == per i test di uguaglianza JavaScript, si verificano alcune conversioni funky.

Morale della storia:

Utilizza === meno che tu non comprenda pienamente le conversioni che si verificano con == .


Significa che l' uguaglianza senza tipo di coercizione di tipo coercizione significa che JavaScript non converte automaticamente altri tipi di dati in tipi di dati stringa

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 


Semplicemente

==significa confronto tra gli operandi con type conversion

&

===significa confronto tra operandi senza type conversion

Digitare la conversione in javaScript significa che javaScript converte automaticamente qualsiasi altro tipo di dati in tipi di dati stringa.

Per esempio:

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 

* Operatori === vs == *

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

Controlla se gli stessi lati sono uguali per tipo e valore .

Esempio:

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

Esempio comune:

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

Un altro esempio comune:

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

Le prime 2 risposte entrambe menzionate == significa uguaglianza e === significa identità. Sfortunatamente, questa affermazione non è corretta.

Se entrambi gli operandi di == sono oggetti, vengono confrontati per vedere se sono lo stesso oggetto. Se entrambi gli operandi puntano allo stesso oggetto, l'operatore uguale restituisce true. Altrimenti, i due non sono uguali.

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

Nel codice sopra, sia == che === diventa falso perché a e b non sono gli stessi oggetti.

Vale a dire: se entrambi gli operandi di == sono oggetti, == si comporta come ===, che significa anche identità. La differenza essenziale di questi due operatori riguarda la conversione del tipo. == ha una conversione prima che controlli l'uguaglianza, ma === no.


L'operatore di confronto uguale == è confuso e dovrebbe essere evitato.

Se DEVI vivere con esso, quindi ricorda le seguenti 3 cose:

  1. Non è transitivo: (a == b) e (b == c) non porta a (a == c)
  2. Si esclude a vicenda per la sua negazione: (a == b) e (a! = B) mantengono sempre i valori booleani opposti, con tutti a e b.
  3. In caso di dubbio, impara a memoria la seguente tabella di verità:

TABELLA DELLA VERITÀ DELL'OPERATORE EQUAL IN JAVASCRIPT

  • Ogni riga della tabella è un insieme di 3 valori reciprocamente "uguali", il che significa che qualsiasi 2 valori tra loro sono uguali usando l'uguale == segno *

** STRANGE: nota che qualsiasi due valori sulla prima colonna non sono uguali in questo senso. **

''       == 0 == false   // Any two values among these 3 ones are equal with the == operator
'0'      == 0 == false   // Also a set of 3 equal values, note that only 0 and false are repeated
'\t'     == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\r'     == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\n'     == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\t\r\n' == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

null == undefined  // These two "default" values are not-equal to any of the listed values above
NaN                // NaN is not equal to any thing, even to itself.

L'operatore di identità ( === ) si comporta in modo identico all'operatore di uguaglianza ( == ) tranne che non viene eseguita alcuna conversione di tipo e i tipi devono essere uguali per essere considerati uguali.

Riferimento: Javascript Tutorial: Operatori di confronto

L'operatore == si confronterà per l'uguaglianza dopo aver effettuato tutte le conversioni di tipo necessarie . L'operatore === non eseguirà la conversione, quindi se due valori non sono dello stesso tipo === restituirà semplicemente false . Entrambi sono ugualmente veloci.

Per citare l'eccellente JavaScript di Douglas Crockford : The Good Parts ,

JavaScript ha due insiemi di operatori di uguaglianza: === e !== , e i loro gemelli malvagi == e != . I bravi funzionano come ti aspetteresti. Se i due operandi sono dello stesso tipo e hanno lo stesso valore, allora === produce true e !== produce false . I gemelli malvagi fanno la cosa giusta quando gli operandi sono dello stesso tipo, ma se sono di tipi diversi, tentano di forzare i valori. le regole con cui lo fanno sono complicate e non memorizzabili. Questi sono alcuni dei casi interessanti:

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

La mancanza di transitività è allarmante. Il mio consiglio è di non usare mai i gemelli malvagi. Invece, usa sempre === e !== . Tutti i confronti appena mostrati producono false con l'operatore === .

Aggiornare:

Un buon punto è stato sollevato da @Casebash nei commenti e nella answer @Phillipe Laybaert sui tipi di riferimento. Per i tipi di riferimento == e === agire in modo coerente l'uno con l'altro (tranne in un caso speciale).

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

Il caso speciale è quando si confronta un valore letterale con un oggetto che valueOf lo stesso valore letterale, a causa del metodo toString o valueOf . Ad esempio, si consideri il confronto di un letterale stringa con un oggetto stringa creato dal costruttore String .

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

Qui l'operatore == sta controllando i valori dei due oggetti e restituisce true , ma il === sta vedendo che non sono dello stesso tipo e restituiscono false . Quale è corretto? Dipende molto da cosa stai cercando di confrontare. Il mio consiglio è di ignorare completamente la domanda e semplicemente non usare il costruttore String per creare oggetti stringa.

Riferimento
http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3


nulli e indefiniti sono il nulla, cioè,

var a;
var b = null;

Qui ae bnon hanno valori. Mentre, 0, false e '' sono tutti valori. Una cosa comune tra tutti questi è che sono tutti valori falsi, il che significa che soddisfano tutti le condizioni di falsità.

Quindi, lo 0, falso e "insieme formano un sottogruppo. E d'altra parte, null e indefinito formano il secondo sottogruppo. Controlla i confronti nell'immagine sottostante. null e undefined sarebbero uguali. Gli altri tre sarebbero uguali tra loro. Ma sono tutti trattati come falsi in JavaScript.

Questo è uguale a qualsiasi oggetto (come {}, matrici, ecc.), Stringa non vuota e Booleano true sono tutte condizioni di verità. Ma non sono tutti uguali.


In PHP e JavaScript, è un operatore di uguaglianza rigorosa. Il che significa che confronterà sia il tipo che i valori.


Sì! Importa.

=== operatore in javascript controlla il valore e digita dove come == operatore controlla solo il valore (esegue la conversione del tipo se necessario) .

Puoi facilmente testarlo. Incolla il codice seguente in un file HTML e aprilo nel browser

<script>

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

</script>

</head>

<body onload='onPageLoad();'>

Riceverai ' falso ' in allerta. Ora modifica il metodo onPageLoad() per alert(x == 5); tu diventerai vero .


Nelle risposte qui, non ho letto nulla su ciò che equivale a dire. Alcuni diranno che === significa uguale e dello stesso tipo , ma non è proprio vero. In realtà significa che entrambi gli operandi fanno riferimento allo stesso oggetto o, nel caso di tipi di valore, hanno lo stesso valore .

Quindi, prendiamo il seguente codice:

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

Lo stesso qui:

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

O anche:

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

Questo comportamento non è sempre ovvio. C'è di più nella storia che essere uguali ed essere dello stesso tipo.

La regola è:

Per i tipi di valore (numeri):
a === b restituisce true se a e b hanno lo stesso valore e sono dello stesso tipo

Per i tipi di riferimento:
a === b restituisce true se a e b riferimento allo stesso identico oggetto

Per le stringhe:
a === b restituisce true se a e b sono entrambe stringhe e contengono esattamente gli stessi caratteri

Archi: il caso speciale ...

Le stringhe non sono tipi di valore, ma in Javascript si comportano come tipi di valore, quindi saranno "uguali" quando i caratteri nella stringa sono uguali e quando hanno la stessa lunghezza (come spiegato nella terza regola)

Ora diventa interessante:

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

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

Ma che ne dici di questo ?:

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

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

Pensavo che le stringhe si comportassero come tipi di valore? Beh, dipende da chi chiedi ... In questo caso a e b non sono dello stesso tipo. a è di tipo Object , mentre b è di tipo string . Basta ricordare che la creazione di un oggetto stringa usando il costruttore String crea qualcosa di tipo Object che si comporta come una stringa il più delle volte .





identity-operator