Dois-je réutiliser des variables?
Dois-je réutiliser des variables?
Je sais que de nombreuses meilleures pratiques disent que vous ne devriez pas le faire, cependant, plus tard, lorsque différents développeurs déboguent le code et ont 3 variables qui se ressemblent et la seule différence est qu'elles sont créées à différents endroits du code, il pourrait être confus. Les tests unitaires en sont un excellent exemple.
Cependant, je fais sais que les meilleures pratiques sont la plupart du temps contre. Par exemple, ils disent de ne pas "remplacer" les paramètres de la méthode.
Les meilleures pratiques sont même contre l'annulation des variables précédentes (dans Java il y a Sonar qui donne un avertissement lorsque vous affectez null à la variable, que vous n'avez pas besoin de le faire) pour appeler le garbage collector depuis Java 6. Vous ne pouvez pas toujours contrôler quels avertissements sont désactivés; la plupart du temps, la valeur par défaut est activée.)
Votre problème apparaît uniquement lorsque vos méthodes sont longues et effectuent plusieurs tâches dans une séquence. Cela rend le code plus difficile à comprendre (et donc à maintenir) en soi. La réutilisation de variables ajoute à cela un élément de risque supplémentaire, rendant le code encore plus difficile à suivre et plus sujet aux erreurs.
La meilleure pratique de l'OMI consiste à utiliser des méthodes suffisamment courtes qui ne font qu'une chose, éliminant tout le problème.
La réutilisation variable dans une méthode est un signe fort que vous devez la refactoriser/la diviser.
Donc, ma réponse serait que vous ne devriez pas les réutiliser, car si vous le faites, il serait beaucoup plus difficile de le refaçonner plus tard.
Ça dépend.
Certaines variables peuvent être créées exactement dans le but de contenir un certain type de données, qui peuvent changer pendant l'exécution d'une fonction. Les codes de retour viennent à l'esprit ici, par exemple:
void my_function() {
HRESULT errorcode;
errorcode = ::SomeWindowsApiFunction();
if (FAILED(errorcode)) { /* handle error */ }
errorcode = ::AnotherWindowsApiFunction();
if (FAILED(errorcode)) { /* handle error */ }
}
Le nom de la variable indique très clairement ce que cette variable est destinée à stocker. Je pense que d'autres cas d'utilisation tels que celui-ci sont possibles, où une variable est conceptuellement un conteneur qui est logiquement utilisé par différentes instances de choses très similaires au cours d'une fonction.
En général, cependant, cela ne devrait être fait que dans des circonstances où cela est absolument clair pour les lecteurs potentiels du code. En aucun cas, sauf peut-être une optimisation extrême sans égard à la lisibilité du code, une variable ne doit être réutilisée juste parce que le type convient.
Tout cela découle essentiellement des bonnes pratiques de nommage des variables. Les noms devraient parler d'eux-mêmes. S'il est difficile de mettre le but exact de toutes les réutilisations dans un nom court, il est préférable d'utiliser simplement des variables distinctes.
La principale raison pour laquelle je ne réutilise pas les variables (en particulier dans les tests unitaires) est qu'il introduit un chemin de code inutile, difficile à tester et à déboguer. Un bon test unitaire doit être indépendant des autres tests et lorsque vous réutilisez une variable de niveau de classe (instance) dans un montage de test unitaire, vous devez vous assurer de vérifier leur état avant chaque test. Un bon test unitaire isole également les défauts, donc en théorie, chaque cas de test (méthode) ne devrait affirmer qu'un seul comportement pour le système testé. Si vos méthodes de test sont écrites comme ceci, il est rarement nécessaire ou avantageux de réutiliser une variable de niveau de méthode. Enfin, dans les langages qui prennent en charge les fermetures et le traitement asynchrone, il est vraiment difficile de raisonner sur ce qui se passe si vous réutilisez des variables dans une méthode.
Vous devez utiliser différentes variables. Si vous craignez que votre collègue soit confus, donnez-leur des noms qui couvrent clairement leurs rôles.
La réutilisation des variables est une source probable de confusion à l'avenir; mieux de l'éclaircir maintenant.
Dans certains cas, le même nom de variable peut être réutilisé; par exemple i dans une simple boucle de comptage. Dans ces cas, vous devez bien sûr vous assurer que les variables sont dans leur propre portée.
EDIT: La réutilisation des variables est parfois un signe que le principe de responsabilité unique est violé. Vérifiez si la variable réutilisée est utilisée dans le même rôle. Si tel est le cas, il se peut qu'il ne soit pas du tout réutilisé (bien qu'il soit toujours préférable d'avoir deux variables différentes, pour restreindre la portée de ces variables). S'il est utilisé dans différents rôles, vous avez une violation SRP entre vos mains.
Il y a une situation dans laquelle vous voudrez peut-être réutiliser une variable indépendamment des excellents conseils donnés par d'autres réponses: lorsque votre compilateur a besoin d'un coup de main.
Dans certains cas, votre compilateur peut ne pas être assez intelligent pour se rendre compte qu'une certaine variable allouée au registre n'est plus utilisée par la partie suivante du code. Par conséquent, il ne réutilisera pas ce registre théoriquement libre pour les variables suivantes, et le code généré peut être sous-optimal.
Notez que je ne connais pas de compilateurs traditionnels actuels qui ne parviennent pas à détecter correctement cette situation, donc ne faites jamais cela, à moins que vous ne sachiez avec certitude que votre compilateur génère du code sous-optimal. Si vous compilez pour des systèmes embarqués spéciaux avec des compilateurs personnalisés, vous pouvez toujours rencontrer ce problème.
Je dirais NON.
Pensez à ce scénario: votre programme a planté et vous devez déterminer ce qui s'est passé en inspectant un vidage de mémoire ... pouvez-vous voir la différence? ;-)
Non, vous n'améliorez pas le code que la machine exécute (... le code d'assemblage). Laissez la réutilisation de la mémoire que le compilateur utilise pour la variable au compilateur. Très souvent, ce sera un registre et la réutilisation ne vous a rien acheté. Concentrez-vous sur la facilité de lecture du code.
Ça dépend. Dans un langage dynamique, où le type réside sur des valeurs plutôt que sur des variables, alors si j'avais un argument bien nommé pour une fonction qui, par exemple, était une chaîne. Si un changement d'algorithme signifiait qu'il était toujours utilisé après avoir été interprété comme un entier, alors, comme première ébauche, je pourrais faire l'équivalent de
scrote = int (scrote)
Mais je chercherais finalement à changer le type envoyé à la fonction et à noter le changement de type de paramètre.
Tout d'abord, examinez votre environnement de développement. Si vous rencontrez des problèmes de débogage car vous avez cinq variables dans des étendues différentes avec des noms identiques et que le débogueur ne vous montre pas laquelle de ces variables est celle dont vous avez besoin, n'utilisez pas cinq variables avec le même nom. Il existe deux façons d'y parvenir: utilisez une variable ou utilisez cinq noms différents.
Votre débogueur peut également rendre difficile le débogage d'une fonction avec de nombreuses variables. Si une fonction avec 20 variables est plus difficile à déboguer qu'une fonction avec 16 variables, alors vous pourriez envisager de remplacer 5 variables par une. ("Pourrait considérer" n'est pas la même chose que "devrait toujours").
C'est Ok pour avoir une variable utilisée à plusieurs endroits tant que la variable a toujours le même objectif. Par exemple, si dix appels de fonction renvoient un code d'erreur, qui est traité immédiatement pour chaque appel, utilisez une variable et non 10. Mais n'utilisez pas la même variable pour des choses complètement différentes. Comme utiliser "nom" pour un nom de client, et 10 lignes plus tard en utilisant la même variable pour un nom de société, c'est mauvais et vous Pire, en utilisant "customerName" pour un nom de client, et 10 lignes plus tard en utilisant la même variable "customerName" pour un nom de société.
Surtout, rien n'est une règle de fer. Tout a des avantages et des inconvénients. Si les "meilleures pratiques" suggèrent une chose et que vous avez des raisons de dire que c'est une mauvaise idée dans votre situation spécifique, ne le faites pas.
Tout d'abord, examinez votre environnement de développement. Si vous rencontrez des problèmes de débogage car vous avez cinq variables dans des étendues différentes avec des noms identiques et que le débogueur ne vous montre pas laquelle de ces variables est celle dont vous avez besoin, n'utilisez pas cinq variables avec le même nom. Il existe deux façons d'y parvenir: utilisez une variable ou utilisez cinq noms différents.
Votre débogueur peut également rendre difficile le débogage d'une fonction avec de nombreuses variables. Si une fonction avec 20 variables est plus difficile à déboguer qu'une fonction avec 16 variables, alors vous pourriez envisager de remplacer 5 variables par une. ("Pourrait considérer" n'est pas la même chose que "devrait toujours").
C'est Ok pour avoir une variable utilisée à plusieurs endroits tant que la variable a toujours le même objectif. Par exemple, si dix appels de fonction renvoient un code d'erreur, qui est traité immédiatement pour chaque appel, utilisez une variable et non 10. Il y a un problème avec cela: le compilateur vous indique généralement lorsque vous utilisez une variable non initialisée. Mais ici, si vous lisez le code d'erreur après l'appel 6, mais que la variable n'a pas réellement été modifiée après l'appel 5, vous obtiendrez des données inutiles sans que le compilateur ne vous prévienne. Parce que la variable a été initialisée, avec des données qui sont maintenant inutiles.
Surtout, rien n'est une règle de fer. Tout a des avantages et des inconvénients. Si les "meilleures pratiques" suggèrent une chose et que vous avez des raisons de dire que c'est une mauvaise idée dans votre situation spécifique, ne le faites pas.