J'utilise parfois des variables temporaires pour raccourcir les identificateurs: Bien que ce soit un exemple de PHP, je vous demande en général:
9 Réponses :
Cet exemple est parfaitement bien, car vous l'utilisez dans des fonctions / méthodes.
La variable sera non définie juste après la fin de la méthode / de la fonction - il n'y a donc pas beaucoup de fuite de mémoire ou de quoi.
aussi en faisant cela, vous "en quelque sorte" mise en œuvre sèche - ne vous répétez pas vous-même.
Pourquoi écrire tant de $ ceci-> ActualDatabase Quand vous pouvez écrire $ dB . Et que si vous devez changer $ ceci-> actuelleDatabase à d'autres valeurs?
Malgré tout, la variable sera également déséquilibrée après la fin de l'exécution du script.
@thephpDéveloppeur, ce n'est pas ce que signifie un moyen sec. Sec est à propos de ne pas définir une entité dans plus d'un endroit, comme ayant une constante définie dans un fichier de configuration et dans votre code source (au lieu de la lire à partir du fichier de configuration). La raison pour ne pas se répéter consiste à éviter les erreurs qui cultivent de devoir faire double entretien (telles que la modification d'une valeur dans le fichier de configuration, mais oublier (ou ne pas savoir) pour changer le code source).
En réalité, vous n'essayez pas d'éviter taper (sinon, vous utiliseriez un mécanisme d'achèvement de votre éditeur), mais vous faites simplement votre fonction plus lisible (en utilisant des "abréviations") qui est une bonne chose.
Les inconvénients apparaîtront lorsque vous commencerez à faire cela pour éviter de taper (et de sacrifier la lisibilité)
en général:
Donc, je dirais: non, ce n'est pas une mauvaise pratique.
Si vous faites ceci soigneusement, il est absolument bien. Tant que vous utilisez seulement quelques-unes de ces variables dans une petite quantité de code et à l'intérieur de petites fonctions, je pense que c'est correct.
Si vous avez beaucoup de ces variables et qu'ils sont mal nommés comme i, J, L et F dans la même fonction, la compréhensibilité de votre code souffrira. Si tel est le cas, je préférerais taper un peu plus encore, puis n'a pas compréhensible de code. C'est une raison pour laquelle un bon IDE a une achèvement automatique du code.
Non, je pense, c'est bon. Souvent performance si pas aussi critique que le code lisible propre.
En outre, vous vendez une mémoire une petite allocation frappée sur la pile pour des appels de méthode plus rapides en évitant la déséroférance supplémentaire.
Je semble vous rappeler que Steve McConnell recommande d'utiliser des variables temporaires dans "Code complet". Au risque de commettre de l'hérésie, je dois être en désaccord. Je préfère la lisibilité supplémentaire introduite. Je me trouve également que je les ajoute à l'aide d'un débogage d'une seule étape, puis ne voyez aucune raison de les supprimer.
Je suis d'accord avec vous et en désaccord avec McConnell ici. Je préfère également utiliser des variables locales sur des appels de méthode à plusieurs lignes par exemple. Il facilite également le débogage, car vous pouvez vérifier la valeur de chaque variable.
Il peut être évité. Lorsque vous avez besoin d'une variable temporaire, un nom de méthode doit être refacturé, car il doit être renommé d'être bien compris.
Cela dépend de quel est le contrat sur $ ceci-> actuelleDatabase. Peut-il changer à tout moment, après un appel de méthode? Si cela change, êtes-vous censé continuer à utiliser l'objet que vous avez fait lorsque vous avez effectué votre premier appel de DB ou êtes-vous censé toujours nous toujours nous la valeur actuelle? Cela dicte si vous Donc, strictement parlant, ce n'est pas une question de style du tout.
Mais, en supposant que le député n'est jamais changé lors d'appels de fonction telles que cela, cela ne fait aucune différence. Je dirais que le stocker dans une variable est légèrement meilleur, car il est plus facile de lire et d'éviter un accès membre sur un objet à chaque opération. Le compilateur peut l'optimiser si c'est bon, mais dans de nombreuses langues, ces optimisations sont très difficiles - et l'accès à une variable locale est presque invariablement plus rapide que d'accéder à un membre d'un objet.
Je ne pense pas qu'il y ait une pénalité de performance si vous utilisez la variable d'origine au lieu de sauter la première Dréréférence ( Cependant, comme la lisibilité est très améliorée à l'aide de l'abréviation, allez-y!
Bien sûr, cela dépendra également des conventions de codage de votre équipe. $ ceci-> actuelleDatabase ).
Si vous obtenez $ ceci-> CurrentDatabase implique un appel de la fonction (je ne connais aucun PHP pour que je ne puisse pas dire), il devrait être plus rapide d'utiliser une variable temporaire, car la fonction n'est appelée qu'une seule fois. Nurs à l'esprit la réponse du nudité.
Un getter résoudra votre problème: par code de nettoyage n.
Indice: à partout où vous avez besoin
$ dB , vous devez le déclarer$ dB = $ ceci-> actuelleDatabase; . Et si vous modifiez la mise en œuvre dedB , vous devrez également modifier cetteDOSOMOD () fonction.