J'étais codé ici l'autre jour, écrivant quelques déclarations si avec des entiers qui sont toujours Lorsque vous testez un résultat positif, ce qui est meilleur; Test de Par exemple, donné un int Y a-t-il une différence entre tout en ce qui concerne la vitesse, la puissance de traitement, etc.
Veuillez ignorer le fait que l'INT peut être plus / moins que 0 ou 1 (pratiquement agissant comme bool s). Je me suis demandé:
int == 1 ou int! = 0 ?
N , si je veux tester si c'est true , dois-je utiliser n == 1 ou < code> n! = 0 ?
1 / 0 , il n'est pas pertinent et ne se produit pas. < / p>
17 Réponses :
Le cerveau de l'homme de meilleures déclarations de processus qui ne contiennent pas de négation, ce qui rend "INT == 1" de meilleure manière.
Vous ne pouviez pas dire que les humains ne préfèrent pas n'utiliser pas peu de négations. Attends, ou était-ce le contraire? :-)
N'avez-vous pas décidé de penser binaire, encore?
@Emil, il est également important que votre code communique avec d'autres humains (autres programmeurs et même vous-même, mois ou années plus tard).
-1 pour ne contient pas de négation , mon cerveau ne peut pas traiter que (je ne vous ai pas réellement donné A -1 :)
Dans mon opinion honnête, s'habituer à la lecture si (! Expr) comme s'il ne s'agissait pas d'expression; est probablement la chose la plus difficile que vous devez apprendre lorsque vous prenez une langue comme C. Surtout si vous avez une police de merde.
@Emil: Qui se soucie de la compréhension de l'ordinateur? Si vous cueillez entre deux manières identiques d'écrire quelque chose, vous choisissez l'un des humains fera mieux.
La négation de tuple est considérée comme inappropriée en anglais pour une raison :)
Cela dépend vraiment. Si vous utilisez une langue prenant en charge les booléens, vous devez utiliser le booléen, pas un entier, c'est-à-dire: ou Cela étant dit, avec de vrais types booléens, il est parfaitement valide (et généralement plus agréable) à écrire: ou qui étant dit, si vous utilisez une langue qui ne supporte pas les booléens directement, la meilleure option Ici dépend vraiment de la façon dont vous définissez vrai et faux. Souvent, Si vous êtes garanti que 0 et 1 sont les seules deux valeurs, j'utiliserais probablement false est 0, et true est autre chose que 0. Dans cette situation, en utilisant si (i == 0) (pour false Vérifiez) et si (i! = 0) pour une vérification réelle. Si (i == 1) puisque une négation est plus complexe et plus susceptible de conduire à des bugs de maintenance.
Objective-C soutient les booléens, non? J'ai des problèmes avec des booléens Nslogging, c'est pourquoi j'utilise un int. (non pertinent de questionner)
@Emil: Objective-C, comme c, ne contient pas de type "réel" booléen, mais a une macro la définissant (à oui et au lieu de vrai / faux). Pour plus de détails, voir: iPhonedevelopERTes.com/Objective-c/of-bool -et-yes-oui.html
Quel que soit le point de si (faux) ? Cela n'exécutera jamais ses déclarations. Et si (vrai) exécutera toujours ses déclarations.
J'ajouterais simplement à l'excellent conseil de Reed Copsey, soit cohérent sur le codeBase (écrivez-le dans un fichier de piratage de piratage ou de la SPH pour le prochain SAP ^ H ^ H ^ HCoder).
@Joren: ça a l'air mieux? Je suggérais juste d'utiliser False ou Vrai au lieu de 0/1 ...
Je n'aime pas les tests avec des vars booléens par rapport aux constantes comme vous l'avez fait. Je préfère nommer mes variables booléennes avec 'est', comme Isfileopen. Mon test serait "si (isfileopen)", pas le lourd "si (isfileopen == true)".
@AAAA BBBB: Je le fais souvent, mais dans ce cas, l'objectif était de suggérer d'utiliser des booléens au lieu d'utiliser des entiers. La même chose peut être faite avec des valeurs int (en C et l'objectif-c, pas c #, cependant), mais il est plus clair lorsque vous êtes explicite avec des booléens.
== false de == true ou == true == true == true est un non-sens. Il suffit d'écrire si (! Valeur) { / si (valeur) { (ajustez la syntaxe et le formatage au contexte).
@Reed Copsey Objective-C comme C (99) qu'il s'agit d'un superset de fait contient un vrai type booléen.
-1 Si vous utilisez une langue prenant en charge les booléens, vous devez écrire si (valeur) ... ou si (! Valeur) ... .
@JeremyP: Objective-C ne fait pas, dans sa mise en œuvre standard. Certains vendeurs en ont ajouté un, mais c'est généralement une définition dans NsObject.h. Pour plus de détails, voir: otierney.net/Objective-c.html
@starBlue: Comme je l'ai déjà mentionné, je le fais généralement, mais je voulais illustrer le test de la valeur contre un booléen et non un entier. Je vais essayer de retravailler ma réponse pour rendre cela encore plus clair.
@Reed Copsey. L'objectif-c est un Superset strict strict de C99 . C99 a un type booléen. Par conséquent, l'objectif-c a un type booléen.
@JeremyP: très faux. Si vous ne me croyez pas, voici la référence officielle d'Apple, montrant que Bool est un typlef pour (Signé) Char et oui / non sont Typefs: développeur.apple.com/mac/library/documentation/cocoa/referenc E / ...
@JeremyP: Objective-C est un superset strict de C89 - il a été développé en 1996 et l'angle C-99, ratifié en 2000 (bien qu'il partage la plupart des fonctionnalités de C99 maintenant).
@Reed Copsey: Objective-C comme compilé par la boîte à outils actuelle est un superset strict de C99. C99 a un type de données booléen appelé _bool donc objectif-c a un type de données booléen appelé _bool. Le type Bool existe également mais est un type de Typef'd séparé qui fait partie de l'heure d'exécution de l'objectif-C (afin que vous puissiez l'affirer aussi fait partie de la langue).
@Reed Copsey: Au fait, il s'agit de la référence en profondeur pour Bool développeur.apple.com/mac/library/documentation/cocoa/referenc E / ...
@JeremyP: Mon problème en disant que ce n'est pas un type "réel", c'est que, dans l'objectif-c, vous pouvez attribuer 2 à une valeur BOOL sans erreur , ce qui signifie que BOOL n'est plus oui ou non . Voir la section "Considérations spéciales" de là ....
@Reed: Je ne conteste pas que Bool n'est pas un vrai type booléen, je conteste votre affirmation que l'objectif-c n'a pas de type booléen. Cela fait. Il a le type C99 _bool.
(Et _bool devient bool avec
@Reed: lol. Si j'ai trouvé quelqu'un codant le texte si (var == faux) , cette personne serait marquée avec attribut "Ne payez jamais pour leur travail".
Si seulement deux valeurs sont possibles, j'utiliserais le premier: car il est plus explicite. S'il n'y avait aucune contrainte sur les valeurs, je penserais autrement.
(supposer que votre intégration ne peut être que 1 ou 0) les deux déclarations sont logiquement équivalentes. Je recommanderais d'utiliser la syntaxe == car je pense qu'il est plus clair de la plupart des gens lorsque vous n'introduisez pas des négations inutiles.
Lorsque vous utilisez des entiers comme booléens, je préfère les interpréter comme suit: False = 0, True = non nulle.
J'écrirais les déclarations de condition comme
une question de Daft vraiment. Si vous testez 1, testez-le pour 1, si vous testez zéro, testez zéro.
L'ajout d'une déclaration Ce choix entre sinon peut faire le choix peut sembler arbitraire. Je choisirais ce qui constitue le plus de sens, ou a une signification plus contextuelle, un comportement par défaut ou un «naturel» suggéré par la fréquence attendue de l'occurrence par exemple.
int == 0 et int! = 1 peut très bien bou ébulluer sur des évaluations subjectives qui ne valent probablement pas la peine de s'inquiéter.
Ne pas aller à -1, car les deux premiers points sont assez valables, mais l'appelant une question de Daft est un peu beaucoup. De plus, la clarté / la lisibilité du code peut être très subjective, mais je ne l'appellerais pas "ne mérite pas la peine de s'inquiéter."
Le dernier paragraphe devrait être lu comme une sous-clause du deuxième paragraphe, que parfois tous les avantages de la lisibilité peuvent devenir si insignifiants que cela devient une perte de temps qui s'inquiète de si vous devriez tester pour (int == 1) ou < / Code> (int! = 0) `, la phrase" Le diable est dans les détails "vient à l'esprit.
Si vous travaillez avec des valeurs qui ne peuvent être que 1 ou 0, alors je vous suggère d'utiliser des valeurs booléennes pour commencer, puis faites simplement si (bool) ou si (! bool) .
Dans la langue où INT qui ne représentent pas 0 représente la valeur booléenne "vraie", et 0 "false", comme c, j'aurai tendance à utiliser si (int! = 0) car il représente la même signification que si (int) alors que int == 1 représente plus la valeur entière étant égale à 1 plutôt que le Vrai Booléen. Ce n'est peut-être que moi cependant. Dans les langues prenant en charge le type booléen, utilisez-le toujours plutôt que dans l'INTS.
Pour être honnête si la valeur de INT est juste 1 ou 0, vous pourriez même dire: et ce serait le même que de dire p> Mais vous voudriez probablement utiliser P> if (int == 1)
Je dirais que cela dépend de la sémantique, si vous conditionez signifie
tandis que (! avortez) la négation est OK.
si (quitte) casse; serait également OK.
IF INT IS 1 NEXT SENTENCE ELSE MOVE "INT IS NOT ONE" TO MESSAGE.
deux points:
1) Comme indiqué ci-dessus, une victoire plus explicite est une victoire. Si vous ajoutez quelque chose à une liste vide, vous voulez non seulement que sa taille ne soit pas nulle, mais vous voulez aussi que cela soit explicitement 1.
2) Vous voudrez peut-être faire (1 == int) De cette façon si vous oubliez un = vous finirez par une erreur de compilation plutôt qu'une session de débogage.
Personne d'autre l'a dit, alors je vais donner mon vote ici. +1 Do (cons / finale == var) de cette façon si vous oubliez un = vous finirez par une erreur de compilation plutôt qu'une session de débogage.
if( is_numeric( $int ) ) { its a number }
elseif( !$int ) { $int is not set or false }
else { its set but its not a number }
end of discussion :P
Ouais, comment ça me complique encore plus? Haha. :)
Hey, ne blâmez pas le messager: p
Je suis d'accord avec ce que la plupart des gens ont dit dans ce post. Il est beaucoup plus efficace d'utiliser des valeurs booléennes si vous avez une des deux possibilités distinctes. Il rend également le code beaucoup plus facile à lire et à interpréter.
si (bool) {...}
J'étais du monde C. Au début, je ne comprends pas beaucoup sur l'objectif-c. Après quelque chose, je préfère quelque chose comme: ou in c, c'est-à-dire: Ces jours-ci, j'utilise est beaucoup mieux que: ou varchar au lieu de integer en tant que touches de table, par exemple
Mais alors vous rencontrez dans la question que l'INT est traité beaucoup mieux dans les bases de données, puis les Varchars. Il vaut mieux utiliser dire un tinyint (1) avec différentes valeurs.
"Ces jours-ci, j'utilise Varcharne au lieu d'entier comme des clés de table aussi" Certains appelleront-il une bravoure
Comme d'autres personnes ont dit, en utilisant Cela dit, la plupart des processeurs ont une opération spécifique à zéro. Cela dépend du compilateur spécifique, du processeur, et de cetera, mais il peut y avoir une avantage de vitesse presque incommensurable à utiliser La plupart des langues vous permettront d'utiliser == est souvent plus facile à lire que d'utiliser ! = . .
! = 0 sur == 1 en conséquence. < / p>
si (int) et si (! int) , ce qui est à la fois plus lisible et que vous obtenez un bonus de vitesse minuscule. < / p>
Je suis paranoïaque. Si une valeur est soit 0 code> ou 1 code>, il peut s'agir de 2 code>. Peut-être pas aujourd'hui, ce n'est peut-être pas demain, mais un programmeur de maintenance va faire quelque chose de bizarre dans une sous-classe. Parfois, je fais moi-même des erreurs [SHH, ne dites pas à mon employeur] em>. Donc, faites-le dire que le code me dit que la valeur est soit 0 code> ou 1 code>, sinon elle pleure à maman. if (i == 0) {
... 0 stuff ...
} else if (i == 1) {
... 1 stuff ...
} else {
throw new Error();
}
Lisez la question! "S'il vous plaît, ne répondez pas avec des trucs concernant le Int peut être plus / moins de 1/0, ce n'est pas ce que je veux savoir."
@Emil c'est ce que vous devez savoir.
Pourquoi toutes ces tags, vous demandez? Eh bien, je considère cela une question multi-langues. Vous pouvez publier une réponse valable dans une seule de ces langues et je serai heureux;)
@Emil: Dans ce cas, vous voudrez peut-être envisager de l'alterner la langue-agnostique.
Qu'est-ce que INT? Afaik c'est un mot clé réservé. Si la variable est quelque chose comme Bool A = TRUE | false, vous devez utiliser si (a == vrai) par exemple
Vous dites: Devrais-je demander si quelque chose est
true ounon faux ? Que préférez-vous lire?@Bo int est entier. Nombre. Pas bool :)
C'est presque, mais pas tout à fait différent de la même chose
ou même
rosetta-pierre si vous voulez obtenir des réponses dans autant de langues que possibleEt pourquoi n'est-ce pas une vraie question?
Quel type est un complément de nombreux
book ?Encore un autre faux étroite (vote à rouvrir)