Pregunta ¿Qué operador igual (== vs ===) se debe usar en las comparaciones de JavaScript?


Estoy usando JSLint ir a través de JavaScript, y está devolviendo muchas sugerencias para reemplazar == (dos signos iguales) con === (tres signos iguales) al hacer cosas como comparar idSele_UNVEHtype.value.length == 0 dentro de un if declaración.

¿Hay algún beneficio en el rendimiento para reemplazar == con ===?

Cualquier mejora en el rendimiento sería bienvenida ya que existen muchos operadores de comparación.

Si no se realiza ninguna conversión de tipo, ¿habría una ganancia de rendimiento ==?


5674
2017-12-11 14:19


origen


Respuestas:


La identidad (===) el operador se comporta de forma idéntica a la igualdad (==) operador, excepto que no se realiza ninguna conversión de tipo, y los tipos deben ser iguales para considerarse iguales.

Referencia: Tutorial de Javascript: operadores de comparación

los == el operador comparará por igualdad después de hacer las conversiones de tipo necesarias. los === el operador no hacer la conversión, entonces si dos valores no son del mismo tipo === simplemente regresará false. Ambos son igualmente rápidos.

Para citar a Douglas Crockford es excelente JavaScript: las buenas partes,

JavaScript tiene dos conjuntos de operadores de igualdad: === y !==y sus malvados gemelos == y !=. Los buenos funcionan de la forma esperable. Si los dos operandos son del mismo tipo y tienen el mismo valor, entonces === produce true y !== produce false. Los gemelos malvados hacen lo correcto cuando los operandos son del mismo tipo, pero si son de tipos diferentes, intentan coaccionar los valores. las reglas por las que lo hacen son complicadas y no memorables. Estos son algunos de los casos interesantes:

'' == '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 falta de transitividad es alarmante. Mi consejo es que nunca uses a los malvados gemelos. En cambio, siempre usa === y !==. Todas las comparaciones que acabamos de mostrar producen false con el === operador.


Actualizar:

Un buen punto fue mencionado por @Casebash en los comentarios y en @Phillipe Laybaert's  responder con respecto a los tipos de referencia. Para tipos de referencia == y === Actuar consistentemente con los demás (excepto en un caso especial).

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

El caso especial es cuando se compara un literal con un objeto que se evalúa con el mismo literal, debido a su toString o valueOf método. Por ejemplo, considere la comparación de un literal de cadena con un objeto de cadena creado por el String constructor.

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

Aquí el == el operador está comprobando los valores de los dos objetos y regresando true, pero el === está viendo que no son del mismo tipo y regresan false. ¿Cuál es correcto? Eso realmente depende de lo que estás tratando de comparar. Mi consejo es omitir la pregunta por completo y simplemente no usar el String constructor para crear objetos de cadena.

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


5716
2017-12-11 14:25



Utilizando el ==operador (Igualdad)

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

Utilizando el ===operador (Identidad)

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

Esto es porque el operador de igualdad == no escribe coerción, lo que significa que el intérprete implícitamente intenta convertir los valores antes de comparar.

Por otro lado, el operador de identidad === no hace tipo de coacción, y por lo tanto no convierte los valores al comparar.


988
2018-06-05 19:11



En las respuestas aquí, no leí nada sobre qué igual medio. Algunos dirán que === medio igual y del mismo tipo, pero eso no es realmente cierto. En realidad significa que ambos operandos hacen referencia al mismo objeto, o en caso de tipos de valor, tienen el mismo valor.

Entonces, tomemos el siguiente código:

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 mismo aquí:

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 incluso:

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

Este comportamiento no siempre es obvio. Hay más en la historia que ser igual y ser del mismo tipo.

La regla es:

Para tipos de valores (números):
a === b devuelve verdadero si a y b tienen el mismo valor y son del mismo tipo

Para tipos de referencia:
a === b devuelve verdadero si a y b referencia el mismo objeto exacto

Para cuerdas:
a === b devuelve verdadero si a y b son ambas cadenas y contienen exactamente los mismos caracteres


Cuerdas: el caso especial ...

Las cadenas no son tipos de valores, pero en Javascript se comportan como tipos de valores, por lo que serán "iguales" cuando los caracteres en la cadena sean iguales y cuando tengan la misma longitud (como se explica en la tercera regla)

Ahora se vuelve interesante:

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

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

Pero ¿qué tal esto ?:

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

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

Pensé que las cadenas se comportan como tipos de valores? Bueno, depende a quién le preguntes ... En este caso, a y b no son del mismo tipo. a es de tipo Object, mientras b es de tipo string. Solo recuerda que crear un objeto de cadena usando el String constructor crea algo de tipo Object que se comporta como una cadena la mayor parte del tiempo.


545
2018-05-05 05:21



Una representación pictórica interesante de la comparación de igualdad entre == y ===.

Fuente: http://dorey.github.io/JavaScript-Equality-Table/


var1 === var2

Cuando usas === para la prueba de igualdad de JavaScript, todo es como es. Nada se convierte antes de ser evaluado.

Equality evaluation of === in JS


var1 == var2

Cuando usas == para la prueba de igualdad de JavaScript, algunos   se producen conversiones funky.

Equality evaluation of == in JS

Moraleja de la historia: 

Utilizar === a menos que entiendas completamente el   conversiones que tienen lugar con ==.


519
2017-11-28 18:18



Permítanme agregar este consejo:

Si tiene dudas, lea el especificación! 

ECMA-262 es la especificación para un lenguaje de script cuyo JavaScript es un dialecto. Por supuesto, en la práctica importa más cómo se comportan los navegadores más importantes que una definición esotérica de cómo se supone que se debe manejar algo. Pero es útil entender por qué nueva cadena ("a")! == "a".

Permítanme explicar cómo leer la especificación para aclarar esta pregunta. Veo que en este viejo tema nadie tenía una respuesta para el efecto muy extraño. Entonces, si puede leer una especificación, esto lo ayudará enormemente en su profesión. Es una habilidad adquirida. Entonces, continuemos.

Buscando el archivo PDF para === me lleva a la página 56 de la especificación: 11.9.4. The Strict Equals Operator (===), y después de vadear la ficha especificada, encuentro:

11.9.6 El algoritmo de comparación de igualdad estricta
  La comparación x === y, donde xey son valores, produce cierto o falso. Tal comparación se realiza de la siguiente manera:
  1. Si Tipo (x) es diferente de Tipo (y), devuelva falso.
  2. Si Tipo (x) no está definido, devuelva cierto.
  3. Si Type (x) es nulo, devuelve cierto.
  4. Si Tipo (x) no es Número, vaya al paso 11.
  5. Si x es Yaya, regreso falso.
  6. Si y es Yaya, regreso falso.
  7. Si x es el mismo valor numérico que y, return cierto.
  8. Si x es +0 e y es -0, regrese cierto.
  9. Si x es -0 y y es +0, regrese cierto.
  10. Regreso falso.
  11. Si Type (x) es String, luego regresa cierto si xey son exactamente la misma secuencia de caracteres (la misma longitud y los mismos caracteres en las posiciones correspondientes); de lo contrario, regresa falso.
  12. Si Type (x) es Boolean, devuelve cierto si x y y son ambos cierto o ambos falso; de lo contrario, regresa falso.
  13. Regreso cierto si xey se refieren al mismo objeto o si se refieren a objetos unidos entre sí (ver 13.1.2). De lo contrario, regresa falso.

Interesante es el paso 11. Sí, las cadenas se tratan como tipos de valor. Pero esto no explica por qué nueva cadena ("a")! == "a". ¿Tenemos un navegador que no se ajuste a ECMA-262?

¡No tan rapido!

Revisemos los tipos de operandos. Pruébelo usted mismo envolviéndolos en tipo de(). encontré eso nueva cadena ("a") es un objeto, y se usa el paso 1: regresar falso si los tipos son diferentes

Si te preguntas por qué nueva cadena ("a") no devuelve una cadena, ¿qué tal un ejercicio leyendo una especificación? ¡Que te diviertas!


Aidiakapi escribió esto en un comentario a continuación:

De la especificación

11.2.2 El nuevo operador:

Si Type (constructor) no es Object, lanza una excepción TypeError.

En otras palabras, si String no fuera de tipo Object, no podría usarse con el nuevo operador.

nuevo siempre devuelve un objeto, incluso para Cuerda constructores, también. Y ¡ay! La semántica del valor de las cadenas (ver paso 11) se pierde.

Y esto finalmente significa: nueva cadena ("a")! == "a".


250
2018-05-12 12:58



En PHP y JavaScript, es un operador estricto de igualdad. Lo que significa que comparará el tipo y los valores.


93
2017-12-25 11:17



Probé esto en Firefox con Firebug usando un código como este:

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

y

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

Mis resultados (probados cinco veces cada uno y promediados):

==: 115.2
===: 114.4

Así que diría que la diferencia minúscula (esto es más de 100000 iteraciones, recuerda) es insignificante. Actuación no es una razón para hacer ===. Escriba la seguridad (bueno, tan seguro como va a obtener en JavaScript) y la calidad del código.


88
2018-05-12 12:58



En JavaScript significa del mismo valor y tipo.

Por ejemplo,

4 == "4" // will return true

pero

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

84
2017-12-11 14:58



los === operador se llama un operador de comparación estricta, hace diferir de la == operador.

Tomemos 2 vars a y b.

por "a == b" para evaluar a verdadero ayb necesitan ser el mismo valor.

En el caso de "a === b" ayb deben ser los mismo valor y también el el mismo tipo para que evalúe a verdadero.

Toma el siguiente ejemplo

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 resumen; utilizando el == el operador puede evaluar como verdadero en situaciones en las que no lo desea así que usar el === el operador estaría más seguro.

En el escenario de uso del 90%, no importa cuál usar, pero es útil saber la diferencia cuando se produce un comportamiento inesperado algún día.


72
2018-05-12 12:58