Lorsque l'on regarde l'ensemble des actions que doit effectuer un programmeur pour faire son travail et que l'on réfléchi à ce qui pourrait être amélioré pour lui faciliter la vie, on tombe sur des petites choses qui n'ont l'air de rien et qui pourtant ont de grosses répercussions.

L'ajout d'un fichier à un projet en est une.

Lorsqu'un programmeur ajoute un fichier à un projet auquel il participe, voici généralement ce qui doit être fait :

• créer le fichier sur le disque,
• l'ajouter à la solution,
• l'ajouter au gestionnaire de version,
• l'ouvrir et en écrire le squelette.

Ces actions peuvent être regroupées. L'idéal est qu'elles le soient. L'idéal serait d'utiliser un éditeur qui ajoutera le fichier dans la solution, l'écrira au bon endroit sur le disque, l'ajoutera au gestionnaire de version et écrira un squelette.

C'est le cas lorsque j'utilise Eclipse sur un petit projet personnel en Java. Les manipulations restent un peu trop nombreuses à mon goût, mais on s'approche de l'idéal.

Cependant, dans la quasi totalité des projets auxquels j'ai pu participer ou que j'ai pu voir en action, on est loin de l'idéal :

• la création depuis l'IDE d'un fichier n'est pas reflété correctement sur le disque, ce qui oblige à créer le fichier puis à l'intégrer dans le projet (à ce propos, voir mon article sur le sujet) ;
• le connecteur entre l'IDE et le gestionnaire de version ne fonctionne pas très bien : cela implique que les programmeurs se battent contre le plugins et ne l'utilisent pas à 100% ;
• la création de squelettes de fichiers se fait généralement par copier/coller, ce qui induit parfois (et trop souvent) des erreurs de nommages ou, en C++, des erreurs de gardes d'inclusions.

En C++, le travail de création d'un fichier est au moins doublé (entêtes et sources) voire triplé (fichier séparé pour les inlines).

Si vous pratiquez le TDD, alors il faudra aussi créer le fichier de tests associé.

Quels sont les problèmes que cela entraîne ?

Si une de ces étapes est manquée, le projet ne compile plus :

• la création du ou des fichiers, bien entendu, est obligatoire.
• oublier de l'ajouter à la solution ne fera pas prendre en compte le fichier : j'ai déjà eu l'occasion de voir des fichiers compilés à part, utilisés depuis le reste du programme, archivés... sans avoir compilé le projet en entier. Cela est particulièrement vrai si un même fichier est utilisé par plusieurs projets.
• oublier de l'ajouter au dépôt : tout se passera bien jusqu'à ce que la machine de build ou un collègue reprenne le code. À noter une version voisine : les fichiers sont bien archivés, mais pas le projet modifié, erreur classique lorsque l'IDE utilisé nécessite une action supplémentaire explicite pour sauver la nouvelle version du projet.
• bien évidemment, ne rien mettre dans les fichiers n'avancera pas à grand chose. À noter qu'au moins, il n'y aura pas de soucis. Ici, le problème viendra plutôt d'un copier/coller malencontreux qui ne posera pas de problème sur la machine du programmeur mais qui pourra en poser lors du passage sur la machine (ordre de compilation différent, projet utilisé dans un autre contexte).

Toutes ces étapes prennent du temps et les risques d'erreurs sont nombreux.

Puisqu'un programmeur veut généralement développer en un minimum de temps, ces actions sont considérées comme un frein et la tentation est grande de les éviter. Mon expérience me montre que beaucoup (trop) de programmeurs se laissent aller à cette tentation.

Dans les faits, éviter de créer un nouveau fichier entraîne des conséquences en cascade :

• puisque ajouter un fichier est long et source d'erreur, s'il y a le choix de ne pas en ajouter, ne pas l'ajouter,
• de nouvelles fonctionnalités qui ont besoin d'une nouvelle classe se voient insérées dans un fichier dont la classe est connexe,
• puisque les fonctionnalités sont dans le même fichier, l'étape d'après est de s'insérer directement dans une classe existante.

Au final, moins de classes, des fichiers plus gros, des problèmes de dépendances entre système, une architecture qui s'écroule¹.

Tout cela à cause d'une simple petite chose : la création d'un fichier dans un projet n'est pas simple !

C'est un point à ne pas négliger si vous mettez en place un projet ou que vous en maintenez un. Pensez à tout ce qui peut aider un programmeur à ajouter un nouveau fichier dans le projet.

Quelle est la solution idéale ?

J'en ai soufflé en mot au début. L'idéal est bien entendu que le programmeur ait un moyen très simple (une boite de dialogue et un bouton de validation) d'ajouter un fichier dans le projet. Eclipse en mode Java s'en approche, il ne me manquerait pas grand chose².

La boite de dialogue, à partir des renseignements donnés, doit pouvoir :

• créer le ou les fichiers au bon endroit en respectant l'architecture physique du projet.
• remplir les fichiers avec le minimum : entêtes légales si vous en avez, inclusion de l'entête correspondant au source et inclusion éventuelle de pre-compiled header en C++, écriture des espaces de noms, d'un squelette de classe en fonction des choix de la boite de dialogue.
• ajouter les fichiers dans la solution ; bien entendu, si votre solution est dynamiquement générée depuis le contenu du disque, cette action est gratuite. Avec un IDE, ce n'est pas forcément évident, sauf si la méthode de création est intégrée à l'IDE, au prix d'une dépendance forte avec l'utilisation de cet IDE.
• ajouter les fichiers au gestionnaire de version ; si votre gestionnaire de version scan les nouveautés automatiquement (subversion, bazaar, git,...) cela ne demande pas d'effort, dans d'autres cas (Perforce,...) cela est une étape obligatoire pour palier aux défaillances de certains connecteurs d'IDE.

J'ai eu l'occasion de mettre en place un tel système pour un projet personnel, j'ai aussi mis en place une partie de ce système (pas d'intégration avec l'IDE utilisé) sur un projet professionnel.

Dans mon cas, le gain de temps m'a aidé à me concentrer sur l'écriture du programme plutôt que sur l'écriture des détails (et certains langages, comme le C++, sont bavards et demandent beaucoup d'à côté avant de pouvoir écrire une première ligne qui fait réellement quelque chose).

Dans le cas du projet professionnel, j'ai eu des retours positifs des utilisateurs et j'ai pu constater une chute des erreurs de copier/coller dans les en-têtes ainsi que moins de réluctance à créer un fichier par classe et au bon endroit de surcroît.

Je vous conseille donc de vous attacher à cette petite chose dans la vie d'un programmeur qu'est la création d'un nouveau fichier.