Est-ce mauvais de comparer explicitement avec les constantes booléennes, par exemple si (b == false) en Java?

Ce n’est pas nécessairement mauvais, c’est simplement superflu. En outre, le nom de la variable réelle pèse beaucoup. Je préférerais par exemple if (userIsAllowedToLogin) ci if (b) dessus if (b) ou même pire if (flag) .

En ce qui concerne les performances, le compilateur l’optimise à tout moment.

Mise à jour : en ce qui concerne les sources faisant autorité, je ne peux pas trouver quelque chose explicitement dans les conventions de codage de Sun , mais au moins, Checkstyle a un module SimplifyBooleanExpression qui vous en avertit.

Vous ne devriez pas utiliser le premier style. J’ai vu des gens utiliser:

• if ( b == true )
• if ( b == false )

J’ai personnellement du mal à lire mais c’est passable. Cependant, un gros problème avec ce style est qu’il conduit aux exemples incroyablement contre-intuitifs que vous avez montrés:

• if ( b != true )
• if ( b != false )

Cela demande plus d’efforts de la part du lecteur pour déterminer l’intention des auteurs. Personnellement, je trouve qu’inclure une comparaison explicite avec true ou false est redondant et donc plus difficile à lire, mais c’est moi.

C’est une question de goût.

Personnellement, j’ai trouvé que if (!a) { est beaucoup moins lisible (EDIT: pour moi) que if (a == false) { et donc plus enclin aux erreurs lors de la maintenance du code plus tard, et que je me suis converti pour utiliser la dernière forme.

Fondamentalement, je n’aime pas le choix des symboles pour les opérations logiques au lieu des mots (C contre Pascal), car pour moi a = 10 and not b = 20 lit plus facilement qu’un a == 10 && !(b==20) , mais c’est le comme c’est en Java.

Quiconque met le “== faux” en faveur de “!” clairement n’avait jamais regardé le code trop longtemps et raté ce point d’exclamation. Oui, vous pouvez obtenir un code aveugle.

La raison principale pour laquelle vous ne devriez pas utiliser le premier style est que les deux sont valides:

 if (b = false) //... while (b = true) //... 

Autrement dit, si vous omettez accidentellement un caractère, vous créez une affectation au lieu d’une comparaison. Une expression d’affectation correspond à la valeur affectée. Par conséquent, la première instruction ci-dessus assigne la valeur false à b et donne la valeur false . Le second atsortingbue la valeur true à b , il est donc toujours évalué à true , peu importe ce que vous faites avec b dans la boucle.

Je n’ai jamais vu le premier sauf en code écrit par des débutants; c’est toujours le dernier, et je ne pense pas que quiconque soit vraiment confus. Par contre, je pense

 int x; ... if(x) //... 

contre

 if(x != 0) //... 

est beaucoup plus discutable, et dans ce cas je préfère le second

IMHO, je pense que si vous faites juste les noms de variables bool précédés de "Is" , ce sera évident et plus significatif et vous pourrez alors supprimer la comparaison explicite avec true ou false

Exemple:

 isEdited // use IsEdited in case of property names isAuthorized // use IsAuthorized in case of property names 

etc

Je préfère le premier parce que c’est plus clair. La machine peut lire aussi bien, mais j’essaie d’écrire du code pour que d’autres personnes puissent le lire, pas seulement la machine.

Je préfère l’approche longue, mais je compare en utilisant == au lieu de != 99% du temps.

Je sais que cette question concerne Java, mais je change souvent de langue, et en C# , par exemple, la comparaison avec (pour isntance) == false peut aider à gérer les types de bool nullables. J’ai donc eu cette habilité de comparer avec true ou false mais en utilisant l’opérateur == .

Je fais ça:

if(isSomething == false) ou if(isSomething == true)

mais je déteste ceux-ci:

if(isSomething != false) ou if(isSomething != true)

pour des raisons de lisibilité évidentes!

Tant que vous gardez votre code lisible, cela n’aura aucune importance.

Personnellement, je réorganiserais le code pour ne pas utiliser de test négatif. par exemple.

 if (b == false) { // false } else { // true } 

ou

 boolean b = false; while(b == false) { if (condition) b = true; } 

À mon humble avis, dans 90% des cas, le code peut être modifié afin que le test négatif ne soit pas requirejs.

À mon avis, c’est tout simplement ennuyeux. Pas quelque chose que je provoquerais un chahut quand même.

La ligne direcsortingce normale est de ne jamais tester contre booléen. Certains prétendent que la verbosité supplémentaire ajoute à la clarté. Le code ajouté peut aider certaines personnes, mais chaque lecteur devra lire plus de code.

Ce matin, j’ai perdu 1/2 heure pour trouver un bug. Le code était

  if ( !strcmp(runway_in_use,"CLOSED") == IPAS_FALSE) printf(" ACTIVE FALSE \n"); else printf(" ACTIVE TRUE \n"); 

S’il était codé avec la convention normale, j’aurais vu beaucoup plus vite que c’était faux:

  if (strcmp(runway_in_use, "CLOSED")) printf(" ACTIVE FALSE \n"); else printf(" ACTIVE TRUE \n"); 

Ceci est ma première réponse sur StackOverflow alors soyez gentil … Récemment, lors du refactoring, j’ai remarqué que 2 blocs de code avaient presque le même code mais

 for (Alert alert : alerts) { Long currentId = alert.getUserId(); if (vipList.contains(currentId)) { customersToNotify.add(alert); if (customersToNotify.size() == maxAlerts) { break; } } } 

et l’autre avait

 for (Alert alert : alerts) { Long currentId = alert.getUserId(); if (!vipList.contains(currentId)) { customersToNotify.add(alert); if (customersToNotify.size() == maxAlerts) { break; } } } 

donc dans ce cas, il était logique de créer une méthode qui a fonctionné pour les deux conditions comme celle-ci en utilisant la boolean == condition pour retourner la signification

 private void appendCustomersToNotify(List alerts List customersToNotify, List vipList, boolean vip){ for (Alert alert : alerts) { Long currentId = alertItem.getUserId(); if (vip == vipList.contains(currentId)) { customersToNotify.add(alertItem); if (customersToNotify.size() == maxAlerts) { break; } } } } 

Je dirais que c’est mauvais.

 while (!b) { // do something } 

lit beaucoup mieux que

 while (b != true) { // do something } 

Une des raisons pour laquelle le premier (b == faux) est mal vu est que souvent les débutants ne réalisent pas que la deuxième alternative (! B) est possible. Donc, utiliser la première forme peut indiquer une idée fausse avec des expressions booléennes et des variables booléennes. De cette façon, l’utilisation de la seconde forme est devenue une sorte de sjiboleth: quand quelqu’un écrit ceci, il comprend probablement ce qui se passe.

Je crois que cela a causé une différence plus importante qu’elle ne l’est réellement.