Regrouper les variables globales en C ?

Les gens changent. J’ai changé. J’ai envie de dire « heureusement ! ». J’ai toujours été avide d’apprendre et j’estime avoir beaucoup progressé, au moins avoir changé et avoir réfléchi depuis que je suis sorti d’école. Aux débuts de ce blog, j’ai écrit un article sur les variables globales : Regrouper les variables globales dans un seul fichier header en C. Quand j’ai relu cet article en Novembre 2013, ça m’a donné envie de vomir ! J’avais vraiment écrit ça ?… Quelques jours plus tard, je suis arrivé au chapitre sur les variables globales dans le livre Code Complet de Steve McConnell et ça a été un signe : il fallait corriger le tir. Lors que j’avais publié cet article, mon camarade Insalien Florent avait commenté l’article et si je comprenais ces arguments, je n’en comprenais pas la portée et l’importance. En novembre 2013, j’avais commencé l’écriture du présent article,une sorte de mea culpa et pour expliquer pourquoi l’article cité précédemment est juste tout ce qu’il ne faut pas faire. J’ai mis quelques mois à finalement finir cet article car la motivation m’a manqué et je l’ai finalement oublié.

Les raisons évoquées ci-dessous ne se veulent pas exhaustives. Je suis sûr qu’on peut en trouver d’autres…

1) La forme de la technique du regroupement est mauvaise. Admettons qu’on souhaite toujours regrouper, ce qui est mauvais, il faudrait faire un fichier C avec les définitions des variables et un fichier d’en-tête avec les déclarations externes. Ainsi, on l’inclut où on veut, comme on veut, et on n’a besoin d’un #define tout moche à un et un seul endroit sous peine d’avoir des multiples références aux variables.

2) N’exposer que ce qui est nécessaire. Ici, chaque module où ressources.h est inclus connait l’ensemble des variables globales alors qu’il n’a peut-être besoin que d’une ou deux de ces variables. C’est totalement inutile de lui donner connaissances de ces autres variables globales. Il n’en n’a pas besoin et pourrait les modifier par erreur.

3) On ne devrait pas se baser sur l’ordre des inclusions. J’ai travaillé récemment sur un projet C fourni par un client et il y a avait un fichier similaire, qui s’appelait peut-être bien globals.h. Problème : il fallait forcément l’inclure en premier dans un fichier, car les autres fichiers d’en-tête en avaient besoin pour s’inclure sans erreur. On rejoint le point 1 et les commentaires de Florent.

4) Les variables globales, c’est mal. Depuis 1 an et demi, je travaille chez IS2T. S’il y a une chose que j’ai appris de la programmation orientée objet (POO) que j’y pratique, c’est d’encapsuler ce qui change et de ne pas exposer sa structure interne. Cela vaut aussi pour les langages non POO. Toujours passer par des getters et des setters plutôt que par des variables globales ou des champs publiques. Ça peut paraître la même chose mais non. Si je souhaite faire une section critique pour accéder à une variable, je modifie mes getters et mes setters. Si je décide de changer le type de ma variable globale, je dois retrouver et adapter tous les endroits où elle est utilisée. Avec des getters et setters, je peux maintenir une rétro-compatibilité et fournir en plus de nouveaux getters et setters pour la nouvelle représentation si je le souhaite dans mon API.

5) Enfin, et ce dernier point se suffit à lui même et c’est lui qui aujourd’hui m’a fait terminer cet article : regrouper les variables globales, ou même tout simplement regrouper n’importe quoi, c’est tuer la modularité. Je suis actuellement en déplacement chez un client pour le former aux technologies d’IS2T. Je passe ma journée à expliquer qu’il faut être modulaire, faiblement coupler son code métier aux spécificités matérielles, faiblement coupler ses modules métiers entre eux, pour mettre la réutilisation d’un module dans un autre projet, pour le rendre plus portable sur une cible différente. Une unique en-tête avec tout dedans est totalement contraire à cette bonne parole que je prêche. Chaque module doit être autant que possible indépendant des autres. Si j’ai un fichier C qui inclue le fameux resources.h et que je souhaite un jour le réutiliser dans un deuxième projet, je fais quoi de toutes les autres variables globales ? Hein ?

Regrouper, a fortiori des variables globales, dans un seul fichier, c’est mal. Ne le faites pas. Jamais.

Mise à jour du 2 mars 2017 : je rajoute un 6e point.

6) Si vous modifiez un header, vous devez alors recompiler tous les fichiers source qui incluent ce fichier, que ce soit directement ou indirectement (c’est-à-dire les fichiers source qui incluent un header qui inclue ce header). Même si vous ne faites que corriger une typo dans un commentaire. Ainsi, quand vous avez un header qui est inclus partout, vous allez recompiler l’intégralité de votre projet aussi souvent que vous le modifierez…..ce qui risque d’arriver souvent.

Publicités

2 Réponses

  1. Pingback: Regrouper les variables globales dans un seul fichier header en C | Pierre Gradot

  2. Pingback: Vérification de types à l’édition des liens | Pierre Gradot

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s