2009-09-15 10 views
1

Oui, lisez correctement. Dans la dernière fois, j'ai vu différents modèles de validation d'arguments en JavaScript (fonctions) et je me demandais lequel d'entre eux serait la meilleure pratique. Au début, je vais montrer deux exemples d'extraits de code. La première montre (dans mes mots) une validation argument/condition "immédiate" et la seconde une validation "retardée". Chacun d'eux affecte l'apparence du code suivant de différentes manières. Jusqu'à présent, j'ai toujours utilisé la validation "immédiate". Mais lentement, je commence à douter s'il est raisonnable de forcer tout le code suivant dans de tels blocs conditionnels. S'il vous plaît dites-moi ce que vous pensez et ce qui pourrait être le "meilleur" modèle.Où effectuer la validation des arguments en JavaScript?

Et qu'en est-il de l'endroit où les variables sont déclarées? Quelques fois j'ai lu, que toutes les variables doivent être déclarées sur de la méthode, avant qu'elles ne soient réellement utilisées. Est-ce correct? Parce que je pense qu'il est inutile de déclarer des variables avant d'être sûr qu'elles seront réellement utilisées (peut-être que des arguments invalides forcent le lancement d'une exception), j'ai déplacé la partie variable-déclaration au-delà de la partie validation. Est-ce conseillé?

Merci!

Premier exemple:

if ( colorStops.constructor === Array 
    && colorStops.length 
    && colorStops.every(function(c) { 
     return c instanceof ColorStop 
    })) 
{ 
    var privateVar1 = "foo", 
     privateVar2 = "bar", 
     privateVar3 = "tutifrutti"; 

    // here goes the code 
} 
else { 
    throw new TypeError("GradientCanvasFacade: cannot add Colors; " + 
     "invalid arguments received"); 
} 

Deuxième exemple:

if (cg instanceof ColorGradient) { 
    throw new TypeError("PresetManager: Cannot add preset; " + 
     "invalid arguments received"); 
} 

var privateVar1 = "foo", 
    privateVar2 = "bar", 
    privateVar3 = "tutifrutti"; 

// here goes the code 
// Here goes the code that get executed when no explicit 
// return took place ==> all preconditions fulfilled 
+0

De toute façon, n'utilisez pas 'constructor'. Ce n'est pas dans tous les navigateurs et quand ça l'est, ça ne ressemble pas du tout à ce que ça ressemble. Tenez-vous à instanceof pour les objets JS natifs. – bobince

Répondre

1

Puisque les variables JavaScript sont étendus à la fonction déclarant et non au bloc comme la plupart des autres langues, déclarant variables au début de la la fonction fait beaucoup de sens. Maintenant, imaginez une fonction beaucoup plus complexe, pour moi au moins, déclarant que x au début fait beaucoup de sens. Pour les variables généralement liées à un bloc (comme les variables d'itération ou les collections), je les déclare quand même dans le bloc.

Je choisirais certainement votre deuxième exemple non parce qu'il échoue plus tôt, parce que ce n'est pas le cas, mais parce qu'il est plus facile de supprimer et d'ajouter des validations de cette façon sans casser une structure compliquée.

0

J'irais avec le second, simplement parce que c'est plus facile à lire. En outre, avec le premier, si votre fonction est très longue, quelqu'un regardant en bas, se demandera à quoi sert }, et doit sauter jusqu'au sommet pour voir.

Également la portée des variables est très claire, même pour quelqu'un qui oublie que javascript a des règles de portée étranges.

De plus, comme mentionné par Martijn, la seconde méthode permet de vérifier plus facilement les différentes erreurs, c'est-à-dire que chacune peut avoir sa propre instruction if et ainsi de suite.

0
if (some condition) { 
    if (some other condition based in the first) { 
    if (another condition based in 1st and 2nd) { 
     do_job(); 
    } else? 
    } else? 
} else? 

Où placer le bloc else? Après chaque si ou après le dernier?

Il semble absolument plus lisible le deuxième choix

Questions connexes