Debería usar"!IsGood` o `IsGood == false`?

Siempre me río (o tiro algo a alguien, dependiendo de mi estado de ánimo) cuando me encuentro

if (someBoolean == true) { /* ... */ }

Porque seguramente si no puede confiar en el hecho de que su comparación devuelve un booleano, entonces tampoco puede confiar en comparar el resultado con true, por lo que el código debería convertirse en

if ((someBoolean == true) == true) { /* ... */ }

Pero, por supuesto, esto realmente debería ser

if (((someBoolean == true) == true) == true) { /* ... */ }

Pero, por supuesto ...

(ah, la compilación falló. De vuelta al trabajo.)

Preferiría una variante más corta. Pero a veces == false ayuda a hacer su código aún más corto:

Para el escenario de la vida real en proyectos que usan C# 2.0, solo veo una buena razón para hacer esto: bool? type. Three-state bool? es útil y es fácil comprobar uno de sus posibles valores de esta manera.

En Realidad no se puede usar (!IsGood) si IsGood es bool?. Pero escribir (IsGood.HasValue && IsGood.Value) es peor que (IsGood == true).

Juegue con esta muestra para hacerse una idea:

bool? value = true; // try false and null too

if (value == true)
{
    Console.WriteLine("value is true");
}
else if (value == false)
{
    Console.WriteLine("value is false");
}
else
{
    Console.WriteLine("value is null");
}

Hay uno más caso que acabo de descubrir donde if (!IsGood) { ... } no es lo mismo que if (IsGood == false) { ... }. Pero este no es realista ;) La sobrecarga del operador puede ayudar aquí:) (y el operador true/false que AFAIK se desaconseja en C# 2.0 porque su propósito es proporcionar bool?- como el comportamiento de tipo definido por el usuario y ahora se puede obtener con el tipo estándar!)

using System;

namespace BoolHack
{
    class Program
    {
        public struct CrazyBool
        {
            private readonly bool value;

            public CrazyBool(bool value)
            {
                this.value = value;
            }

            // Just to make nice init possible ;)
            public static implicit operator CrazyBool(bool value)
            {
                return new CrazyBool(value);
            }

            public static bool operator==(CrazyBool crazyBool, bool value)
            {
                return crazyBool.value == value;
            }

            public static bool operator!=(CrazyBool crazyBool, bool value)
            {
                return crazyBool.value != value;
            }

            #region Twisted logic!

            public static bool operator true(CrazyBool crazyBool)
            {
                return !crazyBool.value;
            }

            public static bool operator false(CrazyBool crazyBool)
            {
                return crazyBool.value;
            }

            #endregion Twisted logic!
        }

        static void Main()
        {
            CrazyBool IsGood = false;

            if (IsGood)
            {
                if (IsGood == false)
                {
                    Console.WriteLine("Now you should understand why those type is called CrazyBool!");
                }
            }
        }
    }
}

So... por favor, utilice la sobrecarga del operador con precaución :(

De acuerdo con el Código Complete un libro Jeff obtuvo su nombre de y tiene en alta estima la siguiente es la forma en que debe tratar a los booleanos.

if (IsGood)
if (!IsGood)

Uso para ir con realmente comparar los booleanos, pero me imaginé por qué agregar un paso adicional al proceso y tratar a los booleanos como tipos de segunda tasa. En mi opinión, una comparación devuelve un booleano y un tipo booleano ya es un booleano, así que por qué no solo usar el booleano.

Realmente a lo que se reduce el debate es usar buenas nombres para tus booleanos. Al igual que lo hizo anteriormente siempre frase mis objetos booleanos en el para de una pregunta. Tales como

• IsGood
• HasValue
• etc.

La técnica de probar específicamente contra true o false es definitivamente una mala práctica si la variable en cuestión realmente se supone que debe usarse como un valor booleano (incluso si su tipo no es booleano), especialmente en C/C++. Probar con true puede (y probablemente lo hará) conducir a errores sutiles:

Estas pruebas aparentemente similares dan resultados opuestos:

// needs C++ to get true/false keywords
// or needs macros (or something) defining true/false appropriately
int main( int argc, char* argv[])
{
    int isGood = -1;

    if (isGood == true) {
        printf( "isGood == true\n");
    }
    else {
        printf( "isGood != true\n");
    }

    if (isGood) {
        printf( "isGood is true\n");
    }
    else {
        printf( "isGood is not true\n");
    }

    return 0;
}

Esto muestra el siguiente resultado:

isGood != true
isGood is true

Si siente la necesidad de probar la variable que se usa como booleana flag contra true / false (lo que no debería hacerse en mi opinión), debe usar el modismo de siempre probar contra false porque false solo puede tener un valor (0) mientras que un true puede tener múltiples valores posibles (cualquier cosa que no sea 0):

if (isGood != false) ...  // instead of using if (isGood == true)

Algunas personas opinarán que esto es un defecto en C/C++, y eso puede ser cierto. Pero es un hecho de la vida en esos idiomas (y probablemente muchos otros), por lo que me quedaría con el modismo corto, incluso en idiomas como C# que no lo hacen le permiten utilizar un valor integral como booleano.

Ver esta pregunta SO para un ejemplo de donde este problema realmente mordió a alguien...

• isalpha () = = true evalúa a false??

Estoy de acuerdo contigo (y también estoy molesto por ello). Creo que es solo un ligero malentendido que IsGood == true evalúa a bool, que es lo que IsGood fue para empezar.

A menudo veo estos casos cercanos de SomeStringObject.ToString().

Dicho esto, en los lenguajes que juegan menos con los tipos, esto podría estar justificado. Pero no en C#.

Algunas personas encuentran que la comprobación explícita contra un valor conocido es más legible, ya que puede inferir el tipo de variable leyendo. Soy agnóstico en cuanto a si uno es mejor que el otro. Ambos funcionan. Encuentro que si la variable contiene inherentemente un "inverso" entonces me parece gravitar hacia la comprobación contra un valor:

if(IsGood) DoSomething();

O

if(IsBad == false) DoSomething();

En lugar de

if(!IsBad) DoSomething();

Pero de nuevo, no me importa mucho, y estoy seguro de que termina como el mismo IL.

Solo legibilidad..

En todo caso, la forma que prefiera es más eficiente cuando se compila en código máquina. Sin embargo, espero que produzcan exactamente el mismo código máquina.

De las respuestas hasta ahora, este parece ser el consenso:

1. La forma corta es la mejor en la mayoría de los casos. (IsGood y !IsGood)
2. Las variables booleanas deben escribirse como positivas. (IsGood en lugar de IsBad)
3. Dado que la mayoría de los compiladores emitirán el mismo código de cualquier manera, no hay diferencia de rendimiento, excepto en el caso de los lenguajes interpretados.
4. Este tema no tiene un ganador claro probablemente podría ser visto como una batalla en la guerra religiosa de la codificación estilo.

Prefiero usar:

if (IsGood)
{
    DoSomething();
}

Y

if (IsGood == false)
{
    DoSomething();
}

Como me parece más legible-el ! es simplemente demasiado fácil de perder (tanto en la lectura como en la escritura); también "si no es bueno entonces..."simplemente no suena bien cuando lo escucho, a diferencia de" si IsGood es falso entonces...", que suena mejor.

Es posible (aunque poco probable, al menos espero) que en el código C TRUE y FALSE se #definan a cosas que no sean 1 y 0. Por ejemplo, un programador podría haber decidido usar 0 como " verdadero "y -1 como" falso " en una API en particular. Lo mismo ocurre con el código heredado de C++, ya que "true" y "false" no siempre eran palabras clave de C++, particularmente en el día antes de que existiera un estándar ANSI.

También vale la pena señalar que algunos lenguajes particularly particularmente los script-y como Perl, JavaScript y PHP can pueden tener interpretaciones divertidas de qué valores cuentan como verdaderos y qué valores cuentan como falsos. Es posible (aunque, de nuevo, poco probable en las esperanzas) que "foo == falso" significa algo sutilmente diferente de "!foo". Esta pregunta está etiquetada como "language agnostic", y un lenguaje puede definir el operador == para que no funcione de manera compatible con el ! operador.

He visto lo siguiente como un requisito de estilo C/C++.

if ( true == FunctionCall()) {
  // stuff
}

El razonamiento fue que si accidentalmente pones "=" en lugar de "==", el compilador abandonará la asignación de un valor a una constante. Mientras tanto, perjudica la legibilidad de cada declaración if.

Ocasionalmente tiene usos en términos de legibilidad. A veces, una llamada a una variable o función con nombre puede terminar siendo una doble negativa, lo que puede ser confuso, y hacer que la prueba esperada sea explícita como esta puede ayudar a la legibilidad.

Un buen ejemplo de esto podría ser strcmp() C/C++ que devuelve 0 si las cadenas son iguales, de lo contrario 0, dependiendo de dónde esté la diferencia. Así que a menudo verás:

if(strcmp(string1, string2)==0) { /*do something*/ }

En general, sin embargo, estoy de acuerdo con usted que

if(!isCached)
{
    Cache(thing);
}

Es más claro para Leer.

Prefiero el !IsGood enfoque, y creo que la mayoría de la gente que viene de un fondo de lenguaje de estilo c lo preferirá también. Solo estoy adivinando aquí, pero creo que la mayoría de las personas que escriben IsGood == False provienen de un fondo de lenguaje más detallado como Visual Basic.

Lo único peor es

if (true == IsGood) {....

Nunca entendí el pensamiento detrás de ese método.

El patrón !IsGood es más fácil de encontrar que IsGood == false cuando se reduce a una expresión regular.

/\b!IsGood\b/

Vs

/\bIsGood\s*==\s*false\b/
/\bIsGood\s*!=\s*true\b/
/\bIsGood\s*(?:==\s*false|!=\s*true)\b/

Para la legibilidad, puede considerar una propiedad que depende de la otra propiedad:

public bool IsBad => !IsGood;

Entonces, realmente puedes entender el significado:

if (IsBad)
{
    ...
}

Prefiero !IsGood porque para mí, es más claro y consise. Comprobando si un boolean == true es redundante, así que evitaría eso. Sintácticamente, sin embargo, no creo que haya una diferencia comprobando si IsGood == false.

En muchos idiomas, la diferencia es que en un caso, el compilador/intérprete dicta el significado de verdadero o falso, mientras que en el otro caso, está siendo definido por el código. C es un buen ejemplo de esto.

if (something) ...

En el ejemplo anterior, "algo" se compara con la definición del compilador de "true."Usualmente esto significa" no cero."

if (something == true) ...

En el ejemplo anterior, "algo" se compara con "verdadero"."Tanto el tipo de "verdadero" (y por lo tanto la comparabilidad) y el valor de "verdadero" puede o no ser definido por el lenguaje y/o el compilador/intérprete.

A menudo los dos no son lo mismo.

Olvidaste:

If (IsGood = = FileNotFound )

Me parece (aunque no tengo pruebas para respaldar esto) que las personas que comienzan en lenguajes de tipo C#/java prefieren el método "if (CheckSomething ())", mientras que las personas que comienzan en otros lenguajes (C++: específicamente Win32 C++) tienden a usar el otro método por costumbre: en Win32 "if (CheckSomething())" no funcionará si CheckSomething devuelve un BOOL (en lugar de un bool); y en muchos casos, las funciones de la API devuelven explícitamente un 0/1 int/INT en lugar de un valor verdadero/falso (que es lo que un BOOL ser).

Siempre he usado el método más detallado, de nuevo, por costumbre. Son sintácticamente los mismos; no compro la tontería de "verbosidad me irrita", porque el programador no es el que necesita ser impresionado por el código (el ordenador lo hace). Y, en el mundo real, el nivel de habilidad de cualquier persona dada que mira el código que he escrito variará, y no tengo el tiempo o la inclinación para explicar las peculiaridades de la evaluación de la declaración a alguien que puede no entender poco cosas sin importancia como esa.

Ah, tengo algunos co-trabajado a favor de la forma más larga, argumentando que es más legible que el pequeño !

Empecé a "arreglar" eso, ya que los booleanos son autosuficientes, entonces dejé la cruzada... ^ _ ^ No les gusta limpiar el código aquí, de todos modos, argumentando que hace difícil la integración entre ramas (eso es cierto, pero luego vives para siempre con código mal parecido...).

Si escribe correctamente su nombre de variable booleana, debería leerse naturalmente:
if (isSuccessful) vs. if (returnCode)

Podría complacerme en la comparación booleana en algunos casos, como:
if (PropertyProvider.getBooleanProperty(SOME_SETTING, true) == true) porque se lee menos "naturalmente".

Por alguna razón siempre me ha gustado

if (IsGood)

Más que

if (!IsBad)

Y es por eso que me gusta Ruby a menos que (pero es un poco demasiado fácil de abusar):

unless (IsBad)

Y aún más si se usa así:

raise InvalidColor unless AllowedColors.include?(color)

Cybis, al codificar en C++ también puede usar la palabra clave no . Es parte del estándar desde hace mucho tiempo, por lo que este código es perfectamente válido:

if (not foo ())
   bar ();

Edit: por CIERTO, se me olvidó mencionar que el estándar también define otros booleano palabras clave, tales como y (&&), bitand (&), o (||), bitor (|), xor (^)... Se llaman sinónimos de operador.

Si realmente crees que necesitas:

if (Flag == true)

Entonces, dado que la expresión condicional es en sí misma booleana, probablemente desee expandirla a:

if ((Flag == true) == true)

Y así sucesivamente. ¿Cuántos clavos más necesita este ataúd?

Si está trabajando en perl, tiene la opción de

unless($isGood)

No uso == pero en algún momento uso != porque es más claro en mi mente. PERO en mi trabajo no usamos != o ==. Tratamos de obtener un nombre que es significat si con hasXYZ() o isABC().

Personalmente, prefiero la forma de la que el Tío Bob habla en Clean Code:

(...)
    if (ShouldDoSomething())
    {
        DoSomething();
    }
(...)

bool ShouldDoSomething()
{
    return IsGood;
}

Donde los condicionales, excepto los más triviales, se ponen en funciones predicadas. Entonces importa menos lo legible que sea la implementación de la expresión booleana.

Tendemos a hacer lo siguiente aquí:

if(IsGood)

O

if(IsGood == false)

La razón de esto es porque tenemos un código heredado escrito por un tipo que ya no está aquí (en Delphi) que se parece a:

if not IsNotGuam then

Esto nos ha causado mucho dolor en el pasado, por lo que se decidió que siempre trataríamos de verificar lo positivo; si eso no era posible, entonces compararíamos lo negativo con lo falso.

La única vez que puedo pensar donde el código más vebose tenía sentido estaba en pre-.NET Visual Basic donde true y false eran en realidad enteros (true=-1, false = 0) y las expresiones booleanas se consideraban false si evaluaban a cero y true para cualquier otro valor distinto de cero. Por lo tanto, en el caso del antiguo VB, los dos métodos enumerados no eran realmente equivalentes y si solo querías que algo fuera verdadero si se evaluaba a -1, tenías que comparar explícitamente con 'verdadero'. Por lo tanto, una expresión que evalúa a "+1 " sería verdadero si se evaluara como entero (porque no es cero) pero no sería equivalente a 'verdadero'. No se por qué VB fue diseñado de esa manera, pero veo muchas expresiones booleanas comparando variables con true y false en el antiguo código VB.