JSLint Se esperaba '===' y en su lugar vi '=='

Question

Recientemente estaba ejecutando parte de mi código a través de JSLint cuando se me ocurrió este error. Lo que creo que es gracioso acerca de este error es que automáticamente asume que todo == debería ser ===.

¿Eso realmente tiene sentido? Pude ver muchas instancias en las que no querría comparar el tipo y me preocupa que esto realmente pueda causar problemas.

La palabra "Esperado" implicaría que esto debería hacerse CADA vez ... Eso es lo que no tiene sentido para mí.

Answer 1

OMI, a ciegas utilizando ===, sin tratar de entender cómo tipo de conversión obras no tiene mucho sentido.

El principal temor sobre el operador de igualdad == es que las reglas de comparación en función de los tipos comparados puede hacer que el operador no transitiva, por ejemplo, si:

A == B AND 
B == C 

en realidad no garantiza que :

A == C 

Por ejemplo:

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

El estricto operador de igualdad === no es realmente necesario cuando se comparan los valores del mismo tipo, el ejemplo más común:

if (typeof foo == "function") { 
    //.. 
} 

Se compara el resultado del operador typeof, que es siempre una cadena, con una cadena literal ...

o cuando conoce las reglas de conversión de tipo, por ejemplo, comprobar si algo es algo null o undefined:

if (foo == null) { 
    // foo is null or undefined 
} 

// Vs. the following non-sense version: 

if (foo === null || typeof foo === "undefined") { 
    // foo is null or undefined 
} 

Answer 2

Bueno, realmente no puede causar problemas, solo es aconsejable. Tómelo o déjelo. Dicho esto, no estoy seguro de lo inteligente que es. Puede haber contextos en los que no lo presente como un problema.

Answer 3

Tenga en cuenta que JSLint impone la idea de una sola persona de lo que debería ser el buen JavaScript. Aún debe usar el sentido común al implementar los cambios que sugiere.

En general, comparar el tipo y el valor hará que su código sea más seguro (no se encontrará con el comportamiento inesperado cuando la conversión de tipo no hace lo que cree que debería).

Answer 4

Una cita de http://javascript.crockford.com/code.html:

=== == y Operadores!.

Casi siempre es mejor usar los operadores === y! ==. Los operadores == y! = Escriben coerción. En en particular, no use == para comparar con los valores de falsy.

JSLint es muy estricto, su 'webjslint.js' ni siquiera pasa su propia validación.

Answer 5

JSLint es intrínsecamente más defensivo de lo que permite la sintaxis de Javascript.

De la documentación JSLint:

Los == y != operadores lo escriba antes de comparar la coacción. Esto es malo porque causa que ' \t\r\n' == 0 sea verdadero. Esto puede enmascarar errores de tipo.

Cuando se compara con cualquiera de los siguientes valores, utilice las === o !== operadores (que no hace l tipo coerción): 0 '' undefined null false true

Si sólo se preocupan de que un valor es Truthy o Falsy, a continuación, usa la forma corta.En lugar de

(foo != 0)

sólo decir

(foo)

y en lugar de

(foo == 0)

dicen

(!foo)

Se prefieren los operadores === y !==.

Answer 6

Triple-igual es diferente a doble igual porque además de comprobar si las dos partes son el mismo valor, de triple igual también comprueba que son el mismo tipo de datos.

Entonces ("4" == 4) es verdadero, mientras que ("4" === 4) es falso.

Triple-equal también se ejecuta un poco más rápido, porque JavaScript no tiene que perder tiempo haciendo conversiones de tipo antes de darle la respuesta.

JSLint tiene el objetivo deliberado de hacer que su código JavaScript sea lo más estricto posible, con el objetivo de reducir errores desconocidos. Destaca este tipo de cosas para tratar de que codifiques de una manera que te obligue a respetar los tipos de datos.

Pero lo bueno de JSLint es que es solo una guía. Como dicen en el sitio, dañará tus sentimientos, incluso si eres un programador de JavaScript muy bueno. Pero no deberías sentirte obligado a seguir su consejo. Si ha leído lo que tiene que decir y lo comprende, pero está seguro de que su código no se va a romper, no hay obligación de que cambie nada.

Incluso puede decirle a JSLint que ignore las categorías de cheques si no desea ser bombardeado con advertencias de que no va a hacer nada al respecto.

Answer 7

para ayudar a explicar esta pregunta y también explicar por qué NetBeans (de) 7.3 ha comenzado a mostrar esta advertencia se trata de un extracto de la respuesta en el rastreador NetBeans error cuando alguien informó de esto como un error:

Es bueno practique usar === en lugar de == en JavaScript.

Los operadores == y! = Escriben coerción antes de comparar. Esto es malo porque hace que '\ t \ r \ n' == 0 sea verdadero. Esto puede enmascarar errores de tipo. JSLint no puede determinar de manera confiable si == se está utilizando correctamente, por lo que es mejor no usar == y! = En absoluto y usar siempre los operadores más confiables === y! == en su lugar.

Reference

Answer 8

Si desea probar para falsyness. JSLint no permite

if (foo == null) 

pero permite

if (!foo)