Home » Livres » Automatisez votre Norme de codage

Automatisez votre Norme de codage

Il y a quelque mois, j’ai écrit un article sur le livre 97 choses que tout programmeur devrait savoir. Livre anglais très intéressant sur des bonnes pratiques à avoir.

Aujourd’hui, j’ai décidé de vous traduire un des articles qui s’intitule Automate Your Coding Standard. Cela donne en français : Automatisez votre Norme de codage. L’article d’origine (en anglais) a été écrit par Filip van Laenen.

Voici cet article :

Vous avez probablement été là aussi. Au début d’un projet, tout le monde a beaucoup de bonnes intentions – appelé «résolutions du nouveau projet». Très souvent, ces résolutions sont consignées dans les documents. Ceux sur le code se retrouvent dans la norme de codage du projet. Au cours de la réunion de lancement, le développeur principal passe par le document et, dans le meilleur des cas, tout le monde s’engage à essayer de les suivre. Une fois que le projet est en cours, cependant, ces bonnes intentions sont abandonnées, une à la fois. Lorsque le projet est finalement livré, le code ressemble à un désordre, et personne ne semble savoir comment cela s’est avéré être ainsi.

A quel moment les choses ont mal tourné ? Probablement déjà lors de la réunion de lancement. Certains membres du projet n’ont pas fait attention. D’autres n’ont pas compris le point. Pire encore, certains étaient en désaccord et prévoyaient déjà leur rébellion standard de codage. Enfin, certains ont pris le point et ont convenu, mais lorsque la pression dans le projet était trop élevée, ils devaient laisser tomber quelque chose. Le code bien formaté ne gagne pas de points avec un client qui veut plus de fonctionnalités. En outre, après une norme de codage peut être une tâche ennuyeuse si elle n’est pas automatisée. Essayez simplement d’indenter une classe désordonnée à la main pour découvrir cela par vous-même.

Mais si c’est un tel problème, pourquoi est-ce que nous voulons une norme de codage en premier lieu ? L’une des raisons de formater le code d’une manière uniforme est que personne ne peut « posséder » un morceau de code simplement en le formant à sa manière privée. Nous pouvons vouloir empêcher les développeurs d’utiliser certains antipatterns afin d’éviter certains bogues communs. Au final, une norme de codage devrait faciliter le travail dans le projet et maintenir la vitesse de développement du début à la fin. Il s’ensuit, ensuite, que tout le monde devrait s’entendre sur la norme de codage aussi, cela ne contribue pas si un développeur utilise trois espaces pour indenter le code et un autre en utilise quatre.

Il existe une foule d’outils qui peuvent être utilisés pour produire des rapports de qualité de code et pour documenter et maintenir la norme de codage, mais ce n’est pas la solution complète. Il devrait être automatisé et appliqué dans la mesure du possible. Voici quelques exemples :

  • Assurez-vous que le formatage du code fait partie du processus de construction, de sorte que tout le monde l’exécute automatiquement chaque fois qu’ils compilent le code.
  • Utilisez des outils d’analyse de code statique pour numériser le code pour les antipatternes indésirables. Si vous le trouvez, brisez la construction.
  • Apprenez à configurer ces outils afin que vous puissiez rechercher vos propres antipatterns spécifiques au projet.
  • Ne mesurez pas seulement la couverture des tests, mais vérifiez également automatiquement les résultats. Encore une fois, brisez la construction si la couverture du test est trop faible.

Essayez de le faire pour tout ce que vous considérez comme important. Vous ne pourrez pas automatiser tout ce dont vous vous intéressez vraiment. En ce qui concerne les choses que vous ne pouvez pas repérer ou résoudre automatiquement, considérez-les comme un ensemble de directives complémentaires à la norme de codage automatisée, mais acceptez le fait que vous et vos collègues ne les suivrez pas avec diligence. Enfin, la norme de codage devrait être dynamique plutôt que statique. Au fur et à mesure que le projet évolue, les besoins du projet changent, et ce qui peut sembler intelligent au début n’est pas nécessairement intelligent quelques mois plus tard.

 

Qu’en pensez-vous ?

Posté dans Livres, Programmation Web

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

  • RSS
  • Facebook
  • LinkedIn
  • Twitter
  • YouTube