Quelle est la meilleure pratique et pourquoi?
Déclarez une variable:
exampleFunction(requestData: Object) {
doSomething(requestData.username);
}
Ou accédez directement à la propriété de l'objet?
exampleFunction(requestData: Object) {
const username = requestData.username;
doSomething(username);
}
5 Réponses :
Avantages de la première option:
Première option contre:
Vous ne devez jamais utiliser let au lieu de const .
Mon mauvais laissez-moi mettre à jour la réponse
Tout d'abord, vous référencez un objet, pas le clonage.
La bonne façon de cloner est par Object.assign () ou lodash (ou similaire) _.cloneDeep (), ou un opérateur de diffusion ou autre.
Veuillez vous référer à typescript - objet de clonage pour plus d'informations sur le clonage.
Pour en venir à la question, lorsque vous avez une seule variable pour travailler, les deux ont la même lisibilité dans une méthode aussi courte.
Juste parce que la méthode est si courte, je préférerais la dernière, car la lecture d'une seule ligne de code explique quelle propriété de l'objet je passe à ma méthode au lieu de lecture inverse du code.
Pour mon goût et pour mon opinion générale, la déstructuration est la manière la plus propre qu'un autre programmeur attend de votre code:
const { username, var1, var2 } = requestData;
Et s'il n'avait pas besoin de le cloner et d'avoir besoin d'une référence au lieu de copier en profondeur l'objet?
Ceci est un petit exemple. Le code réel avec lequel je travaille est d'environ 60 lignes de code où la variable est utilisée plus d'une fois.
Je l'ai souligné uniquement parce que le code simulé n'est pas clair à ce sujet et cloneFullProject est assez sémantique mais peut être trompeur
Si des variables sont utilisées plusieurs fois, vous pouvez utiliser la déstructuration, ce qui est encore plus clair: `const {username, var2, var3, var4} = requestData; '
Le nom de la fonction n'est pas pertinent pour le moment, je ne suis pas sûr que vous ayez compris la question.
Oui j'ai compris, je rapporterai mon commentaire déstructurant dans la réponse
Le moteur Javascript V8 effectue une optimisation en prétraitant le code et en vérifiant si une variable peut être supprimée ou s'il existe un modèle régulier dans le code, afin de réduire la charge utile d'exécution.
Pour cette raison, il n'y a aucun problème de mémoire lors de l'utilisation d'un formulaire ou d'un autre, du moins en utilisant le moteur V8 (par exemple, Chrome ou NodeJS).
Même si cette optimisation n'est pas effectuée, il ne s'agit que d'un pointeur ou d'une variable primitive, donc cela ne coûtera pas plus de quelques octets.
C'est différent si nous parlons du coût de transmission du code. Nous savons que JavaScript n'est pas un langage compilé et qu'il doit atteindre l'ordinateur du client pour être exécuté, donc chaque espace, indentation, point-virgule, coûtera dans l'ordre du temps utilisé pour le transfert.
Pour réduire ce coût, vous pouvez modifier et réduire votre code, mais ce type d'optimisation n'est généralement pas effectué.
Enfin, il est impossible de penser à un scénario où cela puisse faire une différence, donc je vous conseille d'utiliser le formulaire que vous pensez qu'il est plus lisible et peu importe les autres paramètres.
Bien expliqué!
Je pense que ma réponse a besoin d'une source, je vais ajouter quelque chose plus tard
Il s'agit principalement d'une question basée sur l'opinion. Donc, la réponse donnée ci-dessous est mon point de vue.
Par refactoring de Martin Fowler est une technique ( Remplacer Temp par une requête ).
après cela, vous passerez à la deuxième variante
exampleFunction(requestData: Object) {
const username = requestData.username;
doSomething1(username);
doSomething2(username);
...
}
Mais c'est aussi l'odeur ( Middle Man ).
En guise de conclusion dans cet exemple , il est préférable de supprimer complètement cette méthode :)
Cependant, dans certains cas, le premier exemple est préférable. Par exemple:
vous avez plusieurs méthodes qui prennent les paramètres requestData.username .
cloneFullProject(requestData: Object) {
doSomething(requestData.username);
}
Et dans ce cas, la variable temporaire est justifiée
Si vous demandez un avis: cela dépend, et c'est une préférence.
Je me demande laquelle de ces options est la meilleure pratique.
Dans le contexte ci-dessus, la propriété d'objet d'accès est meilleure, je pense. Il n'est pas nécessaire de déclarer une variable pour la contenir. Et si vous utilisez un meilleur IDE comme, il vous suggérera d'utiliser le second, dans le contexte ci-dessus.
Je ne sais pas s'il existe une bonne pratique, mais c'est sûr que
requestDataest trop large. Que contient requestData?J'irais pour la deuxième option. C'est beaucoup plus propre de cette façon.
Selon mon point de vue, dans le premier cas, vous avez besoin d'une variable supplémentaire qui n'est pas réellement requise car vous ne la traitez pas davantage dans le même bloc. Donc, je recommande le deuxième dans votre scénario.
Que faire si le code réel fait plus de 60 lignes et que la variable est utilisée plusieurs fois à différents endroits?
puis le premier cas est recommandé afin que vous puissiez le traiter facilement avec une frappe moins / sûre
Cela dépend du coût d'accès à la propriété (ce qui est généralement plus coûteux qu'un accès variable en effet, mais avec les optimisations des compilateurs modernes, pas beaucoup).
Je vois que ma question a été mise en veilleuse parce qu'elle était essentiellement basée sur l'opinion. Si tel est le cas, je suppose que je peux conclure qu'il n'y a pas de meilleure pratique entre les deux.