que parse operadores logicos ejemplo booleanos javascript semantics

javascript - parse - booleano en una sentencia if



operadores logicos javascript (12)

Hoy recibí un comentario sobre el código teniendo en cuenta la forma en que verifico si una variable es verdadera o falsa en una tarea escolar.

El código que había escrito era algo como esto:

var booleanValue = true; function someFunction(){ if(booleanValue === true){ return "something"; } }

Dijeron que era mejor / más limpio escribirlo así:

var booleanValue = true; function someFunction(){ if(booleanValue){ return "something"; } }

La observación que recibí sobre la parte "=== verdadero" fue que no era necesaria y podría crear confusión.

Sin embargo, mi idea es que es mejor verificar si la variable es booleana o no, especialmente dado que Javascript es un lenguaje de loosetyped.

En el segundo ejemplo, una cadena también devolvería "algo";

Entonces mi pregunta; ¿Es más apropiado perder la parte "=== verdadero" en el futuro, o es una buena práctica verificar también el tipo de la variable?

Editar: en mi código "real" el booleano representa si una imagen ha sido eliminada o no, por lo que los únicos valores que boolValue debería tener son verdaderos o falsos.

0 y 1, por ejemplo, no deberían estar en esa variable.


Como el valor verificado es booleano, prefirió usarlo directamente para menos codificación y en absoluto hizo lo mismo == verdadero


Como ya se inicializó claramente como bool, creo que === operador no es necesario.


Creo que tu razonamiento es sólido. Pero en la práctica, he descubierto que es mucho más común omitir la comparación === . Creo que hay tres razones para eso:

  1. Por lo general, no se agrega al significado de la expresión, es decir, en los casos en que se sabe que el valor es booleano de todos modos.
  2. Debido a que hay una gran cantidad de incertidumbre de tipo en JavaScript, forzar una comprobación de tipo tiende a morderte cuando obtienes un valor inesperado, undefined o null . A menudo solo quieres que tu prueba falle en tales casos. (Aunque intento equilibrar esta visión con el lema "fallar rápido").
  3. A los programadores de JavaScript les gusta jugar con tipos rápidos y sueltos, especialmente en expresiones booleanas, porque podemos.

Considera este ejemplo:

var someString = getInput(); var normalized = someString && trim(someString); // trim() removes leading and trailing whitespace if (normalized) { submitInput(normalized); }

Creo que este tipo de código no es raro. Maneja casos donde getInput() devuelve undefined , null o una cadena vacía. Debido a las dos evaluaciones booleanas, se submitInput() solo si la entrada dada es una cadena que contiene caracteres que no son de espacios en blanco.

En JavaScript && devuelve su primer argumento si es falso o su segundo argumento si el primer argumento es verdadero; lo normalized no estará undefined si someString no está definido y demás. Eso significa que ninguna de las entradas a las expresiones booleanas anteriores son realmente valores booleanos.

Sé que muchos programadores que están acostumbrados a una fuerte comprobación de tipos se encojen al ver código como este. Pero la nota que aplica la tipificación fuerte probablemente requerirá comprobaciones explícitas de valores null o undefined , lo que desordenaría el código. En JavaScript que no es necesario.


Depende de tu caso de uso. Puede tener sentido verificar el tipo también, pero si solo es una bandera, no es así.


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

if (booleanValue) es esencialmente if (booleanValue == true).


En Javascript, la idea de boolean es bastante ambigua. Considera esto:

var bool = 0 if(bool){..} //evaluates to false if(//uninitialized var) //evaluates to false

Por lo tanto, cuando usa una instrucción if (o cualquier otra instrucción de control), no es necesario utilizar una var de tipo "booleano". Por lo tanto, en mi opinión, la parte "=== verdadero" de su extracto es innecesaria si usted sabe que es un booleano, pero absolutamente necesario si su valor es una varianza ambigua "verídica". Puede encontrar más sobre booleanos en javscript here .


En el plano "si" la variable será forzada a un booleano y usa toBoolean en el objeto: -

Argument Type Result Undefined false Null false Boolean The result equals the input argument (no conversion). Number The result is false if the argument is +0, −0, or NaN; otherwise the result is true. String The result is false if the argument is the empty String (its length is zero); otherwise the result is true. Object true.

Pero la comparación con === no tiene ningún tipo de coerción, por lo que deben ser iguales sin coacción.

Si está diciendo que el objeto puede que ni siquiera sea booleano, puede que tenga que considerar algo más que verdadero / falso.

if(x===true){ ... } else if(x===false){ .... } else { .... }


En general, es más simple y más simple omitir el === true .

Sin embargo, en Javascript, esas declaraciones son diferentes.

if (booleanValue) se ejecutará si booleanValue es verdadero : cualquier cosa que no sea 0 , false , '''' , NaN , null e undefined .

if (booleanValue === true) solo se ejecutará si booleanValue es exactamente igual a true .


Esto depende. Si le preocupa que su variable pueda terminar como algo que se resuelve como VERDADERO. Entonces la comprobación dura es imprescindible. De lo contrario, depende de usted. Sin embargo, dudo que la sintaxis que whatever == TRUE haya confundido a alguien que supiera lo que estaban haciendo.


Primero, los hechos:

if (booleanValue)

Satisfacerá la instrucción if para cualquier valor de booleanValue de booleanValue incluyendo true , cualquier número distinto de cero, cualquier valor de cadena no vacío, cualquier objeto o referencia de matriz, etc.

Por otra parte:

if (booleanValue === true)

Esto solo satisfará la condición if si booleanValue es exactamente igual a true . Ningún otro valor de verdad lo satisfará.

Por otro lado, si haces esto:

if (someVar == true)

Entonces, lo que Javascript hará es escribir coerce true para que coincida con el tipo de someVar y luego comparar las dos variables. Hay muchas situaciones en las que probablemente no sea lo que se pretende. Debido a esto, en la mayoría de los casos quiere evitar == porque hay un conjunto bastante largo de reglas sobre cómo JavaScript escribirá forzar dos cosas para que sean del mismo tipo y a menos que comprenda todas esas reglas y pueda anticipar todo lo que el intérprete de JS podría Cuando se le dan dos tipos diferentes (que la mayoría de los desarrolladores de JS no pueden), es probable que desee evitar == completo.

Como ejemplo de lo confuso que puede ser:

var x; x = 0; console.log(x == true); // false, as expected console.log(x == false); // true as expected x = 1; console.log(x == true); // true, as expected console.log(x == false); // false as expected x = 2; console.log(x == true); // false, ?? console.log(x == false); // false

Para el valor 2 , pensarías que 2 es un valor verdadero, por lo que se compararía favorablemente con true , pero no es así como funciona la coerción de tipo. Está convirtiendo el valor de la mano derecha para que coincida con el tipo del valor de la mano izquierda, por lo que su conversión es true al número 1 por lo que está comparando 2 == 1 que ciertamente no es lo que probablemente pretendía.

Por lo tanto, el comprador tenga cuidado. Es mejor evitar == en casi todos los casos a menos que sepa explícitamente los tipos que comparará y sepa cómo funcionan todos los posibles algoritmos de coerción de tipos.

Por lo tanto, realmente depende de los valores esperados para booleanValue y de cómo desea que funcione el código. Si sabe de antemano que solo va a tener un valor true o false , entonces cámbielo explícitamente con

if (booleanValue === true)

es solo código extra e innecesario

if (booleanValue)

es más compacto y posiblemente más limpio / mejor.

Si, por otro lado, no sabe qué booleanValue podría ser y desea probar si realmente está configurado como true sin otras conversiones de tipo automáticas permitidas, entonces

if (booleanValue === true)

no es solo una buena idea, sino que es necesaria.

Por ejemplo, si observa la implementación de .on() en jQuery, tiene un valor de retorno opcional. Si la devolución de llamada devuelve false , jQuery detendrá automáticamente la propagación del evento. En este caso específico, dado que jQuery quiere SOLAMENTE detener la propagación si se devolvió false , comprueban la explicidad del valor de retorno para === false porque no quieren undefined o 0 o "" o cualquier otra cosa que automáticamente convertirá a falso para satisfacer también la comparación.

Por ejemplo, aquí está el evento jQuery manejando el código de devolución de llamada:

ret = ( specialHandle || handleObj.handler ).apply( matched.elem, args ); if ( ret !== undefined ) { event.result = ret; if ( ret === false ) { event.preventDefault(); event.stopPropagation(); } }

Puedes ver que jQuery está buscando explícitamente ret === false .

Pero, también hay muchos otros lugares en el código de jQuery donde una verificación más simple es apropiada dado el deseo del código. Por ejemplo:

// The DOM ready check for Internet Explorer function doScrollCheck() { if ( jQuery.isReady ) { return; } ...


Si escribe: if(x === true) , será verdadero solo para x = verdadero

Si escribe: if(x) , será verdadero para cualquier x que no sea: '''' (cadena vacía), falso, nulo, indefinido, 0, NaN.


Si la variable solo puede tomar valores booleanos, entonces es razonable usar la sintaxis más corta.

Si potencialmente se le pueden asignar otros tipos, y necesita distinguir true de 1 o "foo" , entonces debe usar === true .