Depuis le temps que je suis dans le métier (oui je fais des phrases de vieux), j’en ai vu passer des p’tits nouveaux qui tataient du code en entreprise pour la première fois. Le milieu dans lequel nous bossons a, à ce niveau, l’avantage d’attirer des gens qui sont vraiments « à fond dedans ». Mais ce qui est un avantage peut aussi parfois devenir un inconvénient.

Tous les gens qui programment et qui me lisent connaissent bien la phase d’apprentissage d’un langage, le moment où l’on commence à savoir utiliser ce langage de manière efficace pour enfin faire des petits programmes intéressants. Il se passe alors un phénomène intéressant, on devient fier de la maitrise que l’on a. On assiste alors à un concours de celui qui arrivera à utiliser la petite astuce qui va bien pour réduire l’écriture d’un test par exemple. Ainsi en C on peut avoir le code suivant :

if( !~i ) DoSomething();

Ce qui n’est au départ qu’un jeu rigolo d’étudiant peut malheureusement porter préjudice dans le monde professionnel. En effet si l’on reprends le code ci dessus, combien de gens peuvent dire ce qu’il fait exactement ? Et même vous qui savez, combien de secondes d’effort avait vous du faire pour vous en souvenir ? Car le problème est là, quand on programme de manière démonstrative, on met dans le vent ses copains programmeurs qui bossent sur le même programme.

Ce qu’il faut comprendre lorsqu’on écrit du code en entreprise et dans une équipe, c’est que le principal destinataire de votre code ce n’est pas le compilateur qui-comprends-toutes-les-astuces mais simplement votre collègue à coté qui se gratte la tête chaque fois qu’il doit relire une de vos fonctions. Ce genre de pratiques augmentent donc, au minimum, l’effort intellectuel et dans le pire des cas induisent en erreur votre copain développeur. On peut même voir des cas plus vicieux, comme celui ci, récemment vu sur une mailling liste :

AppelleFonction( tableau[ index++ ], tableau[ index++ ], tableau[ index++ ] );

On s’épargne une ligne de index += 3 après, mais surtout on vient d’écrire du code qui d’après le standard est « indécis », l’ordre d’évaluation des paramètres d’une fonction n’étant pas fixé par la norme. Et tout cela juste pour éviter d’écrire une ligne en plus. Le programmeur vient de se mettre tout seul dans le vent sur ce coup là.

Mais au delà de simples astuces de ce goût là, on trouve des choses encore plus malfaisantes comme ces gens qui utilisent des fonctionnalités avancées du langages, qu’ils ne maitrisent pas, pour faire en moins bien ce que de la « basse technologie » aurait pu faire de manière plus élégante et efficace. J’ai ainsi récemment vu quelqu’un qui utilisait de la métaprogrammation avec sa bonne couche de template pour faire un simple « logger » d’évènements. Dans une équipe ce genre de pratique est simplement détestable.

D’ailleurs Bjarne Stroustrup l’a bien compris. Dans une vidéo récemment disponible du club informatique de l’université de Waterloo au Canada il explique comment certains mécanismes du C++ ont donné des résultats qu’il n’avait pas anticipé en matière de « je suis un ninja » et qu’il le regrettait, surtout quand il avait constaté l’utilisation sauvage et démonstrative qu’en faisait certains développeurs. Et je suis entièrement d’accord avec lui, surtout quand les gens n’ont pas l’expérience pour anticiper l’approche du ventilateur, c’est à dire le jour où ils s’exclament « ah il faut sérialiser tout ça ? ».

Ne nous méprenons pas, j’aime les gens qui ont la volonté de maitriser un langage et qui savent vraiment ce qu’ils font, mais il faut connaitre ses limites quand on écrit du code de production dans un langage remplis de pièges à con comme le C++. Parce que les gens qui ont lu « Modern C++ design » cela risque de finir comme ceux qui ont regardé les films de Bruce Lee en voulant refaire la même chose : avec un grand coup de nunchaku là où ça fait mal.