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

J'ai lu pas mal de choses sur JavaScript, et je n'ai jamais vu personne dire que if(success) était une mauvaise pratique. Je le ferais. Êtes-vous sûr que le success sera toujours booléen ? Pour l'instant, si cela devait changer en quelque chose d'autre, il faudrait modifier la fonction. Mais si vous utilisez simplement if(success) Il fonctionnerait pour d'autres valeurs "vraies" et "fausses", comme une chaîne de caractères par rapport à une chaîne vide, ou 1 par rapport à 0.

Si vous souhaitez convertir ce paramètre en valeur booléenne, il vous suffit de le renier : !!success ; mais ce n'est pas nécessaire à l'intérieur d'une conditionnelle comme celle-ci.

Answer 2

S'agit-il d'une odeur de code, d'une odeur de langage, d'un détail de mise en œuvre ou d'une question de convention ?

En fait, cela dépend de la situation.

Mettre toutes les valeurs fausses et toutes les valeurs vraies dans un seau simplifie les choses, jusqu'à ce que les différences soient importantes, que ce soit à cause d'une mauvaise conception du code ou parce qu'elles sont vraiment importantes pour une raison ou une autre.

Dans le même ordre d'idées, Hoare s'est excusé d'avoir inventé les null qui se rapproche le plus de la racine de ce problème de vérité. La conception de JavaScript ne fait qu'embrouiller le problème en ajoutant encore plus de valeurs vraies, ce qui conduit de nombreuses personnes à préconiser une vérification explicite pour éviter les erreurs difficiles à repérer (Douglas Crockford). La communauté JavaScript a accepté le langage lui-même, mais est un peu coincée. L'équipe de base de Python préconise le contraire, car la conception du langage semble viser à simplifier les choses, et non à les embrouiller, et l'équipe de base prévoit toujours des changements dans le langage. Les petits changements itératifs sont l'essence même des grandes améliorations au fil du temps, qu'il s'agisse des conventions ou de la conception du langage.

Les deux sont de bonnes stratégies pour leur situation particulière. Je ne dis pas que c'est la seule source d'amélioration, mais c'est une source majeure d'amélioration à l'heure actuelle.

Par exemple True y False sont en fait des sous-classes d'un int en Python, 0 et 1 en particulier. Cela présente plusieurs avantages sur le plan de la conception. Ensuite, PEP8 préconise de préférer l'utilisation de

if a_reference:
    pass

La seule fois où None ne doit être utilisé en Python que lorsqu'il s'agit de spécifier un paramètre optionnel.

def foo(bar=optional): # NOTE I made up this idealistic construct
    """Looks good at the surface"""
    pass

def foo(bar=None):
    """But this is clear to the programmer"""
    pass

En JavaScript, toutes les variables sont implicitement facultatives :

function foo(x, y, z) {
    // Certainly not clear to the programmer.
}

Et Crockford préconise de vérifier explicitement les choses pour essayer de clarifier la langue.

if (foo === undefined) {
    // pass
}

En fait, JavaScript a ajouté la référence nulle n° 2, connue sous le nom de undefined . Je trouve également amusant que le langage JavaScript soit si mal considéré par la communauté des programmeurs qu'ils pensent que c'est un bon compromis d'ajouter la complexité d'utiliser quelque chose comme CoffeeScript, GWT, Pyjamas, juste pour avoir un meilleur langage côté client. Bien sûr, je ne suis pas d'accord avec cette complexité supplémentaire, mais il est malheureusement vrai que certaines personnes peuvent en bénéficier, au moins temporairement, et faire leur travail plus rapidement, au lieu de s'occuper de JavaScript.

Je pense cependant qu'il s'agit d'une décision insensée à long terme.

Answer 3

Pour moi, la solution la meilleure et la plus simple est la suivante :

var isTrue = /^true$/.test( 'true' );    // true
var isTrue = /^true$/.test( 'false' );   // false
var isTrue = /^true$/.test( true );      // true
var isTrue = /^true$/.test( false );     // false
var isTrue = /^true$/.test( ' true ' );  // false
var isTrue = /^true$/.test( '' );        // false
var isTrue = /^true$/.test( 'prueba' );  // false