Je suis plus dans le développement JavaScript et je veux m'assurer que je suis à la suite de conventions populaires. Actuellement, j'ai une bibliothèque qui consiste en des fonctions pouvant être transmises à 1 modèle pour opérer sur ou plusieurs modèles.
Compte tenu du climat que quelques bibliothèques JavaScript sont très populaires, je suis curieux; Serais-je conforme à la "norme de défact" en réalisant mon exigence "mono-élément ou liste" en énumérant la variable des arguments ou en permettant à l'un des arguments d'être un tableau?
< Scénario Strong> Scénario 1: Enumération de l'argument Scénario 2: L'argument d'entité est une instance unique ou une matrice < Pré> xxx J'ai vu des zones de jQuery qui utilisent "scénario 2", mais j'aimerais toujours demander - quelle approche est la plus populaire et pourquoi? merci < / p> [modifier] Quelques commentaires ont suivi la même veine, d'utiliser un objet d'arguments - qui est similaire à "scénario 2" - mais je pense qu'il introduit une complexité inutile - la Les éléments n'ont pas besoin d'être nommés, car ils ne sont qu'une liste de longueur variable. Je pensais que j'ajouterais d'ajouter cela ici au cas où ma question n'était pas assez claire. [EDIT] Je vois le code comme le tout via JQuery-1-7.js < / p> [modifier] après une discussion avec JP, je suis arrivé avec cela - ce que je ne dis pas est le bon choix, mais c'est très flexible ... Si vous appelez cette fonction au début de toute fonction - il traitera la dernière ARG dans l'appelant en tant que "argument de longueur variable" - Soutenir Toute conventions. Par exemple, je peux l'utiliser comme ceci maintenant, je peux appeler "sendemail" de l'une des manières suivantes et cela fonctionnera comme prévu
3 Réponses :
Je préfère personnellement utiliser des littéraux d'objets pour des arguments pour prendre en charge les params nommés, comme celui-ci: Je pense que cela rend le code très lisible et la commande n'a pas d'importance. < p> Vous pouvez également accéder à l'objet argument . Remarque, ce n'est pas un tableau, mais c'est un "type de tableau". Vous pouvez en lire ici: http: // javascriptweblog .wordpress.com / 2011/01/18 / Javascript-arguments-Object-and-Beyond / EDIT: Vous semblez avoir un malentendu ici. Vous utilisez l'expression «objet arguments» et pensez qu'il est identique à la notation littérale objet. Ils ne sont pas. L'objet vous permet de le faire: est-ce que cela aide?
Merci JP - mais un objet d'arguments ne serait pas logique, car je ne veux pas passer une "structure flexible d'articles, où chaque article a un contexte sémantique différent". Chaque "élément variable" a la même signification. c'est-à-dire autoriser les deux "mailserver.send (courrier électronique1);" et "mailserver.send (e-mail1, email2);" Mais je devine que vous préféreriez probablement que mon "scénario 2".
@Adam Note Arguments Les lettres d'objet et d'objet sont des concepts orthogonaux. S'il y avait un paramètre, je n'utiliserais pas de littéraux d'objets. S'il y a plus d'un paramètre, la plupart du temps, je préfère les catégories d'objets. Pour être clair à 100%, je ne suis pas un fan de votre "scénario 2".
En outre, votre scénario 2 n'est pas nécessaire. Parce que vous pouvez déclarer une fonction sans paramètres ni passer autant que vous le souhaitez. Voir mon lien sur le argument objet.
Merci jp. Je serais d'accord avec ça. Je viens d'un contexte C #, alors scénario 1 a le plus de sens pour moi - mais j'ai vu ce dernier utilisé dans JQuery ... dire plus d'un argument doit être envoyé et ils ont tous les deux la même signification sémantique (ce qui est le Cas dans ma question) - Ensuite, les lettres d'objet obtiennent sûrement, car vous devez donner à chaque propriété littéral un nom unique? Je suppose que l'on pourrait utiliser: myfunc ({0: 'Johnson', 1: 'Richardson'}); // Notez comment ils sont tous les deux noms de famille - qui est intentionnel mais n'est pas aussi inutilement verbeux? Les tableaux ajoutent automatiquement le '0' et '1'.
"En outre, votre scénario 2 n'est pas nécessaire" absolument! C'est exactement ce que je pense aussi - mais je l'ai vu faire de cette façon dans le code JQuery. Je veux m'assurer que quelle que soit la façon dont je le fais, c'est logique d'un développeur qui est à jour avec des conventions JavaScript couramment acceptées ...
Laissez-nous Continuez cette discussion en chat
Un autre moyen courant est d'utiliser l'objet littéral comme variables:
myFunction(true, {option: value, option2: value});
Merci Uzi - votre réponse semble être la même que celle de JP's - ne pensez-vous pas que cette approche présente une complexité inutile? L'appelant et la callee doivent être conscients que la convention de dénomination 'option1: x, option2: y' doit être utilisée. L'utilisation de var-args ou d'un tableau ([]) supprime la nécessité de «nommer» chaque entrée.
Je ne sais pas comment cela annonce la complexité. Si vous y réfléchissez, la même manière de déclarer un type de variable, elle n'ajoute pas beaucoup de complexité, elle ajoute beaucoup de verbosité qui peut être un problème de traitance avec une langue de dactylographie vague.
Pour développer sur les autres réponses, il existe deux principales alternatives que je vois généralement: arguments facultatifs et arguments de mots clés. Je ne me souviens pas de voir de bons exemples de l'idiome "UTILISATION DES TRAYS" et il est un type d'obsolète donné comment le tableau code> Arguments code> est toujours disponible de toute façon.
Quoi qu'il en soit, ma règle de maturation est . P>
Si j'ai de nombreux arguments ou que la liste des arguments est susceptible de changer, ou si les arguments n'ont pas de bon ordre naturel, Ma partie préférée à propos de ce style est qu'elle est vraiment flexible et la preuve future, tout en étant un type de documentation auto-documentant (dans un style SmallTalk). P>
Si j'ai peu d'arguments, qui ne sont pas susceptibles de changer et de leur avoir un ordre naturel, ne strong> a des fonctions qui reçoivent une grande liste d'arguments. Il peut devenir un gâchis s'ils commencent à devenir facultatifs et que vous oubliez la commande p>
ne strong> utilise des tableaux de longueur fixe pour être délicat. Ils sont redondants sans tableaux et quand je vois un tableau, je m'attends généralement à ce qu'il soit 1) être homogène et 2) être capable d'être aussi long que je veux p>
foo(true, [1, 2]); //should be foo(true, 1, 2)
foo(1, 2, null, null, 3, null, null); //ugh
foo(x1, x2);
foo(x1, x2, x3);
foo({x1:'1', x2:'2', x3:'3'});
function foo(kwargs){
//I try to always copy the arguments back into variables.
//Its a little verbose but it helps documentation a lot and also
// lets me mutate the variables if I want to
var x1 = kwargs.x1,
x2 = kwargs.x2,
x3 = kwargs.x3;
}
Remarque: encore une fois: l'objet "Arguments" à mesure que vous l'énoncez, est différent de la réponse de ma réponse et de l'UZI.
J'ai édité ma réponse pour effacer avec espoir la confusion.
Je préférerais si nous n'avions pas confondé le modèle d'objet nommé avec des listes de longueur variable. Les listes de longueur variable me font penser à des choses comme Printf, qui peuvent prendre un certain nombre d'arguments, tandis que les arguments mots clés sont parfaits pour les arguments et les arguments facultatifs pouvant changer d'ordre. Quoi qu'il en soit, il serait probablement préférable que JS était comme Python, où vous pouvez mélanger et correspondre aux deux styles.
@MissingNo - Je suis totalement d'accord, les deux sont des concepts complètement différents. Je vois des objets nommés comme «arguments facultatifs» où chaque argument est explicitement référencé par le code de fonction, pourrait être de type différent et un sens complètement différent. Les listes de longueur variable seraient généralement référencées par le code de fonction via une sorte de boucle, où chaque article devait partager le même schéma de base et traité sémantiquement la même chose.