Faire une grosse affaire de == vrai?

105

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?

JoelFan
la source
12
Je préfère les explicites if (some_flag == true)mais les implicites if (is_something)ou if (has_something). Notez les noms de variables.
fredoverflow
69
Rappelez à votre collègue que le type de someBool == trueest également booléen, donc selon la même logique if ((someBool == true) == true).
Mike Seymour
2
@GSto: Je suppose que vous le savez, mais en PHP, vous pouvez le faire pour "jeter" n'importe quoi et peut être réellement utile.
zneak
2
@ zneak Ou vous pourriez être plus clair et utiliser $var = (bool) some_expression. Et dans la plupart des cas, cela n'aura même pas d'importance, car PHP effectuera les conversions nécessaires de manière dynamique.
waiwai933
4
vérifiez toujours la constante en premier, si (vrai == une certaine chose), au cas où vous auriez dactylographié par erreur = au lieu de == [oui, je plaisante!]
Steven A. Lowe,

Réponses:

126

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.

Robert Harvey
la source
Cela me semble le plus fidèle. Tout est une question de clarté et d'art du nommage, la syntaxe d'origine n'est pas si mauvaise, mais c'est le bon chemin pour obtenir un meilleur code.
TJB
2
Battez-moi à elle! Sans une désignation appropriée, l'équivalence plus succincte n'a aucun sens.
Chasse à la Troie
4
J'ai dû utiliser someBool == trueplusieurs fois le code hérité pour plus de clarté. Mais si j'écris à partir de zéro , je nomme la variable en conséquence et utiliserif (isSomething)
nimcap
Je suis d'accord, même si nommer résoudrait ce problème, en supposant que le nom était SomeBool, cela pourrait vouloir dire n'importe quoi et être de n'importe quel type (un entier égal à la quantité de booléens dans un tableau peut-être?). Les booléens ont besoin d'un verbe existentiel, sinon ils seront toujours difficiles à lire par eux-mêmes.
Morgan Herlocker
Je suis d'accord, tout est une question de lisibilité. Si les variables sont bien nommées, vous n'en avez pas besoin. Si l'expression se lit mieux avec elle, je choisirais "== true", elle est également cohérente si vous utilisez "== false" au lieu de (le laid) "if (! ())".
Ronny Brendel
71

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.

Tim Goodman
la source
Je ne mettrais pas si vite cela en ordre. J'ai entendu des choses vraiment étonnantes sortir de la bouche des programmeurs professionnels. Peu de temps après, l’un des grokkers suivait habituellement: "Comment cela a- t-il fonctionné?"
dash-tom-bang
12
Entièrement d'accord sur l'évaluation. À l'occasion, je me suis demandé: "Où ça s'arrête?" if ((((x == vrai) == vrai) == vrai)! = faux) // et ainsi de suite ...
signe de lacet
1
Parfois, j'écrivais if (c == true) return true; else return false;, mais 99% du temps (le 1% est là car je ne peux jamais être sûr de n'en manquer aucun), je le remarque immédiatement et le remplace par le tout return c. Je m'attends à ce que les programmeurs les plus compétents fassent quelque chose de similaire s'ils développent cette habitude tôt dans leur carrière. Ce à quoi je ne m'attendrais pas, c'est une réponse wtf.
Lie Ryan
1
Oh mon dieu, l'art de penser. J'ai littéralement trouvé cela dans notre base de code la semaine dernière. if (!someCondition) { someCondition = false; }J'ai vu quelques licenciements (nombreux) ainsi que des impossibilités dans notre code, mais celui-ci était si simple et pourtant si pénible de penser que quelqu'un l'a écrit. Plusieurs fois, même.
Anthony Pegram
1
Notez juste que j'ai vu quelques cas if(x) x=true;qui n'étaient PAS redondants, mais plutôt l'équivalent de x=!!x;(normalisant x à 0/1)
jkerian
58

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) {}
JohnFx
la source
6
Oui, d'accord. C'est idiot, mais vous devez choisir vos combats, et ce code fait en effet ce que votre collègue dit. Mentionnez-le dans un non "Qu'est-ce que l'enfer est FAUX avec vous?!" genre de façon, alors laissez tomber. Bien que s'ils commencent à tirer de la merde comme "if (someBool! = True)" ou "if (! SomeBool == true)" ou d'autres convolutions similaires, cela pourrait être un combat qui mérite d'être
ramassé
3
Comment (someBool == false) est-il pire que si (someBool == true)?
FinnNk
5
true=truene compile pas, vous ne pouvez pas assigner à true;-)
fredoverflow
1
Je me suis habitué à if(somebool == false)ou !=, mais toujours contre faux et pas vrai. Je le trouve redondant, mais puisque la norme de codage insiste sur le fait que cela if()ressemble à un appel de fonction, les espaces entre les parens m'aident à le lire. Seul, un bool est un bool, mais if (somePointer)ne vole pas; Je préfère if (somePointer != NULL)car un pointeur n'est pas un bool.
dash-tom-bang
5
Il s'agit de lisibilité, pas d'illogique ou de (micro) redondance
Ronny Brendel
45

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.

GrandmasterB
la source
5
Bien placé, il est bon de rechercher la perfection, mais il y a sûrement de plus gros poissons à frire
TJB
3
Je pense que vous dites ceci à propos de chaque problème qui mérite une discussion.
Dave Van den Eynde
2
C'est potentiellement révélateur de problèmes beaucoup plus vastes. Une petite tache brune au plafond de votre garage peut ne pas sembler être un gros problème, mais cela peut signifier que vous avez une fuite d'eau importante.
Josh
42

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.

Guffa
la source
6
Ce n'est pas un argument pertinent. Si vous travaillez dans une langue comme celle-là, vous pouvez simplement déplacer le vrai de l'autre côté. La question est de savoir s'il faut ou non inclure le vrai.
Cam
8
@ Cam: Vous manquez le point, vous. La logique en arrière, je ne suggère pas.
Guffa
15
@Cam - Il donne un exemple concret de ce qui peut poser problème. Je dirais que cela est tout à fait pertinent.
ChaosPandion
1
@Guffa Cam a très raison. Ce n'est pas une raison pour arrêter d'utiliser == (anyType) dans if blocks.
Ronny Brendel
2
@Ronny: Non, cela ne peut arriver avec aucun type (à moins que le langage n'autorise en réalité aucun type). L'instruction if (answer = 42) {}ne se compile tout simplement pas car l'expression n'est pas un bool.
Guffa
21

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
    //...
}
Came
la source
13
lisibilité == GoodThing
Muad'Dib
5
if ((lisibilité == GoodThing) == vrai) ...
JoelFan
1
bool isGoodThing = lisibilité? true: (codingStandards? true: (internalizationOfConcept? true: false));
johnc
17
Alors renommez la variable actionsAreAllowed.
Graeme Perrow
9
En écrivant, if (x) { ...vous affirmez déjà qu'il xs'agit d'un booléen ou qu'il est convertible en booléen. Ce que vous appelez est sans importance.
Daniel Earwicker
15

Qu'en est-il des bools nullable?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 
Steve Wellens
la source
if (MyFlag.Value)
johnc
1
Toutes les langues n’ont pas de valeur nullable, et beaucoup d’entre elles accepteront votre deuxième construction.
Samedi
1
@johnc: "if (MyFlag.Value)" ne fait peut-être pas ce que vous voulez, il peut générer une exception si MyFlag est null (que vous pouvez tester en cochant MyFlag.HasValue).
Ludovic Chabant
4
C \ 'est ma bête noire avec des choses nullables :)
Jarrod Dixon
3
bool? isValid = null; si (isValid ?? false);
Skolima
11

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.

Casey
la source
1
En fonction de votre langue, someValue pourrait ne pas être nécessairement l'équivalent de true, même s'il est évalué à true. Par exemple, (9 == True)évalue false en Python et j'imagine similaire en C ++.
dash-tom-bang
Les régions de code et les soulignés principaux me donnent envie de frapper les gens en face.
MGOwen
11

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.

Scott Fletcher
la source
7
Ce n'est pas une mauvaise chose. Le code qui se lit comme un texte réel est bien meilleur que l'implicite foo. Conservez cette habitude pour des raisons de lisibilité.
Ronny Brendel
11

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
Marcelo de Aguiar
la source
C'est drôle, je devais maintenir un système qui couvrait tout le contenu. Cela m'a rendu fou.
Tjaart
8

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.

utilisateur1249
la source
3
C ++ a en fait l' notopérateur, tout comme C (une fois que vous avez inclus l'en-tête standard <iso646.h>). Si vous ne voulez pas (ou ne peut pas) utiliser cet en- tête (ou si vous êtes coincé avec Java ou C #), je suggère de mettre un espace après le point d'exclamation: if (! condition). Cela le rend un peu plus visible.
Konrad Rudolph
1
Je fais du Java. notn'est pas une option.
6

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.

AShelly
la source
En fait, dans les langues où l'opérateur d'affectation renvoie une valeur ... comme C ++ ... if (b == true) {n'est pas simplement redondant. C'est aussi un peu risqué, car vous pourriez être assigné accidentellement trueà b.
Stephen C
4
Ce n'est pas seulement redondant en C ++, c'est dangereux. Si vous écrivez if (b == true)et que ce bn'est pas un bool, les conversions de types vont dans le mauvais sens. A boolest un type intégral qui est normalement promu à un type intégral approprié avec la valeur 1. Si vous écrivez, par exemple, int b(2); if (b == true)puis truedevient intavec la valeur 1 à des fins de la comparaison, plutôt que d' bêtre forcé dans le type bool, ce qui donnerait le bon résultat.
David Thornley
@ DavidThornley, activez les avertissements dans votre compilateur. Traiter les avertissements comme des erreurs est une meilleure technique de programmation défensive que d’éviter ==.
Abyx
5

Vous pensez que c'est mauvais? Que diriez-vous:

if(someCondition) {
  return true;
} else {
  return false;
}
Sverre Rabbelier
la source
2
Boy combien de fois j'ai vu cela. Cela constitue un bon exemple pour un outil comme ReSharper.
Job
Oui, si vous louez des mottes, achetez ReSharper.
Kirk Broadhurst
4

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!

grokus
la source
4
Pour l'amour de tout ce qui est saint, tant que ce n'est pas if (!bNotVal) ou if (bNotVal)même en premier lieu. Ugh négatifs dans les noms rend tout plus difficile à lire.
dash-tom-bang
2
Je connaissais un développeur qui serait bool isNotConnected; if (isNotConnected == true) ...
beurk
4

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.

Afficher un nom
la source
3

Que diriez-vous

if (x == "true")

POURQUOI EST-CE UNE CHAÎNE?!

atfergs
la source
Je travaille sur un code php existant et je trouve parfois quelque chose comme if(preg_match('/title/', implode($_POST))){. PHP, assez dit, je dois trouver un meilleur travail.
Keyo
4
oui, je vois aussi si (x == "1"), mais c'est généralement le cas pour une mauvaise conception de la base de données.
Atfergs
J'ai utilisé des constructions similaires lorsque je xvenais d'une entrée utilisateur (fichier de configuration ou service Web, par exemple). Cependant, j'autorise généralement d'autres valeurs vraies, donc ça finit par ressemblerif x.lower().strip() in ["true", "yes", "on", "1"]
eswald
3

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

Matt Sherman
la source
3

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é.

Ronny Brendel
la source
3
Vous dites "si bla" ne se lit pas comme une phrase ... cela signifie que votre variable n'est pas nommée correctement ... qu'est-ce qui ne va pas avec ceci: if (userHasRights) doQuelque chose ()
JoelFan 19/10
"dans de nombreux cas". Oui, tu as raison. Renommer, c'est bien aussi. Avec "if (QWidget :: acceptDrops () == true)", vous n'avez pas la possibilité de renommer. peut-être qu’il serait bon de l’appeler notAcceptDrops () ... C’est trop compliqué (et il est impossible d’être cohérent en utilisant cette règle d’omission dans une API), donc cohérent avec les autres "== quels que soient" -ifs, Je suggère fortement de ne pas l'omettre, pour qu'il ne soit pas "différent", donc homogène.
Ronny Brendel
3

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 :)

cdkMoose
la source
2

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.

FinnNk
la source
3
De plus, si cela est dans les normes de codage de l'équipe, vous devez vraiment réévaluer les normes pour vous débarrasser de telles anecdotes.
JohnFx
D'accord! Juste au cas où ...
FinnNk
2

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.

statichippo
la source
bool b;s'initialise uniquement à false lorsqu'il bs'agit d'un champ. Vous devez initialiser explicitement les variables locales.
Matthew Flaschen
+1 accepté. C'est le même problème avec d'autres langages (de script). Vous devez être explicite si vous souhaitez tester booléen trueou simplement "true". Par exemple, toute chaîne non vide est considérée, == truemais pas === truedans certaines langues.
Martin Wickman
2

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)
{...}
Jared G
la source
2

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.

Emploi
la source
Le premier problème découle d'une fausse prémisse IMO utilisant des noms de variables épouvantables. Supposons que x, y, z ont été nommés notExceptButHasX, exceptNotButIsntY, doNotUnlessIsExceptZ? Comment cela rend-il la lisibilité de votre problème? Si x, y, z ont été nommés quelque chose comme "isEnabled", "isEffective", "hasProperty", votre déclaration devient alors isEnabled || isEffective || hasPropertybeaucoup plus lisible que de comparer avec trueou false.
Thomas
1

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.

Huperniketes
la source
1
Avoir une certaine capacité à être autre que VRAI / FAUX est une mauvaise pratique de codage.
AttaquerHobo
@AttackingHobo, c'est l'un des pièges de ne pas avoir de types booléens dans une langue et / ou de ne pas utiliser une classe pour fournir le comportement exact souhaité.
Huperniketes
1

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.

bburbank
la source
1

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.

Tomas Narros
la source
1

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!

ingh.am
la source
0

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).

Driis
la source
0

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.

étonnant
la source
0

que diriez-vous:

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

Oui, je l'ai vu.

Dave
la source