Dev Faq
10
votes

Meilleure pratique: si (foo == faux) ou si (! Foo)

Duplicaté possible:

Quel est le moyen préféré d'écrire des expressions booléennes dans Java

Aujourd'hui, ma collègue et mon collègue a ratissé un argument. Ce qui est un meilleur moyen d'utiliser les variables booléennes dans le code Java ainsi que si des déclarations. xxx

i soutien [1], car je pense que c'est plus lisible. Que pensez-vous les gars?.

6 commentaires

Dupliqué exact de Quel est le moyen préféré d'écrire Expressions booléennes à Java

Ok, maintenant je dois concéder à la vue de mon ami (et vous les gars). Merci à tous vos gars de la participation rapide. :)

Si vous soutenez 1, pourquoi les arrêter? REDUCTIO AD ABSURDUM exige que vous utilisiez si (((((((foo == faux) == true) == true) == vrai) ... .

D'accord!! J'abandonne!. Mes mains sont dans l'air!

Voir aussi Stackoverflow.com/questions/2661110/...

Il suffit de googler, je dis que cela dépend, si la variable est très longue car elle peut être le cas dans Java, l'option 1 est plus lisible: thisisalongclassname.isallowedtoDosomething == false est plus lisible que! Thisisalongclassname.Aubliotodosomething, cependant, si la distance entre les ! et la variable à tester est courte, option 1 mieux

7 Réponses :

0
votes

Je vais pour 2 parce que comme un programmeur voire 2 est lisible.

Imaginez que vous avez des centaines de vérification de ce type de validation, vérifiez-vous toujours avec FALSE.

non

0 commentaires
13
votes

numéro 2, ainsi que "FOO" ayant un nom descriptif, de sorte que le code lit bien:

si (! haspurple) ...

1 commentaires

Oui, mieux nommer les variables est définitivement la voie à suivre. Devient plus lisible.

0
votes

Si vous êtes le seul à entretenir votre code, vous êtes libre d'utiliser le style que vous aimez.

Cela dit! FOO est favorisée par la plupart des développeurs que je connais.

0 commentaires
0
votes

c'est une question d'opinion. Je préfère le numéro 2 parce que c'est moins de code à écrire et je pense que c'est tout aussi lisible.

0 commentaires
6
votes

Je trouve n ° 2 plus lisible. Je pense que chaque Java dev (je suis un c # dev) saurait quoi! moyens. Je

Bien que probablement pas le point ici, je préfère mettre mon "vrai" bloc comme la déclaration. Si la condition va généralement être false, je nomme ma variable pour représenter xxx

2 commentaires

Je ne suis pas d'accord. Les variables booléennes doivent être nommées de manière vérifiée dans la mesure du possible. Vous devriez être capable de toujours lire! Comme "non", et si vous avez besoin de foo, vous évitez le double négatif déroutant! Notfoo. La seule exception est que FOO a un antonyme (comme convexe vs concave).

Doubles négatifs convenus sont diaboliques :) Mais alors, si vous utilisez purement si-autre,! Notfoo serait juste nommé foo :)

5
votes

Je trouve une bonne idée d'éviter les choses comme xxx

parce que vous pouvez occasionnellement écrire xxx

comme une erreur typographique. Souvent, c'est une erreur facile à repérer, mais il semble simplement se prêter bien à faire cette erreur rapide.

3 commentaires

si (foo = true) {} n'est pas légal Java et ne compilera pas (et devrait se démarquer comme mauvaise syntaxe dans votre IDE). Avoir peur de si (var = constante) Les déclarations sont une mauvaise halte de C, où elle était légale (et parfois encouragée) d'attribuer dans le conditionnel. Arrêtez de vous inquiéter de cela et craignez plutôt de ce qui est plus lisible.

@Avi: Cela compile effectivement sous JDK6. Je vous ai donné le bénéfice du doute et je l'ai écrit moi-même. Il compile sans aucun avertissement sur les deux lignes de commande sur une boîte FreeBSD et sur Eclipse, et Eclipse ne montre aucun avertissement de son propre.

vous avez raison. Je m'excuse. J'ai été confus, car la plupart des expressions d'affectation sont illégales dans les conditionnels, à moins qu'ils ne soient de type booléen (car il n'existe pas de conversion automatique int-booléenne ou pointer-to-booléen en Java). J'irais toujours avec le plus lisible cependant. Dans le cas d'entiers, j'écrirais si (foo == constante) ; Dans le cas des booléens, je voudrais simplement écrire si (foo) qui est à la fois plus lisible et évite ce problème.

1
votes

Lorsque vous utilisez une variable booléenne comme une condition dans la déclaration, ne le comparez pas avec true.

pas une erreur, mais le style mauvais, car c'est déjà une valeur booléenne, alors utilisez-le simplement.

raisons pour lesquelles "! foo" est meilleur que "foo == faux". Référencé de

  • concision: supposant que vous êtes dans un contexte où un booléen est de
    nécessaire, et "x" est un booléen, il est Moins de caractères pour écrire "x" que "x
    == True ", ou"! x "que" x == false ".

  • Convention: programmeurs chevronnés en Java (ou C, C ++, C # et la plupart des autres
    Langues) Attendez-vous à voir «X» plutôt
    que "x == vrai", et "! x" plutôt
    que "x == faux".

  • robustesse: en Java Les déclarations conditionnelles et boucles nécessitent toutes un
    expression valorisée booléenne dans le
    état. Si "y" n'est pas un booléen,
    puis une faute de frappe de la forme "si (y = foo) {"donnera une erreur de compilation de
    Java. Mais si "y" est un booléen, puis
    "Si (y = foo) {" ne donne pas de
    erreur de compilation. Par conséquent, en évitant "==" pour les booléens, vous évitez de définir de
    vous-même pour tout un radeau de bugs
    résultant de la typose.

3 commentaires

-1 pour Integral Copier Copy Coly of La réponse de Stephen . Premièrement, même s'il y a un lien, vous faites ressembler le contenu comme il est le vôtre ou reformé, alors que ce n'est pas le cas. Formatez-le comme indiqué, il n'y a pas d'ambiguïté. Deuxièmement, si la réponse collée est appropriée, la question est très probablement une duplication et devrait être fermée comme telle. À la fin, c'est juste une mauvaise pratique.

@Pascal thivent pour ma réponse J'ai ajouté ma vue (2 lignes top 2 en gras) ainsi que la section ajoutée référencée de Stephen.i a également ajouté le lien où il a été référencé. Je n'avais pas l'intention de montrer que la section référencée était mon point de vue. Je suis désolé si cela se sentait alors. J'ai supprimé l'ambiguïté et j'ai clairement cité clairement.

Merci d'avoir supprimé l'ambiguïté. Je pense vraiment qu'il est important de maximiser la transparence et je vais supprimer mon bowvote.

Articles qui pourrait vous intéresser :

Comment envoyer une liste vide à la clause IN
Code de réponse 403 inattendu lors de la récupération des données des API
Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player
Comment définir un tableau dans jsonobject