Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Un bon code source est un code qui se lit sans commentaire.
Alors je sais, on tape peut-être d'il le contraire et ça va te surprendre que je vais te dire mais...
s'il y a des commentaires, c'est peut-être qu'il est difficile à lire.
Traditionnellement, on estime que les commentaires sont un signe d'un code qui sera mieux documenté.
Et donc en sous-entendu, plus facile à maintenir.
Pour moi, il n'y a pas de meilleur doc que les tests automatiques.
Et du coup, on peut se demander, et si c'était tout l'inverse.
Pour pas rafraser feu Nicolas Boileau,
ce que l'on conçoit bien se design clairement et le code pour le dire vient aisément.
En fait, j'aurais tendance à me méfier d'un code qui est commenté.
Alors, ok, il y a des fois, des fois, le commentaire est utile.
Du genre, tu... tous les trucs légaux, les...
les trucs comme ça ou quand tu décris ton API,
que c'est à certains éléments qui vont être repris dans la doc officielle.
Ok, très bien. Mais je ne te parle pas de ça moi.
Je te parle de la lisibilité de ton code.
Tu sais, moi, j'ai connu l'époque.
Je me rappelle encore du premier ordinateur de mon père.
Il l'avait acheté pour sa société, ça valait 20 000 francs.
Et à l'époque, ça représentait une sacrée somme.
Je me rappelle, il y avait des disquettes de 512 kilos.
Autant te dire que l'octet coûte cher.
Mais ça, c'est fini.
Aujourd'hui, les octets ne coûtent pas plus cher.
Donc, pourquoi chercher l'économie de code ?
Tu peux écrire, tu peux écrire des noms de variables qui vont être longues.
Parce que si tu as besoin d'écrire des commentaires,
est-ce que tu es sûr que ton code se lit facilement ?
Est-ce que tu es sûr que ton intention est claire ?
Mais toi, toujours dans la peau de celui qui va lire ton code.
Il y a cette phrase qui me fait rire, qui dit
Imagine toujours que celui qui va lire ton code et le maintenir
est un psychopathe armé d'une tronçonneuse.
Au moins, ça motive à écrire un code plus clair.
Je vais te donner un exemple.
Est-ce que tu n'as jamais eu un problème de constante magique ?
Du genre, une assignation A égale 42.
Quand tu lis un truc comme ça, tu peux te demander
C'est quoi exactement A ?
Pourquoi 42 au fait ?
Qu'est-ce qu'avait le développeur au moment où il écrit ça ?
Là où c'est rigolo, c'est quand tu refais un guide-play
et que tu te rends compte que le mec, c'était toi en fait.
Là, tu as un petit moment de solitude.
Un architecte aurait pu écrire
Ok, je troll les architectes.
Tu verras pourquoi bientôt.
Un beau commentaire du genre, la réponse 42
c'est la réponse universelle et c'est la réponse à la question.
Ok, mais
est-ce que tu ne peux pas plutôt l'écrire directement ?
Par exemple, définir une constante
réponse universelle, qui vaut 42
est ta variable au lieu de l'appeler A, l'appeler answer, réponse
mettre en vrai mot, je t'ai dit, le octet ne coûte pas plus cher.
Et comme ça, tu te retrouves avec un code qui est auto-descriptif.
Pas besoin
pas besoin d'un commentaire.
Et toi, comment est-ce que tu
commentes ton code ?
Si tu commandes ton code, tu le fais pourquoi ?
Moi, l'enjeu fondamentalement, c'est pas de te dire que c'est mal.
C'est juste de te questionner
sur ce qui t'amène à le faire.
Personnellement, je trouve qu'il n'y a rien de mieux pour documenter son code
que d'avoir un code qui se saute au décrit
et d'avoir des bon tests automatiques qui me donnent une documentation vivante.
Je suis ouvert. Dis-moi, pourquoi tu commandes ton code ?
Est-ce que c'est juste pour faire plaisir à ton chef de projet ?
Est-ce que c'est pour poursuivre je ne sais quel chimère ?
J'ai juste envie que tu te poses la question.
Pour moi, un code bien écrit, dont l'intention est claire,
n'a pas besoin de commentaire.
Par contre, attention, la réciproque n'est pas forcément vraie.
Si tu as envie que je te donne un autre exemple
sur un cas réel d'un truc que j'ai fait il y a pas longtemps,
je t'invite à venir sur artisan-developpeur.fr
je décris ce cas que je viens de faire.
Et je suis curieux ton avis d'ailleurs.
Est-ce que tu aurais fait comme moi ? Est-ce que tu aurais fait d'une autre manière ?
Ça m'intéresse.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
Si ça t'a plu et que c'est pas déjà fait,
je t'invite à nous rejoindre sur artisan-developpeur.fr
et je te dis à bientôt.