Une variable publique contrevient aux règles qui président à une bonne architecture de code car elle impose un couplage fort entre les procédures qui l'utilise et l'application dans son ensemble. Cela veut dire que les procédures/fonctions qui utilisent des variables publiques sont fortement liées à leur déclaration/valorisation. Cela amène aux difficultés que je décris ci-dessous. Ce couplage fort entre les procédures/fonctions est pour moi la raison principale qui me fait rejeter l'emploi des variables publiques. Dans les codes que j'écris, je cherche toujours à écrire les procédures/fonctions les plus courtes possibles, recevant uniquement les arguments qu'elles ont a traiter et pouvant être testées de façon autonome. La première action pour bien gérer les erreurs est de les prévenir, et utiliser une architecture à couplage faible permettant des tests autonomes est certainement la meilleure prévention des erreurs en programmation.Envoyé par eriiic
Une variable publique pouvant être modifiée par n'importe quelle partie du code, une procédure/fonction pourrait utiliser une variable mal initialisée ou modifier la valeur d'une variable publique alors que ce n'est pas désiré. La maintenance, la vérification et l'évolution du code sont ainsi rendues plus ardues, car il faut à chaque fois s'assurer que les variables publiques utilisées sont correctement valorisées.
Les bugs, lors des tests ou en prod, lorsqu'ils ne sont pas correctement gérés par des On Error (et je lis malheureusement des inepties sur le forum au sujet de la gestion deserreursexceptions, rejetée par des personnes qui n'en maîtrisent pas les mécanismes), amènent à réinitialiser les variables publiques, ce qui rend le code instable et, à nouveau, difficilement testable, maintenable et évolutif.
Les tests sont rendus plus compliqués à réaliser car il faut à chaque fois s'assurer que les variables publiques ont les valeurs attendues. On ne peut donc réaliser des "tests unitaires" ou à tout le moins tester correctement les procédures/fonctions isolément.
Les variables publiques "ne meurent pas". Elles restent donc en mémoire jusqu'à la mort du projet, ce qui peut être préjudiciable aux performances, selon leur taille et le contexte dans lequel elles ont été utilisées.
Les codes qui utilisent des variables publiques sont difficilement réutilisables dans d'autres configurations et/ou d'autres projets. Il faut à chaque fois les modifier et les adapter, lorsque cela est possible. Or, réutiliser des procédures/fonctions génériques, outre la rentabilité financière de l'opération, permet une rentabilité technique car on réutilise des procédures/fonctions paramétrées qui ont été testées et validées, dégageant le programmeur de cette tâche fastidieuse, chronophage et non rentable. La paramétrisation de procédures/fonctions que l'on rend génériques permet au contraire d'utiliser les briques logicielles ainsi créées. Cette "générisation" du code par l'utilisation des paramètres permet une augmentation de l'abstraction par la réutilisation de code, dégageant le développeur du besoin de réinventer la roue à chaque nouveau développement. La systématisation de l'utilisation d'outils paramétrables rend la programmation plus facile, plus fluide, plus stable, plus maintenable et, in fine, plus rentable (temps, argent). L'utilisation de variables publiques est incompatible avec cet objectif de systématisation du code.
Pour moi, les variables publiques existent en VBA (et pas dans tous les langages, même s'il y en a d'autres qui les permettent) parce que la volonté de Microsoft était de "simplifier la programmation" au détriment de la rigueur et de la bonne architecture. Je pense qu'on peut s'en passer dans tous les cas (ou presque). D'autres aberrations existent en VBA comme les Exit, mais cela ne signifie pas que ce soit une bonne pratique de les utiliser.
My two cents, comme on dit
Répondre avec citation
Partager