Dans les règles de programmation que j'ai pu croiser, il y a bien entendu le fameux « commentez votre code », dont je discutais les excès il y a 15 ans ici même. Une autre règle que j'ai pu croiser, et que je croise encore, c'est l'injonction à écire du code « explicite ».

Malheureusement, tout comme l'injonction à commenter, cette règles est bien trop floue et soumise à des inerprétations variées. Qu'est-ce que du code « explicite » ? Pas toujours ce que ceux à quoi pensent ceux qui mettent cette règle en place à mon avis.

Explicite

Ces règles étant données en anglais, c'est « explicit » dans le sens anglais qu'il faut le comprendre. Le sens est alors « clair, sans ambiguïté ». On peut y ajouter le sens de « précis ». En tant que verbe, la définition est « communicated directly in a clear and exact way », c'est-à-dire « communiqué directement de manière claire et exacte ».

Cela revient donc à dire que le code doit être clair, sans ambiguïté, précis.

Et cela demande à se poser le question : quel est le sens de ce que l'on écrit ? Qu'est-ce que l'on veut passer comme message ? Je le rappelle ici : le code est un moyen de communication entre humains avant d'être une manière de donner des instructions à une machine.

Détaillé

Dans la plupart des discussions que j'ai eu avec des personnes voulant pousser le « explicit code », il s'agissait avant tout non pas d'être précis, mais d'être détaillé. C'est-à-dire de montrer en détails le déroulement du code, avec ses détails d'implémentation.

Par exemple en évitant (pour du C++) des ranges mais en préférant des boucles avec un index explicite. En évitant tous les automasmes offerts par le langage, les portées automatiques. Tout ce qui pourrait « cacher » ce que la machine va faire « réellement ».

Deux commentaires ici : le premier est que cette idée ressemble à celle que les programmeurs des premiers temps opposaient aux langages de haut niveau des origines, préférant l'assembleur, qui était... plus « explicite ». Cette discussion es transposée à diverses époques contre chaque nouvelle abstraction.

Le deuxième commentaire est qu'au niveau d'un langage de haut niveau, ce que l'on écrit en détail n'est pas ce que la machine va faire « réellement ». Même au niveau assemleur sur un processeur moderne, on agit dans l'espace d'un contrat, d'un modèle, que le processeur garanti, mais qui reste là encore une abstraction. Et cette abstraction est nécessaire pour que les processeurs puissent avec de la marge d'optimisation.

La discussion qui s'ensuit se situe sur le niveau d'abstraction acceptable « détaillé assez bas pour que l'on comprenne ce qu'il se passe, mais pas trop bas non plus ». Et c'est ici qu'est je pense le cœur de la question. Cela fait deux fois maintenant que j'utilise le mot « abstraction », qui pourrait s'opposer à « explicite ».

Abstraction

En programmation, tout est question d'abstraction, de modèles. On abstrait un modèle physiques de signaux électriques que l'on ne peut pas humainement contrôler dans leur ensemble. Le juste niveau d'abstraction dépend de ce que l'on exprime à l'endroit où le code est écrit.

Si je suis en train d'écrire du code de bas niveau, il est très probable que je doive détailler certains aspects de l'implémentation en terme de gestion mémoire, en terme d'utilisation de variables. Si j'écris au contraire du code de haut niveau, je vais plutôt appuyer sur les concepts métiers, sur l'articulation des étapes.

Ainsi, le pseudo-code suivant est tout à fait explicite :

initialize_program()
while not finished()
    run_program()
uninitialize_program()

C'est clair, sans ambiguïté et précis. Ce n'est pas détaillé dans le fonctionnement. Mais au niveau d'abstraction où il est écrit, on sait exactement ce qu'il se passe et la manière dont le programme est structuré.

Conclusion

Lorsque l'on me parle d'écrire du code « explicite », j'ai ma petit alarme interne qui se déclenche. Est-ce qu'on ne serait pas en train de me dire d'écrire du code de même niveau de détail quelque soit le niveau d'abstraction où je me trouve ? Est-ce que cela signifie que la personne a du mal à se situer dans les abstractions ? Est-ce que c'est un mécanisme de défense pour éviter d'avoir à lire des constructions non usuelles pour cette personne ?

Je pense que la règle de l'écriture de « code explicite » est à éviter. Elle ne dit pas ce qu'elle veut dire, elle n'est en elle-même pas assez explicite pour en faire une règle applicable avec justesse. Mieux vaut la remplacer par des règles qui indiquent sans ambiguïté ce qui est attendu.

Peut-être que ces nouvelles règles ouvriront alors des débats au sein d'un groupe de travail.