Faire une grosse affaire avec == vrai?
Il y a un de mes collègues qui écrit constamment:
if (someBool == true)
Ça me fait monter le mur! Dois-je en faire une grosse affaire ou simplement la laisser tomber?
Ce n'est qu'un code redondant, pas la vie ou la mort. Toutefois....
Si cela se produit souvent, cela pourrait être un problème avec le nom de someBool. Un bon nom peut grandement contribuer à éliminer le besoin de ==true
if(IsSomeCondition)
ou
if(hasCondition)
ou
if(somethingExists)
par exemple.
Quand je vois someBool == true, Je ne peux m'empêcher de penser que le programmeur n'a pas intériorisé l'idée de évaluation, ce qui est une lacune assez fondamentale.
Cependant, mon point de vue est biaisé parce que j'ai passé plusieurs étés à enseigner les programmes universitaires aux enfants, qui écrivaient fréquemment des expressions comme celle-ci parce qu'ils n'avaient vraiment pas maîtrisé l'exercice mental d'évaluation d'une expression. Une fois qu'ils ont cherché le concept, la redondance est devenue évidente.
Pour un programmeur professionnel par ailleurs compétent, ce n'est probablement pas le cas. C'est probablement juste une mauvaise habitude qu'ils ont développée dans leurs premiers jours de programmation et qui n'ont jamais vraiment tremblé. Mais cela me ferait encore un peu peur si c'était la première chose que je voyais quelqu'un faire dans une interview.
Cela me rend fou aussi, mais je dirais de mentionner la redondance de manière constructive et de la laisser tomber même s'ils ne sont pas d'accord.
Alternativement, vous pouvez essayer cette approche:
Vous: Pouvez-vous commencer à utiliser la convention de code suivante pour évaluer les booléens?
if (someBool==true)&&(true==true) {}
Eux: Pourquoi ferions-nous cela? La seconde moitié de cette déclaration est redondante, elle serait toujours évaluée à vrai.
Vous: Par George, vous avez raison. Que je suis bête. Disons simplement aller avec une version sans toute la redondance alors. Que diriez-vous?
if (someBool) {}
Je pense que, si quelque chose d'aussi banal est votre plus gros problème avec vos collègues, vous devriez vous considérer assez chanceux.
Vous devez absolument arrêter cette mauvaise habitude. Doucement...
Il est facile d'oublier d'écrire les doubles signes égaux, transformant le code en:
if (someBool = true)
En C # par exemple, cela ne produira qu'un avertissement, pas une erreur. Donc, sauf si vous traitez les avertissements comme des erreurs, le code s'exécutera, définissez la variable sur true et entrez toujours la condition.
Je suis d'accord avec vous, mais je vais jouer l'avocat du diable ici:
Selon la langue et le nom de la variable, x == true est approprié:
Considérez la situation suivante dans un langage avec typage statique et coercition de type pour les types intégraux:
if (actionsAllowed){
//do actions, since they are allowed
//...
}
Quelqu'un qui lit cette section du code peut ne pas se rendre compte immédiatement que actionsAllowed est une variable booléenne - il peut également s'agir d'un entier, représentant le nombre d'actions autorisées. Ainsi, en ajoutant == true, il devient clair que x est un booléen, et non un entier contraint à un booléen:
if (actionsAllowed == true){
//do actions, since they are allowed
//...
}
Qu'en est-il des bools annulables?
bool? MyFlag = null;
if (MyFlag == true)
;
if (MyFlag) // error, doesn't compile!
;
En règle générale, vous ne voulez pas faire grand cas des conventions de codage à moins que cette convention n'entrave en quelque sorte le projet de manière significative. J'ai vu de nombreux arguments enflammés sur des choses aussi petites que les régions de code et les soulignements principaux.
Cela étant dit, je ne vois aucun problème à ajouter == true à une instruction conditionnelle. En fait, j'ai l'habitude d'utiliser == false par opposition à un point d'exclamation principal lors du test de conditions négatives. Je pense que c'est plus lisible.
S'il existe une convention établie, je dis de la suivre, sauf s'il y a lieu de changer. Cependant, cela ne vaut pas vraiment la peine de faire une grosse odeur.
Ack. Je suis ce mec. La honte, la honte. C'est comme ça que j'ai appris, et c'est comme ça que je "formate automatiquement" dans ma tête. La seule fois où j'utilise la syntaxe préférée de Joel, c'est quand la variable bool a un préfixe de verbe comme "est". J'ai besoin du verbe, que ce soit "est", "peut", "a fait", ou bien j'ai besoin du == pour fournir le verbe "égal". Je pourrais ne jamais briser cette habitude, alors je comprendrai si vous ne me dites pas "bonjour" dans la rue.
rappelle-moi le "code de la folie booléenne", c'est comme ça
if(someBool == true)
otherBool = false;
else
otherBool = true
Au lieu de:
otherBool = !someBool
Personnellement, je n'aime pas du tout la façon de dire "non" dans les langages basés sur C. Ce petit point d'exclamation est trop facile à ignorer.
C'est pourquoi je l'écris en entier:
if (someCondition == false) {
Après avoir lu ça pendant un moment, je veux aussi la symétrie avec
if (someCondition == true) {
Considérez-le donc comme un artefact de C utilisant ! au lieu de not.
Cela dépend de la langue, mais c'est généralement une mauvaise idée ...
En C, jamais faites cela. Il est trop facile de trouver une situation dans laquelle la valeur que vous testez n'est pas fausse (non nulle), mais pas égale à la valeur unique définie comme "vraie".
Dans Ruby, ne faites cela que si vous êtes absolument certain de vouloir échouer sur tout sauf Boolean true.
En C++ et dans d'autres langages statiques de type booléen, il est redondant et peut entraîner des erreurs de programmation lorsque vous tapez mal = au lieu de ==, ou des erreurs de promotion comme mentionné dans les commentaires.
Tu penses que c'est mauvais? Que diriez-vous:
if(someCondition) {
return true;
} else {
return false;
}
Je préfère
if (bVal)
ou
if (!bVal)
aussi, mais je crains que le faire remonter ne fasse chier les gens, donc mon conseil est de l'oublier. Désolé!
vous devez lui dire qu'il se trompe.
ses
if (true == someBool) {
}
s'il en oublie un, il est en grande difficulté dans son style d'écriture.
Que diriez-vous
if (x == "true")
POURQUOI IS CETTE CHAÎNE?!
En fait, s'il est nullable, un test de x == true serait nécessaire. :)
J'écris du code comme ça!
Voici pourquoi:
"if bla == true" se lit comme une phrase, alors que "if bla" ne l'est pas dans de nombreux cas. Cela semble tout simplement faux, lors de la lecture du code réel.
De plus, le compilateur met en garde contre les affectations dans les blocs if, il n'y a donc vraiment aucun danger à utiliser == true. (en le confondant avec =)
Les gars qui n'écrivent pas "== true", utilisent-ils "! ()" Pour "== false"? Je trouve ça vraiment moche. Et si vous utilisez "== false", il n'est que très cohérent d'utiliser également "== true", au lieu d'avoir deux façons distinctes de vérifier la vérité.
N'oubliez pas que vous travaillez en équipe, vous devez donc travailler ensemble. "Joue bien avec les autres" est toujours un trait de personnalité important même après l'école primaire :)
Généralement, le "== true" sera omis, mais cela ne vaut même pas la peine d'en discuter à moins que vous ne l'ayez inclus dans les normes de codage de votre équipe.
Bien que je sois d'accord en tant que développeur principalement C #, je ne peux pas dire que c'est toujours le cas. Par exemple, en Javascript, le === effectuera la coalescence de type. En supposant donc var x = alors:
if(x) --> true
tandis que
if (x === true) --> false
Je suppose que c'est différent de == puisque même en JS je n'utiliserais pas si (x == true) mais juste quelque chose à penser.
Ce genre de touche cependant à un autre point qui a été soulevé dans mon bureau:
bool b = false;
En C #, bool b; serait suffisant et initialiserait b à false. Cependant, il est plus explicite d'écrire la ligne ci-dessus et de toute façon devrait être arraché par le compilateur lors de l'optimisation.
Donc, je suppose que mon point de vue n'est pas toujours si évident ce qui est et n'est pas une bonne pratique et cela se résume en grande partie aux préférences ainsi qu'aux fonctionnalités/bizarreries du langage.
Ah oui, mais que faire si la variable est nullable? (bool?)
Certains langages (C #) nécessiteront et seront castés ou comparés avec 'true'.
bool? isAccepted = true;
if((bool)isAccepted)
{...}
if(isAccepted == true)
{...}
Les jeunes connaissent les règles, mais les anciens connaissent les exceptions;)
Dans le dernier C#, si vous avez affaire à un null-able bool, alors vous devez:
bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
// That was the only way that is reasonably readable that I know of
// to accomplish this expression.
}
Si tristate n'est pas un problème, alors il ne devrait généralement pas y avoir de raison de comparer quelque chose à true/True. Cependant, dans Python et plusieurs autres langues telles que C/C++ vous pouvez effectuer un if sur une expression non booléenne. Ces langages ont des règles uniques pour interpréter les entiers, pointeurs, listes, etc. comme vrais ou faux. Parfois, vous ne voulez pas ça. Par exemple, dans cet extrait Python:
x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)
Ici, z devrait être True, mais z2 devrait être False. Maintenant, un langage Clojure aborde cela d'une autre manière encore - la fonction and n'évalue pas nécessairement un bool, mais le if peut gérer cela.
Quelle que soit la langue, chaque fois que vous vous retrouvez à comparer quelque chose à True ou False, cela vaut probablement la peine d'être commenté.
Un tel codage m'aurait également frotté dans le mauvais sens. Bien que votre identifiant d'exemple soit nommé "someBool", l'utilisation de ce style de codage par inadvertance sur une variable qui n'était pas garantie d'être un booléen pourrait avoir un comportement inattendu. Si la valeur de "someBool" n'est pas exactement "true" ou "false", le résultat sera faux.
J'ai rencontré un bug très subtil l'année dernière causé par un tel style de codage qui était difficile à identifier parce que les yeux brillent sur de telles constructions. Vous penseriez: "Comment cela pourrait-il être faux?" Il en va de même pour des expressions bien comprises telles que "(var)" ou "(! Var)", que vous les lisez ou les codez sans vérifier leur comportement.
J'ai donc introduit quelques normes de codage pour réduire l'existence de tels bogues dans la base de code et la probabilité que de tels bogues subtils se glissent accidentellement dans le futur.
- Toutes les expressions doivent être entre parenthèses selon leur intention.
- Tous les tests booléens doivent être exprimés par la négative, comme "suchBool! = False".
En nettoyant le code non conforme au nouveau style, j'ai identifié et corrigé quelques autres instances de ces bogues subtils.
J'ai dû utiliser cela tout le temps dans ActionScript 2 (certes maintenant un langage mort), car:
var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();
// this is slightly ambiguous
if(something)
{
}
// because if you allow undefined you might actually mean
if(false != something)
{
}
// which can mean something different than
if(true == something)
{
}
// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}
Il était donc presque toujours préférable d'être précis.
Je suis d'accord. C'est une construction redondante, spécialement dans les langages typés forts.
Pour ajouter une autre mauvaise utilisation des booléens, j'ai trouvé ce genre de construction plusieurs fois en Javascript, (en particulier pour certaines fonctions de monstre ressemblant à des spaghettis, comme dans plus de 100 lignes):
//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example
flag=$("mycheckbox").selected;
//...
//and at the moment of use it:
if(flag!=true) {
//code to execute when the checkbox is unchecked
}
Il semble qu'en raison de l'absence d'une définition de type stricte dans ce langage, certains programmeurs préfèrent ne pas avoir à déconner avec le false|undefined valeurs.
J'ai un collègue qui aura un code comme celui-ci:
if(something == true)
Et puis, pour une sorte de test/débogage, il souhaitera ne pas appeler ce bloc donc il le changera en:
if(something == true && false)
Et puis de temps en temps il le changera en:
if(false)
Le pire, c'est que ce type de débogage a parfois déteint sur moi et est vraiment mauvais à lire pour les autres développeurs!
Je dirais que la cohérence est reine dans une base de code. Vous devez donc utiliser le style, c'est-à-dire principalement utilisé dans votre organisation. Essayez d'intégrer votre style préféré aux directives de codage officielles de l'entreprise. Si c'est déjà dans les directives, suivez-le.
(Cela étant dit, cela me gênerait également beaucoup - mais probablement pas assez pour en faire une grosse affaire).
Je préfère ne pas placer le supplément == true, mais parfois je l'inclus accidentellement et je ne le remarque pas. La personne ne les a peut-être pas remarqués et les a accidentellement placés. Je relis mon code et remarque parfois que j'ai placé le supplément == true donc je le supprime == true. Parfois, je ne le remarque pas et j'accueillerais volontiers quelqu'un me disant que je l'ai placé de manière redondante.
Un de mes collègues s'appelle if a loop. J'ai vécu pour en parler.
On peut développer cette habitude quand on fait beaucoup de programmation en WPF. Il utilise beaucoup de bool? (booléen nullable) vous devez écrire if (someBool == true) ou if (someBool ?? false)
J'espère que vous utilisez un langage sensible, comme VB.NET avec Option Strict On, qui ne permet pas la coercition d'autres types sur Boolean dans une instruction If. Ensuite, il n'est pas nécessaire d'ajouter le "== true" (ou "= True" dans VB), car le cas de coercition ne peut pas se produire. Si vous voulez vérifier non différent de zéro, écrivez-le explicitement (c'est-à-dire "Si x <> 0").
que diriez-vous:
int j = 1;
for (int i=1; i>=j; i++) ...
Oui, je l'ai vu.
C'est une odeur de code pour un développeur novice. Ils doivent encore maîtriser/internaliser la condition booléenne et doivent explicitement évaluer la condition vraie ou fausse.
En JavaScript, je préfère if(bool) quand j'ai suffisamment de documentation expliquant ce que la méthode attend ... mais quand evaluation sur true peut signifier que la variable existe, est égal au nombre 1 ou au booléen c'est vrai, c'est plus difficile.
Taper fortement dans JS signifie également moins de flexibilité. Décision difficile. Langages fortement typés, posez le marteau. Sinon, demandez pourquoi il le fait?
En fait, il y a votre réponse: demandez-lui pourquoi. Corrigez-le ensuite.
l'utiliser comme une occasion de lui apprendre. il vous respectera davantage si vous le faites. ne voudriez-vous pas que quelqu'un fasse de même pour vous?
La recherche montre que le code avec de nombreuses redondances est fortement corrélé aux erreurs. Voici un article intéressant sur le sujet (alerte PDF).
La comparaison des booléens peut en fait causer des problèmes majeurs. J'ai récemment rencontré un code interne qui disait:
if(foo == false && bar == 2) {...}
Maintenant, cela semble assez simple, non? Simplifiez-le simplement pour:
if(!foo && bar == 2) {...}
Faux. Dans ce cas, l'ordre des opérations impose que le && est évalué en premier, ce qui signifie que cela donne vraiment:
if(foo == (false && bar == 2))
aussi connu sous le nom
if(!foo)
Cette chose supplémentaire que nous étions censés vérifier, bar == 2, a totalement disparu. C'est pourquoi je n'approuverai jamais un examen de code contenant someBool == [true|false].
(Vous pouvez voir comment l'instruction inverse, == true et ||, causerait également des problèmes.)
Oui, c'est une sorte de mentalité de programmeurs. Tout le temps ils considèrent que "si la condition" n'a pas d'existence sans une expression avec des symboles =, <,> ... J'ai vu des situations que les gens éprouvent vraiment des difficultés comme "retour de fonction"
if (RowsAffected> 0) {return true; } else {return false; }
Les programmeurs doivent regarder leur code sous l'angle en temps réel .. :)
Un problème en C est qu'il existe une tradition d'utilisation de valeurs autres que 0 et 1 pour les booléens.
typedef enum { WHATEVER = 1 << 4 } MyFlags;
if (flags & WHATEVER) {
}
ou même compter sur -1 comme vrai.
Le problème est que vous écrivez une API:
struct foo {
unsigned int bar : 1;
};
void myapi_foo_set_bar(struct foo *foo, int bar) {
foo->bar = bar;
}
Ici, si la barre n'est pas canonisée à 0 ou 1, elle ne rentrera pas dans le champ de bits et elle se cassera:
myapi_foo_set_bar(foo, flags & WHATEVER); /* broken */
Vous pouvez également trouver d'autres façons de casser les bools non canoniques, comme les comparer à VRAI ou FAUX comme dans la question!
Quoi qu'il en soit, ce que je viens de dire, c'est qu'il est souvent logique de canoniser un booléen:
foo->bar = bar != FALSE;
C'est une bizarrerie spécifique au C, bien sûr.
Oui, c'est un gros problème car le nom du booléen devrait indiquer qu'il est booléen. Dit si vous avez ce morceau de code:
bool arrayIsEmpty = array.length == 0;
if (arrayIsEmpty) { ... }
Il est déjà facile à lire, vous n'aurez donc pas besoin de == true, même pour la personne ou le programmeur ayant moins le sens de l'évaluation.
Les conventions de programmation ne sont pas nécessairement "correctes" ou "erronées". Ils existent pour donner au programme une structure familière à ceux qui le lisent, de sorte que les erreurs possibles ressortent plus clairement - il est difficile de "voir" un problème si tout vous semble légèrement faux.
L'important est que les conventions soient clairement définies et acceptées par tous les participants (même si l'accord est comme "J'accepte d'utiliser cette convention pendant que je travaille ici" :), sinon cela fait plus de mal que de bien.
Bien sûr, le cas particulier de la comparaison d'un booléen avec un vrai est tout à fait faux et doit être évité à tout prix. ;-)
J'écris si (var == false) car après avoir écrit var, je n'ai pas envie de revenir en arrière et d'écrire! derrière. J'aime aussi comment == false le rend plus clair.
Cependant == true est juste bizarre. Je ne sais pas s'il est utile de faire une grosse affaire. Je ne voudrais pas à moins qu'il ne pousse les autres à l'utiliser ou à en faire une norme de codage.
Vous pouvez essayer d'approcher votre collègue avec l'exemple suivant:
if ((x == 3) == true) {
...
}
Il devrait dire que le == true est redondant et doit être réécrit en
if (x == 3) {
...
}
depuis x == 3 est déjà une expression booléenne.
Maintenant, présentez-lui le someBool == true exemple, mais légèrement réécrit:
if ((someBool) == true) {
...
}
Puisque someBool est déjà un booléen, par comparaison avec l'exemple précédent, il devrait maintenant être clair que le == true est également redondant dans cet exemple. Ainsi, il devrait être réécrit comme suit:
if (someBool) {
...
}
Drôle parce que je remplace toujours du code comme:
if(foo) {
Avec:
if(true == foo) {
if(false == foo) {
Mais j'ai pris cette habitude parce que la plupart du temps, le code avec lequel je travaillais n'avait pas de noms de variables clairs.
Cela peut mettre certains de vos pseudos dans une liasse.
Nous avons des méthodes d'extension pour .IsTrue et .IsFalse pour le type bool.
Nous écrivons donc
if (someBool.IsTrue ())
-ou-
if (someBool.IsFalse ())
Oui! Et je les aime. En lisant du code, cela devient plus évident pour moi.