Un jour en lisant mes blogs favoris, je tombe sur cet article que je vous invite à lire. Il parle de l’importance de la discipline lorsque l’on programme. Sans cela, tout part vite n’importe comment jusqu’au jour où ça devient ingérable et où les gens commencent à passer plus de temps à chercher et comprendre qu’à développer.

Il prend l’exemple des outils de source control et je ne peux qu’être d’accord avec lui… J’ai eu l’occasion de voir un bon nombre de projets utilisant des sources control et à chaque fois c’était un désastre ! Aucune discipline n’est apportée sur l’arborescence des répertoires alors que c’est la base du projet, ses fondations. Le problème principal est que personne ne s’intéresse à ce sujet, chacun met ses fichiers où il veut et s’il ne sait pas où, il va surement créer un répertoire quelque part portant son nom. Il y a ceux qui vont créer un répertoire par classe, d’autres qui vont tout mettre en vrac dans un même répertoire, après tout, on s’en fiche du moment que ça compile et que ça se lance !

Quelque chose qui m’horripile encore plus, c’est la nomenclature des noms de fichiers. Vous êtes vous déjà posé la question sur comment vous nommez vos fichiers ? En français ? En anglais ? En minuscule ? En majuscule ? Peu importe ? Pas tant que ça…

Par exemple, accepter les espaces dans les noms de fichiers peut devenir une réelle galère pour les programmeurs et peut entrainer un bon nombre de bugs.

Accepter les majuscules ne pose pas de problèmes sous Windows, car il ne fait pas la différence, mais si pour une raison quelconque vous devez faire fonctionner un outil sous Linux, alors vous allez le regretter. J’ai pu voir des projets où les règles de nommage des fichiers étaient différentes en fonction du programmeur. Il y avait des MyClass.h yourClass.h voir même des his_Class.h. Mais lors de l’inclusion dans le code avec la directive #include, les majuscules ne correspondaient pas. Ça marche très bien sous Windows mais aucune chance que ça passe sous Linux et vous êtes alors bon pour repasser sur tous les #include du code source. L’autre gros problème est pour les nouveaux programmeurs : comment peut-il s’y retrouver ? Un coup il y a un _, un autre coup non, en gros il faut apprendre par cœur le nom de chaque fichier !

Vous pouvez dire que c’est ce qui arrive fatalement quand on a une grosse équipe ou alors quand on engage des gens incompétents mais en fait non. Regardons ce projet développé par 2 programmeurs talentueux et expérimentés qui viennent de créer un studio ensemble dans le but de réaliser le projet de leurs rêves. Le projet a commencé il y a moins d’un an, et ils ne sont que 2. Ils s’amusent à afficher leurs commits alors profitons-en pour essayer de trouver les règles de nommage des fichiers et répertoires qu’ils ont mis en place :

• Règle 1: Nommage des répertoires et des code sources : une majuscule pour la première lettre de chaque mot et le reste en minuscule.


• Règle 2: Nommage des assets graphiques : tout en minuscule avec les mots séparés par des _.


• Règle 3: Nommage des répertoires des assets graphiques: c’est la que ça se complique… Il semblerait que ça soit la règle 1 pour les 2 premiers répertoires, puis la règle 2 pour les répertoires suivants.

Regardons maintenant un autre commit qu’ils ont fait sur le même projet quelques mois auparavant :



AIE. Il semblerait que ma règle 2 ne soit pas correcte, en fait il faut la modifier comme ça :

• Règle 2: Nommage des assets graphiques : tout en minuscule avec les mots séparés par des _ ou des - en fonction du sens du vent (où tout autre paramètre aléatoire).

Imaginez, ils ne sont que 2 ! des ingénieurs avec l’esprit cartésien ! et au bout de quelques mois on ne peut déjà plus décrire le nommage des fichiers/répertoires avec des règles simples. Qu’est ce que ça va devenir dans 1 an, ou quand il y aura des nouveaux dans l’équipe ?

Pourtant, il existe une règle simple qu’en général les programmeurs aiment bien : KISS (Keep It Simple, Stupid). Mais pour je ne sais quelle raison, ils ne l’appliquent que pour la programmation.

À mes débuts à Nevrax, pour le développement d’un MMORPG Windows/Linux, j’avais proposé une règle très simple suivant justement le principe KISS en partant du principe que plus les règles seront simples, plus il y a de chance que les gens la connaitront et la suivront.

• Règle 1: Nommage de tous les fichiers et tous les répertoires : uniquement des caractères alphanumériques en minuscule, les mots étant séparés par des _. Pour les geeks, on peut résumer ça en [a-z0-9_]+


• Règle 2: pas de règle 2…

On peut difficilement faire plus simple, ça évitait tous les problèmes des espaces, des majuscules et des caractères bizarres. Bien que cette règle soit simple et rabâchée depuis le début du projet, un certain nombre de programmeurs n’arrivaient pas (ou ne voulaient pas) la suivre et mettaient des noms de fichiers qui ne suivaient pas cette règle. Mais le pire a été avec les graphistes, designers, sound designers… Ils ne voulaient pas se plier à cette règle et voulaient continuer à faire comme ils faisaient avant (c’est à dire sans règles, au gré des humeurs). Pour éviter des conflits trop violents, il a été décidé de n’appliquer la règle que pour le code source et ce fut une belle erreur. Pendant des années on a du ajouter des bouts de code (rustines) dans les tools, sous Linux uniquement pour gérer des cas particuliers dans les noms fichiers et répertoires parcequ’ils ne voulaient pas se plier à cette règle simple. Il est même arrivé de devoir mettre des rustines dans des outils qui fonctionnaient parfaitement bien depuis 4 ans parce qu’une personne avait trouvé un nouveau moyen fun de nommer les répertoires qui cassait le peu de logique qui restait dans l’arborescence des datas.

Autant je comprends que les gens soient réticents à suivre des règles complexes ou qui n’ont pas de sens. Mais je ne comprends toujours pas pourquoi autant de personnes ont protesté si fortement contre une règle simple qui aurait mis de la discipline dans le source control et aurait rendu la vie tellement plus simple à tous.