Faire une grosse affaire de == vrai?

Il y a un de mes collègues qui écrit constamment:

if (someBool == true)

Cela me fait monter le mur! Devrais-je en faire tout un plat ou le laisser tomber?

Ce n'est qu'un code redondant, pas la vie ou la mort. Pourtant....

Si cela se produit someBoolsouvent , cela pourrait poser un problème de nom. Une bonne réputation peut contribuer grandement à éliminer le besoin de==true

if(IsSomeCondition)

ou

if(hasCondition)

ou

if(somethingExists)

par exemple.

Quand je vois someBool == true, je ne peux pas m'empêcher de penser que le programmeur n'a pas intériorisé l'idée de l' évaluation , ce qui constitue une lacune assez fondamentale.

Cependant, mon point de vue est biaisé parce que j'ai passé plusieurs étés dans l'enseignement d'un programme universitaire à des enfants, qui écrivaient souvent des expressions comme celle-ci parce qu'ils ne maîtrisaient vraiment pas l'exercice mental consistant à évaluer une expression. Une fois qu'ils ont adopté 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 à leurs débuts en programmation et qui n'a jamais bougé. Mais ça me ferait encore un peu peur si c'était la première chose que je voyais faire lors d'un entretien.

Cela me rend fou aussi, mais je dirais que leur mentionner la redondance de manière constructive et puis laisser tomber, même s'ils ne sont pas d'accord.

Vous pouvez également 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 deuxième partie de cette déclaration est redondante, elle s’évaluerait toujours comme vraie.

Vous: Par George, vous avez raison. Que je suis bête. Passons simplement à une version sans toute la redondance alors. Que diriez-vous?

if (someBool) {}

Je pense que si votre plus gros problème avec vos collègues est quelque chose d'aussi trivial, vous devriez vous considérer plutôt chanceux.

Vous devriez absolument arrêter cette mauvaise habitude. Doucement...

Il est facile d'oublier d'écrire les doubles signes d'égalité en transformant le code en:

if (someBool = true)

En C # par exemple, cela ne produira qu'un avertissement, pas une erreur. Ainsi, à moins que vous ne considériez les avertissements comme des erreurs, le code sera exécuté, définissez la variable sur true et entrez toujours la condition.

Je suis d'accord avec vous, mais je vais me faire l'avocat du diable ici:

Selon la langue et le nom de la variable, x == true convient:

Considérez la situation suivante dans un langage avec typage statique et contrainte 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. Donc, en ajoutant == true, il devient clair que x est un booléen et non un entier contraint en booléen:

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}

Qu'en est-il des bools nullable?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 

En règle générale, vous ne voulez pas faire grand-chose des conventions de codage à moins que cette convention ne gêne le projet de manière significative. J'ai assisté à de nombreuses discussions houleuses sur des choses aussi petites que des régions de code et des soulignements importants.

Cela étant dit, je ne vois aucun problème à ajouter == trueà une instruction conditionnelle. En fait, j'ai l'habitude d'utiliser == falseun point d'exclamation au lieu d'un point d'exclamation lorsque je teste des conditions négatives. Je pense que c'est plus lisible.

S'il y a une convention établie, je dis de la suivre à moins qu'il y ait une raison de changer. Cependant, cela ne vaut pas vraiment la peine de soulever 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 me "formate automatiquement" dans ma tête. La seule fois que j'utilise la syntaxe préférée de Joel, c'est lorsque la variable bool a un préfixe de verbe comme "est". J'ai besoin du verbe, que ce soit "est", "peut", "a fait" ou sinon j'ai besoin du == pour fournir le verbe "égal à". Je pourrais ne jamais rompre avec cette habitude, alors je comprendrai si vous ne me dites pas «bonjour» dans la rue.

me rappelle 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 vraiment la façon de dire "pas" dans les langages en langage C. Ce petit point d'exclamation est trop facile à négliger.

C'est pourquoi je l'écris en entier:

if (someCondition == false) {

Après avoir lu cela pendant un moment, je veux aussi de la symétrie avec

if (someCondition == true) {

Alors considérez-le 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, ne fais jamais ça. Il est trop facile de trouver une situation dans laquelle la valeur que vous testez n'est pas fausse (différente de zéro), mais n'est pas égale à la valeur unique définie comme "vraie".

En Ruby, faites ceci uniquement si vous êtes absolument certain de vouloir échouer sur tout, sauf Boolean true.

En C ++ et dans d’autres langages statiques de type bool, cette méthode est redondante et peut entraîner des erreurs de programmation lorsque vous tapez mal à la =place des ==erreurs de promotion, comme indiqué dans les commentaires.

Vous pensez 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 fait d'en parler ne fâche les gens, alors mon conseil est de l'oublier. Pardon!

vous devriez lui dire qu'il le fait mal.

ses

if (true == someBool) {

}

s'il en oublie un = il a de gros problèmes d'écriture.

Que diriez-vous

if (x == "true")

POURQUOI EST-CE UNE CHAÎNE?!

En fait, si la valeur est nullable, il serait nécessaire de tester x == true. :)

J'écris du code comme ça!

Voici pourquoi:

"if bla == true" se lit comme une phrase, où "if bla" ne le fait pas dans bien des cas. Cela sonne juste mal, lors de la lecture du code réel.

De plus, le compilateur met en garde sur les affectations dans if block, il n'y a donc vraiment aucun danger à utiliser == true. (confondant avec =)

De plus, les gars qui n'écrivent pas "== true" utilisent-ils "! ()" Pour "== false"? Je trouve ça vraiment moche. Et si vous utilisez "== false", il est très logique d'utiliser également "== true", au lieu de disposer de deux manières distinctes de vérifier la vérité.

N'oubliez pas que vous travaillez en équipe, vous devez donc régler ces problèmes ensemble. "Joue bien avec les autres" reste un trait de personnalité important même après l'école primaire :)

Généralement, on omettra le "== vrai", mais cela ne vaut même pas la peine d'en discuter, à moins que cela soit inclus dans les normes de codage de votre équipe.

Bien que je convienne en tant que développeur principalement en C #, je ne peux pas dire que ce soit toujours le cas. Par exemple, en Javascript, le === effectuera une coalescence de type. Donc en supposant que var x = 3 alors:

if(x) --> true

tandis que

if (x === true) --> false

Je suppose que c'est différent de == puisque même dans JS, je n'utiliserais pas si (x == vrai) mais juste quelque chose à penser.

Ce type de problème touche cependant à un autre point qui a été soulevé dans mon bureau:

bool b = false;

En C #, bool b; suffirait et inciterait b à faux . Cependant, il est plus explicite d’écrire la ligne ci-dessus et doit de toute façon être extrait par le compilateur lors de l’optimisation.

Donc, je suppose que ce que je veux dire, c’est que ce qui est et n’est pas une bonne pratique n’est pas toujours aussi évident et qu’il s’agit en grande partie de préférences, ainsi que de fonctionnalités linguistiques / bizarreries.

Ah oui, mais que se passe-t-il si la variable est nullable? (bool?)

Certaines langues (C #) nécessiteront un casting et une comparaison avec 'true'.

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}

Les jeunes connaissent les règles, mais les plus âgés connaissent les exceptions;)

Au plus tard C#, si vous avez affaire à a 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 trois états 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 Pythonplusieurs langues telles que celle que C/C++vous utilisez, vous pouvez ifutiliser une expression non booléenne. Ces langues ont des règles uniques pour interpréter les entiers, les pointeurs, les listes, etc. comme étant vrais ou faux. Parfois, vous ne voulez pas cela. Par exemple, dans cet extrait de code Python:

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

Ici zdevrait être True, mais z2devrait être False. Maintenant, un Clojurelangage aborde cela d’une autre manière encore - la andfonction n’évalue pas nécessairement en un bool, mais ifpeut le gérer.

Indépendamment de la langue, chaque fois que vous comparez quelque chose à Trueou False, il vaut probablement la peine de commenter.

Un tel codage m'aurait aussi mal frotté auparavant. Bien que votre exemple d'identification s'appelle "someBool", l'utilisation de ce style de codage par inadvertance sur une variable non garantie comme booléenne peut avoir un comportement inattendu. Si la valeur de "someBool" n'est pas exactement "true" ou "false", le résultat sera false.

L’année dernière, j’ai rencontré un bogue très subtil, causé par un tel style de codage difficile à identifier car les yeux brillaient au-dessus de telles constructions. Vous pensez, "Comment pourrait-il être faux?" Il en va de même pour les expressions bien comprises telles que "(var)" ou "(! Var)", que vous lisiez ou codiez sans les vérifier.

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.

1. Toutes les expressions doivent être entre parenthèses en fonction de leur intention.
2. Tous les tests booléens doivent être exprimés en négatif, comme "suchBool! = False".

En nettoyant le code qui n’était pas conforme au nouveau style, j’ai identifié et corrigé quelques autres cas de bugs aussi subtils.

Devait utiliser cela tout le temps dans ActionScript 2 (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 spécifique.

Je suis d'accord. C'est une construction redondante, spécialement dans les langages fortement typés.

Pour ajouter une autre utilisation abusive de booléens, j'ai trouvé ce type de construction plusieurs fois en Javascript, (spécialement lors de certaines fonctions monstres de type spaghetti, 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 à se préoccuper des false|undefinedvaleurs.

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 voudra ne pas appeler ce bloc pour qu'il le change:

if(something == true && false)

Et puis de temps en temps il le changera pour:

if(false)

Le pire, c’est que ce type de débogage m’a parfois échappé et qu’il est vraiment mauvais pour les autres développeurs de le lire!

Je dirais que la cohérence est roi dans une base de code. Donc, vous devriez utiliser le style, qui est principalement utilisé dans votre organisation. Essayez de faire de votre style préféré une partie des directives officielles de codage de la société. Si cela est déjà dans les directives, suivez-le.

(Cela étant dit, cela m'ennuierait aussi beaucoup - mais probablement pas assez pour en faire un gros problème).

Je préfère ne pas placer l'extrait == vrai, mais parfois je l'incline accidentellement et ne le remarque pas. La personne peut ne pas l'avoir remarquée et placée accidentellement. Je relis mon code et remarque parfois que j'ai placé l'extra == true, je supprime donc ce == true. Parfois, je ne le remarque pas et j'accueillerais volontiers quelqu'un qui me dirait que je l'ai placé de manière redondante.

que diriez-vous:

int j = 1;
for (int i=1; i>=j; i++) ...

Oui, je l'ai vu.