La vérification d'une véritable explicitation est-elle mauvaise de par sa conception ?

Question

Est-il considéré comme mauvais de vérifier explicitement la présence du booléen true. Serait-il préférable de faire un simple if(success) ?

J'ai vu plusieurs plaisanteries sur la façon dont les if (someBoolean === true) est un code horrible dans un langage fortement typé, mais est-il également considéré comme mauvais dans les langages faiblement typés ?

Cela s'applique à tout langage faiblement typé qui effectue une coercion de type sur une instruction if.

Un exemple spécifique serait :

var onSuccess = function (JSONfromServer) {
    // explicitly check for the boolean value `true`
    if (JSONfromServer === true) {
         // do some things
    }
}

// pass it to an ajax as a callback
doSomeAjax(onSuccess);

[Editer]

Dans ce cas particulier, la variable de succès est tout JSON valide renvoyé par un serveur. Il peut donc s'agir de n'importe quoi. S'il s'agit du booléen true, le succès est au rendez-vous. Si c'est un objet de gestion d'erreur, il sera traité. S'il s'agit d'un autre objet, il sera probablement traité discrètement.

La question était de savoir si le fait de renvoyer le serveur true en tant que JSON et de vérifier s'il existe une bonne façon de gérer le cas où l'action a réussi.

Je voulais cependant éviter d'être spécifique à JavaScript et AJAX.

Answer 1

En Javascript, il est utile de savoir qu'au-delà des booléens true et false, les valeurs peuvent être sincère y falsy .

Envisager :

if (false)     // evaluates to false.
if (0)         // evaluates to false, 0 is falsy.
if ("")        // evaluates to false, empty strings are falsy.
if (null)      // evaluates to false, null values are falsy.
if (undefined) // evaluates to false, undefined values are falsy.
if (NaN)       // evaluates to false, NaN is falsy.

Toutes les autres valeurs des objets sont vraies.

Si les valeurs vraies et fausses conduisent à des erreurs dans votre logique, vous devriez envisager d'utiliser explicitement la fonction === y !== pour s'assurer que les objets sont comparés par type et par valeur.

Answer 2

J'ai moi-même des doutes à ce sujet.

D'un certain point de vue, l'exemple de code que vous avez posté est bon, en raison de la manière dont Javascript gère la coercition de type. Un simple if (success) entrerait dans le bloc if tant que success était sincère - par exemple, une chaîne de caractères non vide ferait l'affaire. La triple égalité garantit que success est bien la valeur booléenne true ce qui constitue une garantie plus forte que celle que vous obtiendriez avec la version courte (et probablement celle que vous souhaitez).

Toutefois, si vous besoin c'est-à-dire que vous ne savez pas si success sera un booléen, ou une chaîne de caractères, ou un nombre entier - je dirais que c'est une odeur de code en soi. Quelle que soit la manière dont vous effectuez la comparaison, je comparerais toujours avec une variable qui sera inévitablement un booléen ; à ce moment-là, la forme de comparaison utilisée n'a pas d'importance puisqu'elle est équivalente. En fait, j'introduirais même une variable "redondante" de la manière suivante :

var successCount = items.size(); // or some other way to get an integer
var success = successCount > 0;
if (success) {
   ...
}

Donc, euh, oui. Je ne pense pas que quelqu'un puisse vraiment se plaindre de l'utilisation (explicite) de === dans la comparaison en raison de sa différence fonctionnelle. Mais de la même manière, si vous utilisez clairement les valeurs booléennes success Je ne pense pas non plus qu'il faille se plaindre de la brièveté du style.

(En ce qui concerne votre première phrase, je ne pense pas qu'il soit mauvais de vérifier explicitement la valeur booléenne true dans un langage à typage dynamique, si cette valeur correspond à ce que vous voulez. Ce n'est superflu que lorsque le typage statique contraint déjà la variable à être un booléen).

Answer 3

En règle générale, les noms de variables booléennes doivent être du type :

success, enabled, pass

pour avoir une valeur réelle. Ainsi, les

if(success) //or

if(enabled) //or

if(pass) //or

if(enabled) //or

est lisible de manière compréhensible et logique. Mais si vous avez des variables comme :

result, status, port1.bit7

il est préférable d'écrire :

if(result == true) //or

if(status == false) //or

if(port1.bit7 == true)

parce qu'il est plus facile à comprendre que l'exemple ci-dessous :

if(result)
{
  ....
}

La lisibilité est synonyme de maintenabilité.

Answer 4

Qu'est-ce qui peut mal tourner ? Exactement rien. Dans le meilleur des cas, votre fonction ne fait rien. C'est toujours mieux que d'avoir un argument aléatoire accepté comme true .

Si vous utilisez true tout le reste du temps, alors vous devriez aussi vérifier explicitement si c'est le cas.

Si je suis tout à fait favorable à l'idée de if foo: en Python, il y a une grande différence ici et c'est le fait qu'en fin de compte, un programmeur jQuery aléatoire peut venir et penser "Oh ! ça marche aussi avec une chaîne et new Boolean() "et l'utilise.

En ce qui concerne la suggestion de Sean d'utiliser !! Cela dépend vraiment si vous voulez seulement qu'un booléen soit accepté ou tout ce qui est vrai. Pour une API propre, je n'accepterais que les booléens.

Answer 5

Pour ajouter à cette conversation, les variables sessionStorage et localStorage ne peuvent être stockées que sous forme de chaînes aujourd'hui, donc si vous utilisez :

sessionStorage.setItem('completed',true);

Il sera en fait converti en une chaîne de caractères et stocké sous la forme "true". J'ai vu de nombreuses personnes écrire des méthodes et des conversions pour manipuler cette valeur afin de pouvoir utiliser une instruction if avec une valeur booléenne, alors qu'une simple instruction

if sessionStorage.getItem('completed') === 'true';

suffirait et serait, à mon avis, parfaitement lisible et maintenable.