Discussion:Variable globale

Dans la section "le grand défaut des variables globales", je pense que plusieurs erreurs sont commises. Les fuites de mémoire de sont pas dues aux variables globales mais plutôt aux allocations dans le tas de pointeur (int *ptr = new int) non supprimé et même dans ce cas à la fin de l'exécution du programme (au return de la fonction main) cette mémoire est rendue avec un système d'exploitation moderne. Il faut rappeler que les fonctions elles même sont déclarées en mémoire et de manière globale... L'exemple donné est lui aussi erroné ne désignant ni système d'exploitation ni type de programme. Pour finir elle n'aborde pas le problème de dépendance mutuelle, ni celui de l'utilisation de nom qui pourrait être réutilisé etc etc...

Leçon de morale

Cet article ressemble plus à une leçon de morale (les variables globales c'est mal bla bla bla) qu'à un article encyclopédique. La version en anglais est beaucoup plus complète et objective Bregalad (discuter) 4 novembre 2013 à 22:53 (CET)

Désolé, mais la version anglaise indique tous les risques également (premier chapitre), et aurait même tendance à les minimiser un peu trop en expliquant comment déclarer des globales mais sans expliquer les contraintes engendrées. L'organisation de l'article est différente entre les deux langues, mais sur le fond, le discours est le même, la version anglaise est comme souvent un peu édulcorée dans sa formulation.

La version anglaise détaille certes plus de langages, mais n'est aucunement plus complète. Ni objective, d'ailleurs. Ce n'est pas parce que ça ne va pas dans tes idées que ce n'est pas objectif...

En l'occurrence, je redis ici ce que j'ai dit sur ta PdD : les inconvénients des variables globales sont NOMBREUX, et leurs "avantages" très limités (voire carrément douteux...). Parmi les principaux :

• Les "optimisations" supposées des variables globales ne sont que poudre aux yeux. Les compilateurs modernes, via l'optimisation de la pile, des registres et le LTCG (Link-Time Code Generation), sans parler de l'inlining, font mieux que 90% des cas d'utilisation de variable globale.
• La maintenabilité d'un plat de nouilles truffé de variables globales est proche du néant. Outre les effets de bords difficiles à débusquer, cela masque complètement le contexte des fonctions et donc leur impact sur le reste du système. Je ne suis pas partisan du tout du mode "100% fonctionnel" cher aux dévs Haskell ou Scheme, mais faut pas pousser non plus dans l'extrême inverse. Un "bon" programme impératif ne devrait jamais avoir plus d'une poignée de variables globales, et toutes devraient être des singletons et/ou des éléments de synchro.
• Enfin, et sûrement le point le plus important pour moi, une variable globale interdit la réentrance et donc le parallélisme. Certes, à l'époque des machines 8 bits mono-CPU, on s'en foutait allègrement, surtout quand le moindre octet de RAM comptait. Moi-même, j'écrivais à l'époque du BASIC ou de l'Assembleur Z80 truffé de globales, et j'ai fait pareil sous DOS... Quand seuls les vecteurs d'interruption sont un souci, ça n'en est pas un. Mais maintenant, nous utilisons des processeurs à plusieurs coeurs et avec processeurs logiques (j'utilise personnellement un i7 à 4 coeurs + 4 hyperthreads, qui est donc vu comme HUIT processeurs distincts par l'OS). Et pondre des programmes bousiques monothreadés de facto à cause de variables globales, c'est de l'hérésie.

Quand tu additionnes ces trois facteurs, on ne peut aboutir qu'à une seule raison justifiant l'usage massif de variables globales : la fainéantise d'un développeur, ou son incompétence. Pour te donner un exemple, j'ai récemment fait sauter des variables globales créées "pour optimiser le code". Ma solution, impliquant un changement d'algorithme, s'avère 30 à 40 fois plus rapide (!!!), est thread-safe, plus stable, plus maintenable et n'utilise plus aucune variable globale. C'est la différence entre une "optimisation" faite par un dév incompétent et celle faite par un archi logiciel...

Les rares cas "valides" d'utilisation d'une globale ne sont pas à la charge d'un dév, mais d'un architecte logiciel qui est le seul à même de définir si cela aura un impact (ou pas) sur le fonctionnement, et quelles seront les éventuelles contraintes résultantes de ce choix.

Dans le cadre de mon boulot, les cas d'utilisation des globales sont clairs : mutex et autres éléments de synchronisation, singletons, variables d'environnement, handles et structures pointant sur le hardware (notamment dans les drivers). Point.

Utiliser des globales pour autre chose n'est pas (plus) justifiable à notre époque. Ce n'est pas une question de "moralisation", c'est une question de bon sens et d'éviter de voir les p'tits jeunes sortant de l'école faire du travail de porc au point de se faire virer pour incompétence...

Ce que tu peux faire en code chez toi, pour ton usage personnel, est une chose : t'es libre. Ce qui est fait dans du code "jetable" (genre sites web JS/PHP avec zéro garantie) est, par définition, jetable et donc tu peux bosser n'importe comment si ça t'amuse, en priant pour que ton client revienne un jour. Mais tout ça, c'est du "pissage de code" : tu fais un truc et tu n'y reviens jamais, façon "Après moi, le déluge". Ce n'est pas du développement logiciel...

Quand tu fais réellement du développement logiciel, tu évites de faire des conneries avec les variables globales. C'est à dire avec des objectifs de maintenabilité et d'évolutivité, voire des contraintes de sûreté de fonctionnement, et ceci avec des produits dont la durée de vie est entre 10 et 25 ans (normes industrielles à militaires).

Si tu veux débattre sur de prétendus "bons usages" des globales, pas de problème, je t'accueille même volontiers sur ma PdD perso pour ça afin d'éviter de pourrir cette PdD. Mais il va te falloir étayer tes propos avec des exemples valides, reproductibles et pesant le pour et le contre...

Mais justifier l'usage des globales contre l'avis de 99% de la profession, à mon avis, tu vas avoir du mal...

 Mac LAK ^{[ Discuter ]} 5 novembre 2013 à 14:15 (CET)