Dois-je utiliser `!IsGood " ou " IsGood == false`?

Je ris toujours (ou je jette quelque chose à quelqu'un, selon mon humeur) quand je tombe sur

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

Parce que sûrement si vous ne pouvez pas compter sur le fait que votre comparaison renvoie un booléen, alors vous ne pouvez pas compter sur la comparaison du résultat à true non plus, donc le code devrait devenir

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

, Mais, bien sûr, cela devrait vraiment être

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

Mais, bien sûr ...

(ah, la compilation a échoué. De retour au travail.)

Je préférerais variante plus courte. Mais parfois == false aide à rendre votre code encore plus court:

Pour un scénario réel dans les projets utilisant C # 2.0, Je ne vois qu'une seule bonne raison de le faire: bool? type. Trois d'état-bool? est utile et il est facile de vérifier l'un de ses valeurs possibles de cette façon.

En Fait, vous ne pouvez pas utiliser (!IsGood) si IsGood est bool?. Mais écrire (IsGood.HasValue && IsGood.Value) est pire que (IsGood == true).

Jouez avec cet échantillon pour avoir une idée:

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");
}

Il y en a un de plus cas je viens de découvrir où if (!IsGood) { ... } n'est pas le même que if (IsGood == false) { ... }. Mais celui-ci n'est pas réaliste ;) la surcharge de L'opérateur peut aider ici:) (et l'opérateur true / false que AFAIK est découragé en C # 2.0 car il est destiné à fournir bool?comme le comportement de type défini par l'utilisateur, et maintenant vous pouvez l'obtenir avec type standard!)

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!");
                }
            }
        }
    }
}

Donc... veuillez utiliser la surcharge de l'opérateur avec prudence: (

Selon code complet un livre Jeff tire son nom de et tient en haute estime ce qui suit est la façon dont vous devez traiter les booléens.

if (IsGood)
if (!IsGood)

J'utilise pour comparer les booléens, mais j'ai pensé pourquoi ajouter une étape supplémentaire au processus et traiter les booléens comme des types de second ordre. À mon avis, une comparaison renvoie un booléen et un type booléen est déjà un booléen pourquoi ne pas simplement utiliser les booléens.

Vraiment ce que le débat se résume à utiliser le bien des noms pour vos booléens. Comme vous l'avez fait ci-dessus, j'exprime toujours mes objets booléens dans le for d'une question. Tels que

• IsGood
• HasValue
• etc.

La technique de test spécifique contre true ou false est définitivement mauvaise pratique si la variable en question est vraiment supposée être utilisée comme valeur booléenne (même si son type n'est pas booléen) - en particulier en C / C++. Tester contre true peut (et probablement le fera) conduire à des bugs subtils:

Ces tests apparemment similaires donnent des résultats opposés:

// 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;
}

Affiche le résultat suivant:

isGood != true
isGood is true

Si vous ressentez le besoin de tester la variable utilisée comme booléen flag against true/false (ce qui ne devrait pas être fait à mon avis), vous devriez utiliser l'idiome de toujours tester contre false car false ne peut avoir qu'une seule valeur (0) tandis qu'un true peut avoir plusieurs valeurs possibles (autre chose que 0):

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

Certaines personnes auront l'opinion que c'est une faille en C / C++, et cela peut être vrai. Mais c'est un fait de la vie dans ces langues (et probablement beaucoup d'autres) donc je m'en tiendrais à l'idiome court, même dans des langues comme C# qui ne le font pas vous permet d'utiliser une valeur intégrale en tant que booléen.

Voir cette question SO pour un exemple d'où ce problème a réellement mordu quelqu'un...

• isalpha () = = true est évalué à false??

Je suis d'accord avec vous (et je suis aussi agacé par cela). Je pense que c'est juste un léger malentendu que IsGood == true évalue à bool, ce qui est ce que IsGood était pour commencer.

Je vois souvent ces instances de SomeStringObject.ToString().

Cela dit, dans les langues qui jouent plus lâche avec les types, cela pourrait être justifié. Mais pas en C#.

Certaines personnes trouvent que la vérification explicite par rapport à une valeur connue est plus lisible, car vous pouvez déduire le type de variable en lisant. Je suis agnostique quant à savoir si l'un est meilleur que l'autre. Ils travaillent tous les deux. Je trouve que si la variable contient intrinsèquement un "inverse" alors je semble graviter vers la vérification par rapport à une valeur:

if(IsGood) DoSomething();

Ou

if(IsBad == false) DoSomething();

Au Lieu de

if(!IsBad) DoSomething();

Mais encore une fois, ça n'a pas beaucoup d'importance pour moi, et je suis sûr que ça finit comme le même IL.

Lisibilité uniquement..

Si quelque chose de la façon dont vous préférez est plus efficace lorsqu'il est compilé dans le code machine. Cependant, je m'attends à ce qu'ils produisent exactement le même code machine.

D'après les réponses jusqu'à présent, cela semble être le consensus:

1. la forme abrégée est la meilleure dans la plupart des cas. (IsGood et !IsGood)
2. les variables booléennes doivent être écrites comme positives. (IsGood au lieu de IsBad)
3. comme la plupart des compilateurs produiront le même code de toute façon, il n'y a pas de différence de performance, sauf dans le cas des langages interprétés.
4. Cette question n'a pas de gagnant clair pourrait probablement être considérée comme une bataille dans la guerre de religion de codage style.

Je préfère utiliser:

if (IsGood)
{
    DoSomething();
}

Et

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

Comme je trouve cela plus lisible - le ! est tout simplement trop facile à manquer( à la fois en lisant et en tapant); aussi " sinon IsGood alors..."juste ne semble pas juste quand je l'entends, par opposition à" Si IsGood est faux alors..."qui sonne mieux.

Il est possible (bien que peu probable, au moins j'espère) que dans le code C TRUE et FALSE soient #définis à des choses autres que 1 et 0. Par exemple, un programmeur peut avoir décidé d'utiliser 0 comme "true" et -1 comme "false" dans une API particulière. La même chose est vraie du code C++ hérité, puisque "true" Et "false" n'étaient pas toujours des mots-clés C++, en particulier la veille de l'existence d'une norme ANSI.

Il convient également de souligner que certains langages-en particulier ceux de script-Y comme Perl, JavaScript,et PHP-peuvent avoir des interprétations amusantes de ce que les valeurs comptent comme vrai et quelles valeurs comptent comme faux. Il est possible (bien que, encore une fois, peu probable sur les espoirs) que "foo == false" signifie quelque chose de subtilement différent de "!foo". Cette question est étiquetée "langue agnostique", et un langage peut définir l'opérateur == pour ne pas fonctionner de manière compatible avec le ! opérateur.

J'ai vu ce qui suit comme une exigence de style C/C++.

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

Le raisonnement était que si vous mettez accidentellement " = "au lieu de"==", le compilateur se sauvera en assignant une valeur à une constante. En attendant, cela nuit à la lisibilité de chaque instruction if.

Parfois, il a des utilisations en termes de lisibilité. Parfois, un appel de variable ou de fonction nommé peut finir par être un double négatif qui peut être déroutant, et rendre le test attendu explicite comme celui-ci peut faciliter la lisibilité.

Un bon exemple de ceci pourrait être strcmp () C / C++ qui renvoie 0 si les chaînes sont égales, sinon 0, selon l'endroit où la différence est. Donc, vous verrez souvent:

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

Généralement, cependant, je suis d'accord avec vous que

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

Est plus clair pour lire.

Je préfère le !Isgood approche, et je pense que la plupart des gens venant d'un fond de langage de style c le préféreront aussi. Je ne fais que deviner ici, mais je pense que la plupart des gens qui écrivent IsGood == False proviennent d'un fond de langue plus verbeux comme Visual Basic.

La seule chose pire est

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

N'a jamais compris la pensée derrière cette méthode.

Le modèle !IsGood est eaiser pour trouver que {[3] } lorsqu'il est réduit à une expression régulière.

/\b!IsGood\b/

Vs

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

Pour plus de lisibilité, vous pouvez envisager une propriété qui repose sur l'autre propriété:

public bool IsBad => !IsGood;

Ensuite, vous pouvez vraiment passer à travers le sens:

if (IsBad)
{
    ...
}

Je préfère !IsGood parce que pour moi, c'est plus clair et consise. Vérifier si un boolean == true est redondant, donc j'éviterais cela. Syntaxiquement cependant, je ne pense pas qu'il y ait une différence vérifiant si IsGood == false.

Dans de nombreux langages, la différence est que dans un cas, le compilateur / interpréteur dicte la signification de true ou false, tandis que dans l'autre cas, il est défini par le code. C est un bon exemple de cela.

if (something) ...

Dans l'exemple ci-dessus, "quelque chose" est comparé à la définition du compilateur de "true"."Habituellement, cela signifie" pas zéro."

if (something == true) ...

Dans l'exemple ci-dessus, "quelque chose" est comparé à "vrai."À la fois le type de "vrai" (et donc la comparabilité) et la valeur de "true" peut ou non être définie par le langage et / ou le compilateur/interpréteur.

Souvent, les deux ne sont pas les mêmes.

Vous avez oublié:

If (IsGood = = FileNotFound)

Il me semble (bien que je n'ai aucune preuve pour sauvegarder cela) que les gens qui commencent dans les langages de type C#/java préfèrent la méthode "if (CheckSomething ())", tandis que les gens qui commencent dans d'autres langages (C++: spécifiquement Win32 C++) ont tendance à utiliser l'autre méthode par habitude: dans Win32 "if (checksomething())" ne fonctionnera pas si CheckSomething renvoie un BOOL (au lieu une valeur true/false (qui est ce qu'un bool être).

J'ai toujours utilisé la méthode la plus verbeuse, encore une fois, par habitude. Ils sont syntaxiquement les mêmes; je n'achète pas le non-sens "verbosité m'irrite", parce que le programmeur n'est pas celui qui a besoin d'être impressionné par le code (l'ordinateur le fait). Et, dans le monde réel, le niveau de compétence de toute personne en regardant le code que j'ai écrit varie, et je n'ai pas le temps ou l'envie d'expliquer les particularités de l'évaluation de la déclaration à quelqu'un qui ne comprend peut-être pas peu des morceaux sans importance comme ça.

Ah, j'ai un peu co-travaillé en faveur de la forme plus longue, arguant qu'elle est plus lisible que la minuscule !

J'ai commencé à" réparer " cela, puisque les booléens sont autosuffisants, alors j'ai abandonné la croisade... ^_^ Ils n'aiment pas le nettoyage du code ici, de toute façon, arguant que cela rend l'intégration entre les branches difficile (c'est vrai, mais alors vous vivez éternellement avec du code mauvais...).

Si vous écrivez correctement votre nom de variable booléenne, il devrait se lire naturellement:
if (isSuccessful) vs. if (returnCode)

Je pourrais me livrer à la comparaison booléenne dans certains cas, comme:
if (PropertyProvider.getBooleanProperty(SOME_SETTING, true) == true) parce qu'il lit moins "naturellement".

Pour une raison quelconque, j'ai toujours aimé

if (IsGood)

Plus de

if (!IsBad)

Et c'est pourquoi j'aime Ruby moins (mais c'est un peu trop facile pour les abus):

unless (IsBad)

Et encore plus si utilisé comme ceci:

raise InvalidColor unless AllowedColors.include?(color)

Cybis, lors du codage en C++, vous pouvez également utiliser le pas clé. Il fait partie de la norme depuis longtemps, donc ce code est parfaitement valide:

if (not foo ())
   bar ();

Edit: BTW, j'ai oublié de mentionner que la norme définit également d'autres boolean des mots clés tels que et (&&), bitand (&), ou (||), bitor (|), xor (^)... Ils sont appelés synonymes d'opérateur.

Si vous pensez vraiment que vous avez besoin:

if (Flag == true)

Ensuite, puisque l'expression conditionnelle est elle-même booléenne, vous voulez probablement l'étendre à:

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

Et ainsi de suite. Combien de clous de plus ce cercueil a-t-il besoin?

Si vous travaillez en perl, vous avez la possibilité de

unless($isGood)

, je n'utilise pas ==, mais parfois j'utilise != parce que c'est plus clair dans mon esprit. Mais à mon travail, nous n'utilisons pas != ou ==. Nous essayons d'obtenir un nom qui est significat si avec hasXYZ() ou isABC().

Personnellement, je préfère la forme dont parle oncle Bob dans le code propre:

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

bool ShouldDoSomething()
{
    return IsGood;
}

Où les Conditions, à l'exception des plus triviales, sont mises dans les fonctions de prédicat. Ensuite, peu importe la lisibilité de l'implémentation de l'expression booléenne.

Nous avons tendance à faire ce qui suit ici:

if(IsGood)

Ou

if(IsGood == false)

La raison en est que nous avons un code hérité écrit par un gars qui n'est plus ici (en Delphi) qui ressemble à:

if not IsNotGuam then

Cela nous a causé beaucoup de douleur dans le passé, il a donc été décidé que nous essayerions toujours de vérifier le positif; si cela n'était pas possible, comparez le négatif au faux.

La seule fois où je peux penser où le code plus vebose avait du sens était dans pre-.NET Visual Basic où true Et false étaient en fait des entiers(true = -1, false = 0) et les expressions booléennes étaient considérées comme fausses si elles étaient évaluées à zéro et true pour toute autre valeur non nulle. Donc, dans le cas de l'ancien VB, les deux méthodes listées n'étaient pas réellement équivalentes et si vous vouliez seulement que quelque chose soit vrai s'il était évalué à -1, vous deviez explicitement comparer à 'true'. Donc, une expression qui évalue à "+1 " serait vrai s'il était évalué comme entier (car il n'est pas nul) mais il ne serait pas équivalent à 'true'. Je ne sais pas pourquoi VB a été conçu de cette façon, mais je vois beaucoup d'expressions booléennes comparant les variables à true Et false dans l'ancien code VB.