booléen dans une déclaration if
Aujourd'hui, j'ai une remarque sur le code en considérant la manière dont je vérifie si une variable est vraie ou fausse dans un devoir d'école.
Le code que j'avais écrit ressemblait à ceci:
var booleanValue = true;
function someFunction(){
if(booleanValue === true){
return "something";
}
}
Ils ont dit que c'était mieux/plus ordonné de l'écrire comme ceci:
var booleanValue = true;
function someFunction(){
if(booleanValue){
return "something";
}
}
La remarque que j’ai eu à propos de la partie "=== vraie" était que cela n’était pas nécessaire et pouvait créer de la confusion.
Cependant, mon idée est qu'il est préférable de vérifier si la variable est un booléen ou non, surtout que le langage Javascript est un langage à la touche.
Dans le deuxième exemple, une chaîne renverrait également "quelque chose";
Donc ma question; Est-il plus judicieux de perdre la partie "=== true" dans le futur, ou est-ce une bonne pratique de vérifier également le type de la variable.
Edit: Dans mon "vrai" code, le booléen indique si une image a été supprimée ou non, aussi les seules valeurs que boolValue devrait avoir sont true ou false.
0 et 1 par exemple ne devraient pas être dans cette variable.
Tout d'abord, les faits:
if (booleanValue)
Satisfait l'instruction if pour toute valeur de vérité de booleanValue, y compris true, tout nombre différent de zéro, toute valeur de chaîne non vide, toute référence d'objet ou de tableau, etc.
D'autre part:
if (booleanValue === true)
Cela ne satisfera la condition if que si booleanValue est exactement égal à true. Aucune autre valeur de vérité ne le satisfera.
Par contre si vous faites ceci:
if (someVar == true)
Ensuite, ce que Javascript fera est de taper coerce true pour qu’il corresponde au type de someVar, puis de comparer les deux variables. Il y a beaucoup de situations où ce n'est probablement pas ce que l'on voudrait. Pour cette raison, dans la plupart des cas, vous souhaitez éviter == car il existe un ensemble assez long de règles sur la manière dont Javascript doit taper deux choses du même type et que si vous ne comprenez pas toutes ces règles et si vous pouvez anticiper tout ce que le L'interpréteur JS peut faire cela quand on donne deux types différents (ce que la plupart des développeurs JS ne peuvent pas), vous voudrez probablement éviter complètement ==.
Comme exemple de comment cela peut être déroutant:
var x;
x = 0;
console.log(x == true); // false, as expected
console.log(x == false); // true as expected
x = 1;
console.log(x == true); // true, as expected
console.log(x == false); // false as expected
x = 2;
console.log(x == true); // false, ??
console.log(x == false); // false Pour la valeur 2, on pourrait penser que 2 est une valeur de vérité, si bien que la comparaison serait avantageuse avec true, mais ce n'est pas ainsi que la coercition de type fonctionne. Il convertit la valeur de la main droite pour correspondre au type de la valeur de la main gauche. Ainsi, il convertit true en nombre 1 afin de comparer 2 == 1, ce qui n’est certainement pas ce que vous vouliez.
Alors, méfiez-vous de l'acheteur. Il est probablement préférable d'éviter == dans presque tous les cas, à moins de connaître explicitement les types que vous allez comparer et de connaître le fonctionnement de tous les types possibles d'algorithmes de coercition.
Donc, cela dépend vraiment des valeurs attendues pour booleanValue et de la manière dont vous voulez que le code fonctionne. Si vous savez à l’avance que seule une valeur true ou false sera jamais utilisée, comparez-la explicitement avec
if (booleanValue === true)
est juste du code supplémentaire et inutile et
if (booleanValue)
est plus compact et sans doute plus propre/meilleur.
Si, par contre, vous ne savez pas ce que booleanValue pourrait être et si vous voulez vérifier s'il est réellement défini sur true sans autre conversion de type automatique, alors
if (booleanValue === true)
ce n’est pas seulement une bonne idée, mais une nécessité.
Par exemple, si vous examinez la mise en œuvre de .on() dans jQuery, celle-ci a une valeur de retour facultative. Si le rappel retourne false, jQuery arrêtera automatiquement la propagation de l'événement. Dans ce cas précis, étant donné que jQuery souhaite arrêter UNIQUEMENT la propagation si false a été renvoyé, ils vérifient l’explicité de la valeur renvoyée pour === false car ils ne veulent pas undefined ou 0. ou "" ou tout autre élément qui sera automatiquement converti en false pour satisfaire également la comparaison.
Par exemple, voici le code de rappel de traitement d'événement jQuery:
ret = ( specialHandle || handleObj.handler ).apply( matched.elem, args );
if ( ret !== undefined ) {
event.result = ret;
if ( ret === false ) {
event.preventDefault();
event.stopPropagation();
}
}
Vous pouvez voir que jQuery recherche explicitement ret === false.
Mais, il y a aussi beaucoup d'autres endroits dans le code jQuery où une vérification plus simple est appropriée étant donné le désir du code. Par exemple:
// The DOM ready check for Internet Explorer
function doScrollCheck() {
if ( jQuery.isReady ) {
return;
}
...
Si vous écrivez: if(x === true), ce ne sera vrai que pour x = true
Si vous écrivez: if(x), ce sera vrai pour tout x qui n'est pas: '' (chaîne vide), false, null, non défini, 0, NaN.
En clair "si" la variable sera forcée à un booléen et utilisera toBoolean sur l'objet: -
Argument Type Result
Undefined false
Null false
Boolean The result equals the input argument (no conversion).
Number The result is false if the argument is +0, −0, or NaN;
otherwise the result is true.
String The result is false if the argument is the empty
String (its length is zero); otherwise the result is true.
Object true.
Mais la comparaison avec === n’a aucun type de contrainte, de sorte qu’ils doivent être égaux sans contrainte.
Si vous dites que l'objet n'est peut-être même pas un booléen, vous devrez peut-être considérer plus que simplement vrai/faux.
if(x===true){
...
} else if(x===false){
....
} else {
....
}
Cela dépend de votre cas d'utilisation. Vérifiez également le type, mais s'il ne s'agit que d'un indicateur, ce n'est pas le cas.
En général, il est plus simple et plus simple d’omettre le === true.
Cependant, en Javascript, ces déclarations sont différentes.
if (booleanValue) sera exécuté si booleanValue est vérité - autre chose que 0, false, '', NaN, null et undefined.
if (booleanValue === true) ne sera exécuté que si booleanValue est précisément égal à true.
Puisque vous avez déjà initialisé clairement en tant que bool, je pense que l’opérateur === n’est pas requis.
Étant donné que la valeur vérifiée est une valeur booléenne, il a été préférable de l’utiliser directement pour moins de codage, et il en a fait de même == true
L'opérateur d'identité (===) se comporte de manière identique à l'opérateur d'égalité (==), sauf qu'aucune conversion de type n'est effectuée et que les types doivent être identiques pour être considérés comme égaux.
if (booleanValue) est essentiellement if (booleanValue == true).
Je pense que votre raisonnement est sain. Mais dans la pratique, j’ai constaté qu’il est bien plus courant d’omettre la comparaison ===. Je pense qu'il y a trois raisons à cela:
- En général, cela n’ajoute rien à la signification de l’expression - c’est le cas dans tous les cas où la valeur est connue pour être booléenne.
- Du fait qu’il existe beaucoup d’incertitude de type en JavaScript, le fait de procéder à une vérification de type a tendance à vous mordre lorsque vous obtenez une valeur inattendue
undefinedounull. Souvent, vous voulez simplement que votre test échoue dans de tels cas. (Bien que j'essaie d'équilibrer cette vue avec la devise "fail fast"). - Les programmeurs JavaScript aiment jouer rapidement avec les types - en particulier dans les expressions booléennes - parce que nous le pouvons.
Considérons cet exemple:
var someString = getInput();
var normalized = someString && trim(someString);
// trim() removes leading and trailing whitespace
if (normalized) {
submitInput(normalized);
}
Je pense que ce genre de code n'est pas rare. Il gère les cas où getInput() renvoie undefined, null ou une chaîne vide. En raison des deux évaluations booléennes, submitInput() n'est appelé que si l'entrée indiquée est une chaîne contenant des caractères autres que des espaces.
En JavaScript, && renvoie son premier argument s'il est faux, ou son deuxième argument si le premier argument est true; donc normalized sera undefined si someString n'était pas défini, etc. Cela signifie qu'aucune des entrées des expressions booléennes ci-dessus n'est en réalité une valeur booléenne.
Je sais que beaucoup de programmeurs qui sont habitués à une forte vérification de type rechignent à voir du code comme celui-ci. Toutefois, l'application d'un typage fort nécessiterait probablement des vérifications explicites des valeurs null ou undefined, ce qui encombrerait le code. En JavaScript, ce n'est pas nécessaire.
En Javascript, l’idée de booléen est assez ambiguë. Considère ceci:
var bool = 0
if(bool){..} //evaluates to false
if(//uninitialized var) //evaluates to false
Ainsi, lorsque vous utilisez une instruction if (ou toute autre instruction de contrôle), il n'est pas nécessaire d'utiliser un type "boolean". Par conséquent, à mon avis, la partie "=== true" de votre déclaration est inutile si vous savez que c'est un booléen, mais absolument nécessaire si votre valeur est une "vérité" ambiguë. Plus d'informations sur les booléens en javscript peuvent être trouvés ici .
Cela dépend Si vous craignez que votre variable ne finisse par devenir quelque chose qui résout comme VRAI. Ensuite, la vérification dure est un must. Sinon, c'est à vous de décider. Cependant, je doute que la syntaxe whatever == TRUE puisse confondre quelqu'un qui sait ce qu'il fait.
Si la variable ne peut jamais prendre que des valeurs booléennes, il est raisonnable d'utiliser la syntaxe la plus courte.
Si d'autres types peuvent éventuellement être affectés et que vous devez distinguer true de 1 ou "foo", vous devez utiliser === true.