Licence CC BY-NC-SA

Règles de codage — 97 choses à savoir quand on est un programmeur

Traduction et partage pour les agrumes

Publié :
Auteur :
Catégorie :
Temps de lecture estimé : 3 minutes
Introduction

Il existait, il y a de cela deux-trois ans, un site dont le nom était « 97 Things Every Programmer Should Know » mais qui aujourd’hui semble avoir disparu (bien qu’on puisse trouver le Gitbook). Ce site était composé de conseils divers et variés sur la programmation, écrits par différents programmeurs et librement diffusé sous licence Creative Commons Attribution Non Commercial Share Alike 3.0. Je me permets donc de partager ici avec la communauté de Zeste de Savoir des traductions de ces différents articles. N’hésitez pas à commenter. :)

L’article traduit aujourd’hui est Automatiser les règles de codage par Filip van Laenen.

Automatiser les règles de codage

Tu dois connaître ça. Au commencement d’un projet, tout le monde est bourré de bonnes intentions — appelle ça des « résolutions de nouveaux projets ». Bien souvent, beaucoup d’entre elles sont inscrites dans des documents, ceux dédiés aux règles de codage du projet. Lors de la réunion de démarrage, le lead developer parcourt le document et dans le meilleur des cas, tout le monde est d’accord pour suivre ces règles. Mais une fois que le projet est lancé, ces bonnes intentions sont abandonnées, une par une. Quand le projet aboutit et est livré, le code ressemble à un beau boxon et personne ne comprend comment on a pu en arriver là.

Quand est-ce que les choses ont dérapé ? Sans doute dès la réunion de démarrage. Certains membres ne faisaient pas attention. D’autres n’ont pas compris. Pire, il y en a même qui n’étaient pas d’accord et prévoyaient déjà leur rébellion contre ces normes de codage, pour imposer les leurs. Enfin, certains avaient bien compris et étaient d’accord, mais la pression était telle qu’ils ont du laisser tomber quelque chose. Eh oui, un code bien formaté ne fait pas gagner de points avec un client qui attend plus de fonctionnalités. De plus, suivre un standard peut être vraiment ennuyant si ce n’est pas automatisé. Essaye donc d’indenter une classe bordélique à la main pour tester.

Si c’est un tel problème, pourquoi s’obstiner à vouloir des standards d’abord ? Une raison qui pousse à formater le code de manière uniforme est d’empêcher que quelqu’un ne « s’approprie » un morceau de code en le formatant de la façon qu’il lui convient. On veut aussi empêcher les développeurs d’appliquer des anti-patterns, dans le but d’éviter certains bugs courants. En fait, un standard de code devrait rendre le travail sur le projet plus facile et aider à maintenir une vitesse de développement constante du début à la fin. Cela va sans dire que tout le monde doit être d’accord avec ces règles — ça ne sert à rien si un développeur utilise trois espaces pour indenter alors qu’un autre en utilise quatre.

Il existe une abondance d’outils utilisables pour produire des rapports sur la qualité du code, ainsi que pour documenter et maintenir le standard, même toute la solution ne réside pas ici. Tout cela devrait être automatisé et imposé chaque fois que possible. Voici quelques exemples.

  • Faire en sorte que le formatage du code soit partie intégrante du build, de manière à ce que n’importe qui puisse le lancer en même temps qu’une compilation.
  • Utiliser des outils statiques d’analyse de code pour chercher les anti-patterns et pour empêcher le build le cas échéant.
  • Les configurer pour scanner des anti-patterns spécifiques au projet.
  • Ne pas se contenter de mesurer la couverture de code par les tests, mais également les résultats de ces derniers. Si la couverture est trop faible, le build doit échouer.

Fais ceci pour chaque chose que tu considères comme importante. Tu ne pourras pas automatiser tout ce qui te tiens à cœur. Concernant ces derniers, considère que ce sont des règles complémentaires au standard automatisé. Accepte également que toi et tes collègues ne les suiviez pas avec autant de soin.

Enfin, le standard doit être dynamique et non statique. En même temps que le projet évolue, les besoins du projet changent et ce qui était une bonne décision pour le début du projet n’est peut-être plus nécessaire quelques mois après.

Mon mot à moi

Cela semble être une bonne idée, mais faut-il encore que les règles soient raisonnables et clairement définies. J’ai connu les revues de code avec les rejets parce que const était après et non avant le type en C++, pour la simple raison que cela ne plaisait pas au lead dev. C’est frustrant et source de mécontentement.

Pourtant, dans le même temps, la PEP 8 de Python ne m’a jamais dérangé, parce qu’elle est clairement définie et largement répandue et acceptée. Paradoxal dis-tu ? :)

Votre parole

Et vous, qu’en pensez-vous ?



5 commentaires

J’ai connu les revues de code avec les rejets parce que const était après et non avant le type en C++, pour la simple raison que cela ne plaisait pas au lead dev. C’est frustrant et source de mécontentement.

C’est justement pour éviter ce problème que l’article parle d’automatiser le formatage non ? Je ne sais pas si clang-format est bien en C++ mais en Python, Rust, Go et JS y’a des outils qui font ça bien du coup ça ne fait plus partie des considérations lors de la revue de code.

Pour Python dans mon entreprise on utilise black pour le formattage, flake8 et flake8-bugbear pour l’analyse statique et vulture pour la détection de code mort. Et on en est contents ! Je n’avais pas pensé à écrire un linter spécifique à nos librairies, mais ça pourrait être une bonne idée.

+1 -0

Je me rends compte à quel point ça change beaucoup de chose. J’hésite à choisir une techno s’il n’y a pas de linter à disposition dans le gestionnaire de paquet de mon SE.

Par-contre, je n’ai jamais utiliser d’outils statiques d’analyse de code dans un cadre autre que professionnel. Je n’en ai jamais ressenti le besoin.

ache.one                 🦹         👾                                🦊

+0 -0

J’ai connu les revues de code avec les rejets parce que const était après et non avant le type en C++, pour la simple raison que cela ne plaisait pas au lead dev. C’est frustrant et source de mécontentement.

C’est justement pour éviter ce problème que l’article parle d’automatiser le formatage non ? Je ne sais pas si clang-format est bien en C++ mais en Python, Rust, Go et JS y’a des outils qui font ça bien du coup ça ne fait plus partie des considérations lors de la revue de code.

Quentin

Oui exactement. D’où l’intérêt d’avoir un outil avec les règles bien définies et expliquées. Sinon on tombe dans le cas que je cite, à savoir le petit dictateur qui n’en fait qu’à son goût.

Cela semble être une bonne idée, mais faut-il encore que les règles soient raisonnables et clairement définies. J’ai connu les revues de code avec les rejets parce que const était après et non avant le type en C++, pour la simple raison que cela ne plaisait pas au lead dev. C’est frustrant et source de mécontentement.

J’ai été dans ce cas. J’étais le lead et je pouvais rejeter des PR pour ce genre de détail. Mais je n’étais pas le petit dictateur pour autant car le style du code imposé venait d’une autorité extérieure, nous nous en remettions en effet à la PSR-2 (guide de style pour le PHP). Du coup, il ne s’agissait pas des mes préférences personnelles en matière de style de code, mais d’un standard externe sur lequel nous nous sommes mis d’accord pour l’utiliser.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte