Variables de configuration

Au cours du développement d’un outil informatique, il est commun d’avoir besoin de spécifier des informations de configuration de l’outil en question. De la sorte, l’emploi de “variables de configuration” est tout indiqué. Il existe cependant quelques règles simples à respecter afin de rester dans un esprit de clean code lors de l’utilisation de ce type de variables.

Commençons par introduire les variables internes. Il s’agit là de variables qui sont propres au fonctionnement du logiciel, qui sont souvent positionnées dans des dossiers “enfouis” et ne sont pas à destination de l’utilisateur final. Le but de leur existence est donc l’inverse des variables “externes” qui sont, elles, modifiables et souvent dépendantes de l’environnement sur lequel nous nous trouvons (ex: base de données pour gérer la connexion, Serveur SMTP pour gérer l’envoi de mails, etc…). Ces variables externes sont quant à elles très généralement placées à la racine du projet pour pouvoir y accéder facilement et pour pouvoir modifier rapidement leur valeur.

La première bonne pratique concernant ces variables de configuration réside dans l’utilisation de variables d’environnement lorsque cela est possible. L’utilisation de telles variables va permettre de décorréler complètement l’exploitation de leur valeur au sein du code, et la possibilité de modifier lesdites valeurs grâce au code. En d’autres termes, vous allez pouvoir accroître la sécurité de votre code en faisant en sorte que celui-ci ignore purement et simplement les valeurs de ces variables d’environnements. De la sorte, vous serez dans l’incapacité (via votre code) de modifier les valeurs et créerez une protection supplémentaire.

La deuxième bonne pratique à un impact un peu moindre, mais reste néanmoins importante : utilisez des constantes lorsque votre langage de programmation le permet. La constante est - dans certains langages - non modifiable une fois le programme lancé. Cela signifie que vous créerez une barrière supplémentaire qui vous assurera la non-modification des informations contenues dans ces variables d’environnement.

La troisième bonne pratique est la documentation ! Si celle-ci fait partie intégrante du clean code (ne dit-on pas “un bon code est un code bien documenté” ?), elle est également primordiale pour toute variable de configuration. Elle doit donc a minima contenir :

• Une description de ce qu’elle contient : pourquoi existe-t-elle ? Quel impact a-t-elle sur le logiciel ?
• Une valeur initiale (par défaut) : ces variables sont par définition des variables de configuration. Que se passerait-il si l’utilisateur venait a la modifier sans se souvenir de la valeur initiale (et donc sans la possibilité de réinitialiser la valeur de la variable en cas de souci) ?
• Quelles sont ses limites et ses spécifications ? Existe-t-il une valeur minimale en dessous de laquelle le logiciel ne fonctionnera plus ? Une valeur maximale ? Un nombre de caractères maximum ?

Enfin, même si certaines règles peuvent paraître évidentes à respecter, prenons tout de même le temps de les rappeler. Ne modifiez jamais programmatiquement les valeurs de ces variables de configuration. Respectez systématiquement les conventions de nommage des langages utilisés comme vous le feriez pour n’importe quelle variable. Documentez enfin a minima dans un fichier readme l’emplacement des fichiers de configuration existants au sein d’un projet, et surtout pour les variables externes !