Cette article est une traduction de l’article anglais Simple tips on writing clean code.
L’auteur a lu le livre «Code propre – Un manuel d’artisanat logiciel agile» de Robert C. Martin au cours des derniers mois, parallèlement à son travail habituel.
Il a trouvé ce livre très instructif et didactique. Chaque développeur de logiciel devrait lire ce livre lui-même et essayer de mettre en œuvre les instructions lors du codage. Dans cet article, Il parle des bonnes pratiques de base que chaque développeur devrait suivre et en faire sa norme de codage.
Plus tard équivaut à jamais
Nous écrivons tous des codes compliqués, et sommes soulagés lorsque notre programme fonctionne.
Après examen du gâchis que nous avons créé, nous pensons que nous le remanierons un autre jour. La vérité est que ce jour n’arrivera jamais !
Réfléchissez-le avant de le rendre plus compliqué plus tard.
La règle du Boy Scout
“Leave the compound cleaner than you found it.”
Telle est la règle suivie par le Boy Scout of America. Cette règle s’aligne parfaitement sur notre profession. Nous devrions laisser le code un peu plus propre que nous l’avons trouvé. Le nettoyage n’a pas besoin d’être grand. Un simple changement de nom d’une fonction ou d’une variable, casse une fonction un peu plus longtemps, élimine une duplication qui fera beaucoup. N’oubliez pas que le code s’améliorant avec le temps ne se transformera pas en mauvais code.
Utiliser des noms révélateurs d’intention
Nous utilisons des noms partout dans notre code. Il faut donc faire attention lorsque vous nommez une variable, une fonction ou une classe. Trouver de bons noms prend du temps, mais cela économisera plus qu’il n’en faut. Le nom d’une variable, d’une fonction ou d’une classe devrait répondre à toutes les grandes questions. Il devrait révéler ce qu’il fait, pourquoi il existe, comment l’utiliser. Un nom ne devrait nécessiter aucun commentaire pour révéler son intention. À titre d’exemple :
int r; // rent per monthLe code précédent n’est pas un bon choix pour nommer une variable. Ici, rien ne révèle. Vous pouvez plutôt utiliser rentPerMonth comme nom de variable. Il est plus informatif et aide les autres développeurs à comprendre facilement.
Éviter la désinformation
En tant que développeur, nous devons éviter de laisser de faux indices qui obscurcissent le sens de notre code. Ne faites pas référence à un groupe de personnes en tant que personList, sauf s’il s’agit en réalité d’une liste. Utilisez plutôt personGroup ou simplement des personnes. Parce que liste a une autre signification pour les développeurs.
Faire des distinctions significatives
En tant que développeur, nous créons des problèmes lorsque nous écrivons du code uniquement pour satisfaire le compilateur ou l’interpréteur.
Par exemple, nous ne pouvons pas déclarer deux variables avec le même nom dans la même portée, nous pourrions être tentés de modifier un nom de manière arbitraire.
De plus, il n’est pas bon d’utiliser des séries de nombres pour nommer des variables. Cela a-t-il un sens si vous trouviez quelqu’un écrire int a1, a2, a3; et définir trois variables différentes ? Votre code devrait dire ce que vous vouliez faire.
Un mot par concept
Choisissez un mot pour un concept abstrait et respectez-le.
N’utilisez pas get ou fetch, récupérez comme méthodes équivalentes de différentes classes. Cela va dérouter les développeurs.
Comment vous souvenez-vous quelle méthode va avec quelle classe?
Utiliser les noms du domaine de la solution
Nous sommes des développeurs. Les personnes qui entretiendront notre code seront également des développeurs. Alors n’hésitez pas à utiliser des termes informatiques, des noms d’algorithmes ou des noms de motifs.
Ce n’est pas un bon choix de tirer tous les noms du domaine problématique alors qu’ils connaissent déjà le concept sous un nom différent.
Nommer une méthode getShortestPathUsingDijkstra() est plus pratique lorsque vous implémentez l’algorithme dijkstra. Il révèle ce qu’il fait et pourquoi il existe.
Utiliser le nom de domaine problématique
Lorsqu’il n’y a pas de « programmer-eese » pour ce que vous faites, utilisez le nom du domaine problématique.
Au moins les développeurs qui gèrent votre code peuvent demander aux experts du domaine de comprendre le sens ou l’activité. La séparation du concept de solution et du domaine du problème est très importante. Le code qui a plus à voir avec le concept de domaine problématique devrait avoir un nom tiré du domaine problématique.
La fonction devrait être petite
Les fonctions ou méthodes sont comme des blocs de construction de notre code.
En les écrivant proprement, nous pouvons rendre notre base de code plus propre.
Lorsque vous écrivez une fonction ou une méthode, vous devez suivre deux règles :
- Règle n°1 : les fonctions doivent être petites.
- Règle n°2 : les fonctions est qu’ils doivent être plus petits que ça !
Une fonction ne doit pas comporter plus de 20 à 30 lignes. Horizontalement, chaque ligne ne doit pas comporter plus de 80 caractères.
Faire une chose
Lorsque vous écrivez dans vos classes ou vos fonctions, vous devez garder à l’esprit que vous ne devez pas mettre plus d’une responsabilité sur vos épaules.
Votre classe (ou fonction) devra faire une chose, devra bien le faire et seulement le faire.
Ne pas toujours commenter
Vous pouvez penser qu’en commentant chaque fonctions et variables, vous simplifiez la vie des futurs développeurs.
En réalité, vous polluez la base de code et la rendez plus bruyante, maladroite et trompeuse !
Vous devez comprendre que rien ne peut être aussi utile qu’un commentaire bien placé, et rien ne peut encombrer un module plus que des commentaires dogmatiques et frivoles.
Rien ne peut être aussi préjudiciable qu’un vieux commentaire cruel qui propage des mensonges et de la désinformation.
Ne commentez pas où vous pouvez simplement renommer la variable (ou la fonction) de sorte qu’elle vous raconte son histoire.