Un commentaire sur cette question: Vérifier si une méthode retourne false: assigne le résultat à une variable temporaire ou placez-vous une invocation de méthode directement au conditionnel? indique que vous devez utiliser !boolean
au lieu de boolean == false
lorsque les conditions de test. Pourquoi? Pour moi, boolean == false
c'est beaucoup plus naturel en anglais et c'est plus explicite. Je m'excuse s'il ne s'agit que d'une question de style, mais je me demandais s'il y avait une autre raison à cette préférence de !boolean
?
60
boolean == true
: ça n'a pas de sens. Les expressions à l'intérieur desif
instructions ne sont que cela: des expressions. Si quelque chose correspond déjà à une expression booléenne, pourquoi voudriez-vous ajouter un contrôle pour le forcer à évaluer?!boolean_variable
c'est la façon dont la plupart des programmeurs C le font, je suis d'accord.boolean != true
?Réponses:
Quand je vois une ligne comme celle-ci
if (!lateForMeeting())
, je lis que "Si pas en retard pour une réunion" , ce qui est assez simple à comprendre, par opposition àif (lateForMeeting() == false)
ce que je lisais comme "Si le fait que je sois en retard pour une réunion soit faux " .Leur sens est identique, mais le premier est plus proche de la façon dont la phrase anglaise équivalente serait construite.
la source
if not late_for_meeting
:)unless late_for_meeting
done()
. Les doubles négatifs sont mauvais.Ecrire
== false
et== true
est redondant. Cela peut aussi être pris à des extrêmes arbitraires. Si vous commencez à écrireAlors pourquoi pas
Ou pourquoi pas
La morale de cette histoire est que si
condition
est une expression booléenne, vous n'avez pas besoin d'ajouter== false
; c'est à cela que!
sert l' opérateur ;)la source
== false
n'est PAS redondant, mais plus verbeux que!
. OTOH,== true
est redondant.(exp1 != exp2)
vs((exp1 == exp2) == false)
. Certes, ce sont des scénarios artificiels, mais vous ne devriez presque jamais écrire de comparaisons explicites entre vrai et faux. Tout comme vous devriez utiliser opérateur!=
, vous devriez donc utiliser!
.!
.bool_expression == bool_literal
, le== ...
est redondant. Que vous testiez vrai ou faux n’a aucune importance. C'est juste un changement dans l'ordre des blocs conséquents / alternatifs. Les exemples d'Andres illustrent parfaitement ce point. La plupart des compilateurs modernes optimiseront la redondance, mais elle reste redondante.En C et certaines langues similaires, en comparant les expressions booléennes pour l' égalité à
false
outrue
est une habitude dangereuse.En C, toute expression scalaire (numérique ou pointeur) peut être utilisée dans un contexte booléen, par exemple en tant que condition d'une
if
instruction. La règle Cif (cond)
est équivalente àif (cond != 0)
- c’est- à -dire que zéro est faux et que toute valeur autre que zéro est vraie. Sicond
est de type pointeur,0
est traitée comme une constante de pointeur nulle.if (ptr)
des moyensif (ptr != NULL)
.Cela signifie que
et
ne veut pas dire la même chose . Le premier est vrai si
cond
est non nul; la seconde n'est vraie que si elle est égale àtrue
, ce qui en C (si vous avez#include <stdbool.h>
) est simplement1
.Par exemple, la
isdigit()
fonction déclarée dans<ctype.h>
renvoie uneint
valeur,0
si l'argument est un chiffre, différent de zéro s'il ne l'est pas. Il peut revenir42
pour indiquer que la condition est vraie. La comparaison42 == true
échouera.Il se trouve que
0
c'est la seule valeur considérée comme fausse, alors la comparaison pour l'égalitéfalse
fonctionnera;if (!cond)
etif (cond == false)
faire la même chose. Mais si vous voulez en tirer parti, vous devez vous rappeler que comparer àfalse
est correct, et que comparertrue
ne l’est pas. Pire encore, comparer àtrue
fonctionnera la plupart du temps (par exemple, les opérateurs d'égalité et relationnels donnent toujours un0
ou1
). Cela signifie que tous les bogues que vous introduisez en utilisant ceci pourraient être difficiles à localiser. (Ne vous inquiétez pas, ils apparaîtront dès que vous aurez présenté le code à un client important.)C ++ a des règles légèrement différentes. par exemple, son
bool
type est un peu plus étroitement intégré dans le langage et estif (cond)
converticond
en dactylographiebool
. Mais l'effet est (principalement) le même.Certaines autres langues ont ce que l’on pourrait appeler des booléens plus sages, tels que
cond == true
etcond == false
(ou quelle que soit la syntaxe qui s’avère) est sans danger. Malgré tout, chaque langue que j'ai vue a un opérateurnot
ou!
; c'est là, alors vous pourriez aussi bien l'utiliser. Utilisercond == false
plutôt que!cond
ounot cond
n'améliore pas, à mon avis, la lisibilité. (Il est vrai que le!
personnage peut être difficile à voir d'un coup d'œil; j'ajoute parfois un espace après le!
pour l'éviter.)Et souvent, vous pouvez éviter le problème et améliorer la clarté en réorganisant légèrement le code. Par exemple, plutôt que:
vous pourriez écrire:
Ce n'est pas toujours mieux, mais il n'y a pas de mal à chercher des opportunités là où elles se trouvent.
Résumé: En C et C ++, les comparaisons d'égalité à
true
etfalse
sont dangereux, trop bavard, et le style pauvre. Dans de nombreuses autres langues, de telles comparaisons ne sont peut-être pas dangereuses, mais elles sont toujours trop verbeuses et d'un style médiocre.la source
== true
c'est dangereux. Je me sens mieux comme ça.(==True) . f
pour préciser que nous voulons l'-> Bool
instanciation de la fonction polymorphe de retourf
. C'est plus clair quenot . not . f
et moins gênant que(f :: a -> Bool)
.pred(x)==pred(y)
pour une fonction de retour de boolpred
. L'alternative seraitpred(x)? pred(y) : !pred(y)
que vous conviendrez, c'est difficilement acceptable.pred(x)
etpred(y)
utilisez la même valeur pour indiquer la vérité, ce qui est une hypothèse sûre dans certaines langues mais pas dans d'autres. En C, par exemple, vous pourriez écrire!!pred(x) == !!pred(y)
.Les deux sont fonctionnellement identiques, donc utiliser est une question de goût.
La principale raison pour laquelle je l' utilise
== false
est que j'ai trouvé que!
trop facile d'oublier, quand on regarde le code.Ayant été sévèrement mordu par cela, j'ai pris l'habitude de le préciser très clairement lorsque je teste faux.
Si l'opérateur avait été nommé
not
en Pascal, je ne pense pas que cela serait devenu un problème.la source
== false
au lieu de!
pour la même raison (pour le faire ressortir). Cependant, il n’existait aucune obligation d’utilisation== true
, de sorte que toute valeur autre que zéro fonctionnait toujours comme il se doit.!
est probablement l’erreur la plus gênante de ce type, mais cela devrait inciter l’OMI à ne pas avoir l’habitude de prendre l’écriture==false
mais de mieux écrire les tests unitaires.Si
condition == false
est bien «beaucoup plus naturel en anglais» pour vous, alors je dois supposer que vous n’êtes pas un locuteur natif. Sinon, je ne peux pas expliquer cela, car personne ne parle comme ça:Comparez cela à
Cela dit, je conviens que le
!
code du caractère unique et élancé est facilement négligé. Pour cette raison, je préfère le mot clénot
lorsqu'il est pris en charge par la langue. C ++ , par exemple , ne permet cela bien que beaucoup de programmeurs ne sont pas au courant.Pour les langues qui nécessitent
!
, je mets un espace entre opérateur et opérande. Cela rend la négation beaucoup plus difficile à négliger:Notez que chaque programmeur doit traduire cela automatiquement , sans y réfléchir à deux fois, afin de «ne pas conditionner» dans sa tête. L’acquisition de ce genre de maîtrise de la lecture d’idiomes de code fait partie des premières étapes pour devenir un bon programmeur.
la source
Quand je vois,
var == false
je me demande toujours s'ilvar
s'agit d'un booléen ou d'un type logique avec plus de deux valeurs (avec, par exemple, unmaybe
et unundefined
ainsi quetrue
etfalse
, ou quelque chose comme les neuf valeurs de IEEE 1164 ).la source
parce que parfois vous pouvez écrire
boolean = false
(avec les erreurs évidentes) etfalse == boolean
ne semble pas naturel (peu importe la qualité de votre pratique)la source
if( INVALID_HANDLE_VALUE == hFile )
pour éviter des situations de ce genre. Ainsi, si vous vous trompez et utilisez un signe égal au lieu de deux, vous obtiendrez une erreur du compilateur. Évidemment, cela ne fonctionne que lorsque l'expression de gauche est une constante, mais cela m'a évité plus de maux de tête que je ne peux en compter.hFile==INVALID_HANDLE_VALUE
écriture naturelle .if (!boolean_variable)
se traduit parif the condition is not true
.if (boolean == false)
se traduit parif the condition not false is true
. Parce que c'est une logique inversée, il est plus difficile de comprendre.la source
isVisible
serait un meilleur exemple. Alorsif (!isVisible)
voudrait dire si non visible - ce qui est plus simple à comprendre alorsif (isVisible==false)
, qui est une logique inverse. J'espère que c'est plus clair maintenant. Ou ai-je mal compris votre commentaire?Dans les compilateurs (beaucoup) plus anciens, je pense qu'ils diviseraient (boolean == false) en 2 assignations de registre et un code de comparaison en langage machine. Le premier exemple serait divisé en une affectation et un opérateur NOT. En termes de performances, l'opération de comparaison prendrait plusieurs cycles d'horloge, en fonction de la taille du registre comparé, par rapport à une inversion au niveau du bit (1 horloge) et serait plus lente à exécuter.
Cela étant dit, je pense que les nouveaux compilateurs l’abandonnent, ce qui devrait être acceptable.
la source
Au travail, j’ai souvent affaire à des booléens qui peuvent être nuls alors je vais souvent coder ce cas comme suit:
parce que je pense personnellement que la symétrie facilite la lecture. Surtout s'il y a d'autres booléens testés.
Je ne me soucie pas vraiment d'une manière ou d'une autre.
la source
value == true
alors il n'y a aucune raison de vérifier que ce n'est pas nul. Sivalue == null
cela ne devrait jamais déclencher la déclaration if en premier lieu, celaif (value)
devrait être suffisant.if (value)
lève une exception. J'apprécierais que les gens qui votent par la négative donnent une raison.value == true
serait suffisant.Lorsque vous testez la condition vraie, il est logique de le faire
if (condition)
, en particulier lorsque vous appliquez la convention de nommage des variables booléennes commençant par «is»:if (isOpen)
est parfaitement claire et l'utilisation!= false
serait redondante.Pour un C / C ++ / Java / etc. programmeur, le sens du '!' l’opérateur est complètement assimilé, au point que nous n’avons automatiquement «pas» en tête lorsque nous le voyons. Donc, avoir
if (!isOpen)
est aussi clair queif (_NOT_ isOpen)
pour moi. Mais vous n'êtes pas assez familier. En C / C ++, vous pouvez créer une macro avec#define _NOT_ !
. Mais croyez-moi, après quelques années, c'est complètement inutile.De plus, il est toujours préférable de tester les valeurs booléennes sans les comparer avec les littéraux. Par exemple, il est dangereux de tester,
if (x == true)
car une valeur booléenne est considérée comme vraie si elle n’est pas nulle et que le vrai littéral n’a qu’une valeur spécifique. X peut donc être 'vrai' (c'est-à-dire différent de zéro) et la comparaison doit être évaluée à faux (car contient 2 et le vrai est littéralement, disons 1.) Bien sûr, cela ne s'applique pas à une comparaison avec false, mais si vous ne l'utilisez pas lors du test de true, pourquoi l'utiliser lors du test de false?la source
Questions de taille ;)
En expressions mixtes, il est plus facile de lire:
Et surtout pour Ruby un exemple où il y a une grande différence:
nil n'est pas faux, mais ce n'est pas vrai non plus.
la source
Basé sur mon expérience et les réponses de ma question que vous avez liées.
Certaines personnes préfèrent utiliser si (condition), car il est plus court à écrire. et pour moi, cela a du sens, par exemple (! isValidated ()) Je lis ceci comme étant non validé. mais pour moi tout est basé sur les préférences personnelles, et cela dépend de la structure logique de la méthode isValidated (), si elle retourne true ou false
la source
Si vous avez nommé votre variable correctement, alors
!boolean
c'est plus naturel. Cela se lit commenot boolean
n'importe qui qui est assez d'un programmeur pour lire le code mentalement.la source
Pour certaines personnes, plus tôt un sens est exprimé, mieux c'est.
Pour ceux qui ont "if! ..." se compare plus rapidement à "if ...", alors il faut lire toute la condition (ce qui pourrait en fait être assez long, par exemple (thisThing = thatThing ou quelque chose = autre chose) OU ( thinga = thingb et thinga = thingd), etc.) juste pour trouver le == faux à la fin.
Avoir le! (Je préfère en fait un pas quand la langue le permet) dès le début obtient l'anglais 'not' pour cette condition plus tôt.
Ce problème conduit également à envisager l’utilisation
until
dans les langues qui le supportent, par exemple, faire des «choses courantes» jusqu’à ce que tout soit terminé. Comme d’autres le disent, l’objectif est l’expression dans le langage naturel. J'aime l'exemple du "soleil brille" ci-dessus.la source
Une autre raison est que si vous travaillez dans une base de code qui utilise plusieurs langues, s'il existe un moyen idiomatique de faire quelque chose de sûr dans toutes les langues, c'est une très bonne idée de le faire partout pour que vous ayez une bonne habitude. et sont moins susceptibles de trébucher.
Je ne peux penser à aucun endroit où
if (!variable)
(ou des équivalents tels queif not variable
selon votre langue) n'est pas sûr, alors que par exemple, ilif self.is_ready() == False: ...
n'est pas sûr en python s'ilself.is_ready()
retourneNone
, maintenant ou à l'avenir, ce qui serait une chose tout à fait raisonnable à faire pour indique qu'il n'était pas prêt carNone
est aussi semblable à falseyFalse
.la source