Dimitri Dumont

Freelance front-end developer

15 novembre 2020

Clean code, écrire du code de qualité - Partie 2

Bonjour, je suis Dimitri Dumont, développeur front-end freelance. Je suis passionné par les notions qui tournent autour du “software craftsmanship”.

J’ai récemment acheté le livre Clean Code — A Handbook of Agile Software Craftsmanship de Robert C. Martin (ou Uncle Bob). J’ai décidé de partager mes notes personnelles prises durant sa lecture.

Si vous souhaitez lire la première partie, qui est l’introduction de la notion de “clean code”, vous pouvez la retrouver ici : cliquez-ici

L’objectif de cette deuxième partie est de comprendre pourquoi il faut utiliser des noms significatifs et comment le faire. En tant que développeur, nous nommons constamment des variables, des fonctions, des classes, des objets, etc. Étant donné que nous le faisons très souvent et dans chaque projet, il est important de faire attention aux noms que nous utilisons.

Pour commencer, il faut savoir que choisir un bon nom pour une variable, une classe ou tout autre élément dans un programme prend du temps. Il ne faut donc pas avoir peur de renommer vos variables durant votre projet lorsque vous en trouvez des meilleurs. Avec les IDE, vous pouvez très facilement renommer une variable sans vous soucier de son utilisation, l’IDE se chargera de la renommer lors de ses importations et de ses utilisations.

L’une des premières règles sur le nommage, c’est que le nom doit révéler ce que fait une fonction ou à quoi sert une variable.

Prenons un exemple, si vous souhaitez avoir une variable qui correspond à un utilisateur :

Maintenant, renommons cette variable pour qu’on puisse comprendre plus facilement son usage :

Ainsi, lorsque vous reviendrez sur cette partie de code ou lorsqu’un autre développeur travaillera dessus, il ne perdra pas de temps à comprendre cette variable.

Qu’est-ce que la déformation ? Imaginons que vous souhaitez déclarer une variable qui représente un groupe d’utilisateurs, il peut être tentant de nommer cette variable userList. Le problème ici, c’est qu’en utilisant le mot List vous pouvez laisser croire que cette variable est une liste au sens développement. On peut donc supposer que cette variable est un tableau par exemple, alors qu’au final, elle peut très bien être un objet qui contient des utilisateurs.

La solution est d’utiliser un nom qui n’a pas de signification sur son type : userGroup ou users.

Dans le livre, Robert C. Martin prend aussi l’exemple du 0. En fonction des polices utilisées par votre IDE, le zéro peut être interprété comme un o. La solution est tout simplement de renommer la variable 0 en zero.

Vous ne devez pas avoir des noms qui se ressemblent. Par exemple pour des fonctions, évitez ça : getActiveCustomer(), getActiveCustomers(), getCustomerData() N’utilisez pas des termes techniques : variable, table, list, etc.

Les noms que vous choisissez dans vos programmes seront prononcés régulièrement, que ce soit par vous ou par vos collègues. Utilisez donc des noms facilement prononçables comme meetingDate, meetingCustomer plutôt que mDt, mCtm.

Les noms qui sont composés d’uniquement un caractère, comme par exemple i, u et 0 sont difficilement trouvables au milieu du code. Uncle Bob conseille d’utiliser ce type de nom (un seul caractère) uniquement dans les petites méthodes. Vous pouvez garder par exemple le caractère i pour représenter l’index dans une boucle. Mais excepté ce cas précis, évitez les noms composés d’un seul caractère.

Il est inutile de perdre du temps à comprendre le nom de la variable, d’une fonction ou d’une classe. Choisissez des noms explicites et simples.

Uncle Bob nomme le fait de nommer un élément dans le code avec son type, par exemple addressString comme dangereux pour la lecture, pour changer le nom plus tard et pour changer tout simplement l’élément.

Si vous développez en JavaScript par exemple, il peut être intéressant d’utiliser TypeScript pour typer vos objets et vos variables afin d’éviter ce genre de noms.

Lorsque vous travaillez sur un projet, il est intéressant d’utiliser les mêmes termes et mots que les autres. Cela évitera aux autres développeurs de perdre du temps à essayer de comprendre le nom de chaque élément dans le code et ainsi de leur utilité. Vous pouvez pour cela, utilisez les termes du secteur du projet. Par exemple, si vous travaillez sur une application de gestion de rendez-vous, vous pouvez utiliser les termes suivants : meeting, appointment, contributor.

Les noms des objets et des classes doivent être des noms ou des groupes de noms. Exemple : User, Customer, Meeting, Account, Car.

Les noms des fonctions doivent contenir un verbe. Exemple : getActiveUsers(), deleteArticle(), updateAddress().

Lorsque vous choisissiez un mot pour un concept. Si par exemple pour récupérer des utilisateurs vous choisissiez le mot get pour la fonction getUsers(), n’utilisez pas le mot retrieve ou fetch dans d’autres noms.

Si vous devez utiliser le même mot pour deux éléments différents, alors choisissez deux mots différents car ce ne sont pas les mêmes éléments.

Pour conclure sur cette deuxième partie, qui correspond au deuxième chapitre du livre Clean Code — A Handbook of Agile Software Craftsmanship de Robert C. Martin, le choix des noms que vous utilisez dans votre code est très important.

Plus un nom sera simple, explicite et réfléchi, plus vous gagnerez du temps à vous relire et à comprendre l’utilité d’une fonction, d’une variable ou d’une classe.

L’une des différences entre un développeur intelligent et un développeur professionnel c’est que le professionnel comprend que la clarté est maitresse. Les professionnels utilisent leurs forces pour écrire du code de qualité que les autres peuvent comprendre. Robert C. Martin — A Handbook for Agile Software Craftsmanship