Il semble y avoir une grande aversion pour la création d’une fonction dans JS. Cette aversion incite les gens à faire preuve d'intelligence et à utiliser des astuces ridicules simplement pour garder les éléments dans une ligne, comme cela aurait été le cas pour un appel de fonction. Bien entendu, le nom de la fonction dans un appel sert également de documentation supplémentaire. Nous ne pouvons pas associer un commentaire à une expression délicate, car cela éviterait de le faire et nous l'appelons simplement "idiome js" et tout à coup, cela se comprend.
Javascript est extrêmement accessible, la plupart des gens ne mangent pas les spécifications du petit-déjeuner comme nous le faisons. Ainsi, ils ne comprendront jamais quelles sont les hypothèses cachées et les cas extrêmes d’un idiome.
x = x || 'default_value';
Le joe moyen soit ne comprend pas cela ou a mémorisé que c’est l’idiome de la valeur par défaut. Les deux sont nuisibles, en fait le dernier l'est encore plus. Il ne comprendra pas les hypothèses et les cas extrêmes ici. Il ne se souciera pas de lire le cahier des charges et de le comprendre jamais.
Quand je regarde ce code je vois « si elle est null
ou undefined
, réglez ensuite à cette valeur par défaut. Bien qu'il traitera également implicitement +0
, -0
, NaN
, false
et ""
ne pas les valeurs appropriées. Je dois rappeler que 3 mois à partir de maintenant , quand que les besoins changer. Je vais probablement l’oublier. "
L’hypothèse implicite est extrêmement susceptible de provoquer un bogue dans l’avenir. Lorsque votre base de code regorge d’astuces de ce type, il n’ya aucune chance que vous les gardiez toutes dans votre tête lorsque vous songez à ce qu’une modification affectera. Et ceci est pour le "JS pro", le joe moyen aurait écrit le bogue même si les exigences étaient d’accepter une valeur falsy pour commencer.
Votre nouveau fragment de code a une syntaxe plus familière, mais le problème ci-dessus persiste.
Vous pouvez aller avec:
function f(x) {
x = valueOrDefault(x, "default_value");
}
Maintenant, vous pouvez avoir une logique très complexe pour gérer les cas extrêmes et le code client est toujours aussi beau et lisible.
Maintenant, comment faites-vous la différence entre des fonctionnalités de langage avancées telles que le passage d’une fonction en argument ou un truc astucieux comme || "default"
?
Les astuces intelligentes fonctionnent toujours avec des hypothèses cachées qui pourraient être ignorées lors de la création initiale du code. Je n'aurai jamais à modifier un IIFE en autre chose car une exigence a changé, elle sera toujours là. Peut-être qu'en 2020, je pourrai utiliser des modules réels, mais oui.
| 0
ou la version culte de cargaison ~~num
utilisée pour les revêtements de sol suppose des bornes d’entiers positives signées et de 32 bits.
|| "default"
suppose que toutes les valeurs de falsy sont les mêmes que de ne pas transmettre un argument du tout.
Etc.