¿Por qué usar! Boolean_variable sobre boolean_variable == false

Un comentario sobre esta pregunta: ¿ Comprobar si un método devuelve falso: asignar el resultado a la variable temporal o poner la invocación del método directamente en condicional? dice que debe usar en !booleanlugar de boolean == falsecuando prueba las condiciones. ¿Por qué? Para mí boolean == falsees mucho más natural en inglés y es más explícito. Me disculpo si esto es solo una cuestión de estilo, pero me preguntaba si había alguna otra razón para esta preferencia !boolean.

Cuando veo una línea como if (!lateForMeeting()), leí eso como "Si no es tarde para reunirse" , lo cual es bastante sencillo de entender, en lugar de if (lateForMeeting() == false)lo que leería como "Si el hecho de que llegue tarde a la reunión es falso " .

Tienen un significado idéntico, pero el primero está más cerca de cómo se construiría la oración equivalente en inglés.

Escritura == falsey == truees redundante. También se puede llevar a extremos arbitrarios. Si empiezas a escribir

if (condition == false) { ... }

Entonces porque no

if ((condition == false) == true) { ... }

O porque no

if ((someExp == anotherExp) == true) { ... }

La moraleja de esta historia es que si conditiones una expresión booleana, entonces no necesita agregar == false; para eso está el operador !;)

En C y algunos lenguajes similares, comparar expresiones booleanas para igualdad falseo truees un hábito peligroso.

En C, cualquier expresión escalar (numérica o puntero) se puede utilizar en un contexto booleano, por ejemplo, como la condición de una ifdeclaración. La regla C if (cond)es equivalente a if (cond != 0), es decir, cero es falso y cualquier valor distinto de cero es verdadero. Si condes de tipo puntero, 0se trata como una constante de puntero nulo; if (ptr)significa if (ptr != NULL).

Esto significa que

if (cond)

y

if (cond == true)

No significan lo mismo . El primero es verdadero si condno es cero; el segundo es verdadero solo si es igual a true, que en C (si tiene #include <stdbool.h>) es simplemente 1.

Por ejemplo, la isdigit()función declarada en <ctype.h>devuelve un intvalor, 0si el argumento es un dígito, no cero si no lo es. Puede volver 42para indicar que la condición es verdadera. La comparación 42 == truefallará.

Sucede que ese 0es el único valor considerado falso, por lo que la comparación para igualdad falsefuncionará; if (!cond)y if (cond == false)hacer lo mismo Pero si vas a aprovechar eso, debes recordar que comparar con falseestá bien, y comparar con trueno lo está. Peor aún, la comparación con truefuncionará la mayor parte del tiempo (por ejemplo, los operadores de igualdad y relacionales siempre rinden 0o 1). Esto significa que cualquier error que introduzca al usar esto aún podría ser difícil de rastrear. (No se preocupe, aparecerán tan pronto como demuestre el código a un cliente importante).

C ++ tiene reglas ligeramente diferentes; por ejemplo, su booltipo está un poco más integrado en el lenguaje y se if (cond)convierte conden tipo bool. Pero el efecto es (principalmente) el mismo.

Algunos otros idiomas tienen lo que uno podría llamar booleanos con mejor comportamiento, de modo que cond == truey cond == false(o lo que sea que sea la sintaxis) es seguro. Aun así, cada idioma que he visto tiene un operador notu !; está ahí, así que bien podrías usarlo. Usar en cond == falselugar de !condo not condno, en mi opinión, mejora la legibilidad. (Es cierto que el !personaje puede ser difícil de ver de un vistazo; a veces agrego un espacio después !para evitar esto).

Y a menudo puede evitar el problema y mejorar la claridad reorganizando ligeramente el código. Por ejemplo, en lugar de:

if (!cond) {
    do_this();
}
else {
    do_that();
}

podrías escribir:

if (cond) {
     do_that();
}
else {
    do_this();
}

Eso no siempre es mejor, pero no está de más buscar oportunidades donde está.

Resumen: en C y C ++, las comparaciones de igualdad con truey falseson peligrosas, excesivamente detalladas y con un estilo pobre. En muchos otros idiomas, tales comparaciones pueden no ser peligrosas, pero siguen siendo demasiado detalladas y de mal estilo.

Los dos son funcionalmente idénticos, por lo que cuál usar es cuestión de gustos.

La principal razón por la que yo utilizo == falsees que he encontrado que !es muy fácil pasar por alto, cuando se mira en código.

Después de haber sido mordido severamente por esto, me he acostumbrado a dejarlo muy claro cuando hago pruebas de falso.

Si el operador hubiera sido nombrado notcomo en Pascal, no creo que esto se hubiera convertido en un problema.

Si condition == falserealmente es "mucho más natural en inglés" para usted, entonces debo suponer que no es un hablante nativo. De lo contrario, no puedo explicar esto, porque nadie habla así:

Si el sol brilla es falso, me quedo en casa.

Compara eso con

Si el sol no brilla, me quedo en casa.

Dicho esto, estoy de acuerdo en que el carácter único y delgado !se pasa por alto fácilmente en el código. Por esa razón, prefiero la palabra clave notcuando es compatible con el idioma. C ++, por ejemplo , permite esto, aunque muchos programadores no lo saben.

Para los idiomas que requieren !, pongo un espacio entre el operador y el operando. Esto hace que la negación sea mucho más difícil de pasar por alto:

if (! condition) { … }

Tenga en cuenta que cada programador debe traducir esto automáticamente , sin pensarlo dos veces, a "no condicionar" en su cabeza. Adquirir este tipo de fluidez en la lectura de modismos de códigos es uno de los primeros pasos para convertirse en un buen programador.

Cuando veo var == false, siempre me pregunto si vares booleano o de tipo lógico con más de dos valores (con, por ejemplo, a maybey an undefined, así como truey false, o algo así como los nueve valores de IEEE 1164 ).

porque a veces podrías escribir boolean = false(con los errores obvios) y false == booleanno parece natural (no importa cuán buena sea la práctica)

if (!boolean_variable)se traduce en if the condition is not true.

if (boolean == false)se traduce en if the condition not false is true. Debido a que es una lógica inversa, es más difícil de entender.

En compiladores (mucho) más antiguos, creo que se dividirían (booleano == falso) en 2 asignaciones de registro y un código de comparación en lenguaje de máquina. El primer ejemplo se dividiría en una tarea y un operador NOT. En términos de rendimiento, la operación de comparación tomaría varios ciclos de reloj, dependiendo del tamaño del registro que se compara, en comparación con una inversión bit a bit (1 reloj) y sería más lenta de ejecutar.

Dicho esto, creo que los compiladores más nuevos eliminan esto, por lo que debería estar bien seguir con cualquiera.

En el trabajo, a menudo trato con booleanos que pueden ser nulos, así que a menudo codifico este caso como

if (value != null && value == true){
    //do something
}

porque personalmente siento que la simetría hace que sea más fácil de leer. Especialmente si también se están probando otros booleanos.

Realmente no me importa de una forma u otra.

Cuando está probando la verdadera condición, tiene sentido hacerlo solo if (condition), especialmente cuando aplica la convención de nombrar variables booleanas que comienzan con 'es': if (isOpen)es perfectamente claro y su uso != falsesería redundante.

Para un C / C ++ / Java / etc. programador, el significado del '!' El operador está completamente asimilado, hasta el punto de que automáticamente tenemos "no" en nuestras mentes cuando lo vemos. Entonces tener if (!isOpen)es tan claro como if (_NOT_ isOpen)para mí. Pero no estás lo suficientemente familiarizado, en C / C ++ puedes crear una macro #define _NOT_ !. Pero confía en mí, después de unos años esto es completamente innecesario.

Aparte de eso, siempre es preferible probar valores booleanos sin compararlos con literales. Por ejemplo, es peligroso probar if (x == true)porque un valor booleano se considera verdadero si no es cero, y el verdadero literal tiene solo un valor específico, por lo que x podría ser 'verdadero' (es decir, distinto de cero) y aún así la comparación se evalúa como falsa (porque contiene 2 y el verdadero literal es, digamos, 1.) Por supuesto, eso no se aplica a una comparación con falso, pero si no lo usa cuando prueba verdadero, ¿por qué usarlo cuando prueba falso?

El tamaño importa ;)

En expresiones mixtas es más fácil de leer:

boolean1 = false
boolean2 = true

p ! boolean1 and ! boolean2
p boolean1 == false and boolean2 == false

Y especial para ruby ​​un ejemplo donde hay una gran diferencia:

boolean = nil
p ! boolean         #-> true
p boolean == false  #-> false

nil no es falso, pero tampoco es cierto.

Basado en mi experiencia y las respuestas de mi búsqueda a la que te has vinculado.

Algunas personas prefieren usar if (condición), porque la razón es que es más corto de escribir. y para mí tiene sentido, por ejemplo (! isValidated ()) Leí esto como No validado. pero para mí todo se basa en preferencias personales, y depende de la estructura lógica del método isValidated (), si devuelve verdadero o falso

Si nombró su variable correctamente, entonces !booleanes más natural. Se lee como not booleana cualquiera que sea lo suficientemente programador como para leer código mentalmente.

Para algunas personas, cuanto antes se exprese un significado, mejor.

Para aquellas personas que tienen "if! ..." se compara más rápido con "if ..." y luego tienen que leer toda la condición (que en realidad podría ser bastante larga, por ejemplo (thisThing = thatThing o algo = la otra cosa) O ( thinga = thingb y thinga = thingd), etc.) solo para encontrar el == falso al final.

Tener el! (De hecho, prefiero un no cuando el idioma lo permite) de inmediato obtiene el inglés 'no' para esta condición allí antes.

Este problema también lleva a consideración para usarlo untilen los idiomas que lo admiten, por ejemplo, hacer "cosas comunes" hasta que se complete. Como otros dicen, el objetivo es la expresión en lenguaje natural. Me gusta el ejemplo de "el sol está brillando" arriba.

Otra razón es que si está trabajando en una base de código que usa varios idiomas, si hay una forma idiomática de hacer algo que sea seguro en todos los idiomas, es una buena idea hacerlo de esa manera en todas partes para formar un buen hábito y son menos propensos a tropezar.

No puedo pensar en ningún lugar que if (!variable)(o sus equivalentes, como if not variabledepender de su idioma) no sea seguro, mientras que, por ejemplo, if self.is_ready() == False: ...no es seguro en Python si self.is_ready()regresa None, ahora o en el futuro, lo que sería algo totalmente razonable que haga. indicar que no estaba listo ya que Nonees tan falso como False.