Coding style, Ruby, et entreprise
Les objectifs d’une coding style
Appellés styles de programmation, conventions ou règles de programmation, tous ces concepts ont des objectifs communs :
- uniformiser et diffuser les (bonnes) pratiques
- éviter des erreurs classiques
- faciliter la lecture et la compréhension du code
- organiser les commentaires et la documentation
Ils sont composés de règles, de conseils et/ou de lignes directrices, qui incluent par exemple fréquemment:
- le style d’indentation, l’espacement, les alignements
- des règles de nommage
- la déclaration et l’utilisation de variables et de fonctions
- l’organisations de modules et de classes
Lors du développement d’un logiciel ou d’une application, les développeurs passent plus de temps à lire du code qu’à en écrire. Ajouter une fonctionnalité, modifier le code d’un autre développeur, corriger un bug, toutes ces tâches demandent une bonne compréhension de la logique existante. Un code bien présenté et organisé facilite grandement cette compréhension et réduit le risque d’erreur.
Différentes situations
En entreprise
Avoir un style bien établi au sein d’une équipe est très important. Le travail d’équipe et la transmission de la connaissance seront plus efficaces.
Le style au sein d’un projet doit être cohérent. Résoudre deux fois le même problème de deux manières différentes au sein du même programme augmente la charge cognitive du développeur qui doit comprendre celui-ci et représente une perte d’efficacité majeure.
Même dans le cas où un développeur travaille seul sur un projet, les projets au sein d’une entreprise peuvent être développés sur plusieurs mois, et maintenus pendant des années. Cette personne sera forcément absente un jour ou l’autre (congés, arrêts, départ de l’entreprise etc.). Il est important qu’un autre développeur puisse efficacement prendre la relève ou corriger un bug.
À terme, une coding style cohérente réduira le coût de la maintenance et la dette technique.
Pour des projets open source
Dans le cas d’un projet open source, le mieux est de suivre une norme publique et réputée (voir plus bas).
Si vous voulez participer à un projet open source, les modifications que vous allez apporter seront revues par les principaux contributeurs du projet, et ne seront acceptées que s’ils jugent la qualité suffisante.
Si vous créez votre propre projet, votre code doit être compréhensible et accessible pour que d’autre développeurs veuillent y contribuer.
Pour un projet perso
Lorsque l’on travaille seul, on peut être tenté de faire au plus rapide. À quoi bon écrire joliment si personne d’autre ne nous reliera ?
Même si vous n’avez pas besoin de vous mettre d’accord avec d’autres personnes et vous êtes totalement libres dans ce cas, avoir un style correct permet toujours d’éviter des erreurs et d’en détecter plus facilement.
Un autre fait important à avoir en tête, c’est que le “vous” d’aujourd’hui n’est pas le “vous” de demain. Au moment où vous écrivez ce code, il est clair dans votre tête. Mais si vous retombez dessus des mois plus tard, vous aurez oublié ce que vous pensiez à ce moment-là. Vous n’aurez plus la logique et le contexte en tête. Peut être même certaines de vos habitudes auront changé. À ce moment, ça sera exactement comme si le code avait été écrit par une tierce personne.
Dans la recherche scientifique
Il est fréquent aujourd’hui que des papiers de recherche utilisent des scripts et des algorithmes pour des démonstrations, calculer des statistiques ou traiter des informations (quand l’algorithme n’est pas lui-même le sujet principal du papier).
Ces scripts donnent un sentiment de “jetabilité”. Une fois les résultats obtenus, ils ne seront plus jamais exécutés. Beaucoup de scientifiques considèrent aussi dans ce cas l’informatique comme un outil pour avoir leur résultat, et non un point central de leur recherche. Se motiver à écrire de manière détaillée est difficile dans ce cas. Mais deux points restent importants :
- les algorithmes mis en place étant souvent complexe, il peut y avoir des erreurs. Et les résultats étant complexes et expérimentaux, il est rarement possible de mettre en place des tests automatisés comme avec un programme plus classique. Dans ce cas, il est important de réduire le risque d’erreur au minimum, qui pourrait entraîner des résultats faussés.
- des pairs reliront probablement la recherche. Dans ce cas, il est important qu’ils puissent facilement comprendre les programmes utilisés.
Le Ruby
Le Ruby est un langage très permissif, conçu à l’origine pour des systèmes de scripts, et prévu pour laisser une grande liberté au développeur qui l’utilise.
Là où certains langages comme le python ont la philosophie de “il y a une bonne façon de faire chaque chose”, le Ruby offre plusieurs solutions au même problème et laisse le choix au développeur. Ainsi par exemple :
- Beaucoup de caractères sont optionnels, ou peuvent être interchangés.
- Toute classe peut être facilement modifiée au cours de l’exécution du programme, et ses méthodes redéfinies.
- Le fonctionnement du programme n’est pas sensible à l’indentation.
Autrement dit, le Ruby est un excellent langage pour faire les choses comme on le souhaite. Mais cela peut devenir problématique lorsqu’il s’agit de partager son code avec une équipe. Chaque membre de l’équipe ne peut se permettre de faire les choses à sa sauce, donc avoir une norme commune devient presque une nécessité.
Quelle coding style utiliser ?
Il peut être difficile de savoir quelles sont les règles à instaurer. Le meilleur point de départ est de chercher une norme existante réputée et/ou utilisée par une organisation réputée.
La norme la plus populaire en Ruby est la Ruby Style Guide de Rubocop.
Si vous faites du Ruby, lisez là ! Puis relisez là. Plusieurs fois !
Cette norme est modifiée et peaufinée depuis des années ; elle est une bonne représentation des règles les plus établies dans les projets open source.
Bien-sûr cette norme n’est pas une parole divine ! Certaines des règles ne font pas l’unanimité et font encore débat.
Mais toutes ces règles ont des raisons d’être là. En les suivant, vous vous exposerez à peu de critiques, même de la part d’inconnus. Si vous voulez participer à un projet open source que vous ne connaissez pas bien, ces règles devraient être communément admises.
En comprenant leurs objectifs, vous pourrez ensuite décider des règles que vous souhaitez ajouter ou ignorer. Il devrait y en avoir peu, mais le contexte de votre projet ou de votre entreprise peut avoir une influence.
Certaines règles offrent plusieurs alternatives. Parfois, il est difficile de décider si tel choix est supérieur à tel autre. Dans ce cas, le plus important n’est pas le choix lui-même, mais de l’appliquer rigoureusement. Dans l’éternel débat tabs versus spaces, on ne sait qui a raison, mais il est vital que tous les membres d’une équipe utilisent le même caractère d’indentation !
Être efficace… avec style !
Je vais le dire d’emblée : vous ne voulez pas vérifier ces règles à la main.
Un espace en trop ou en moins ? Un caractère mal placé ? Au total, c’est beaucoup de règles très simples, mais casse-têtes à appliquer.
L’objectif est que la clarté du code vous aide à le comprendre, pas de se fatiguer sur la présentation.
Prenons un exemple concret. Si vous indentez votre code à la main, un bloc mal fermé pourra passer inaperçu, et l’erreur ne sera pas révélée par l’indentation. Alors que si vous disposez d’un outil pour indenter le code automatiquement, une indentation incorrecte sera directement révélatrice d’une erreur de syntaxe un peu plus haut dans le code !
Les outils qui répondent à ces besoins sont très nombreux. Tous les éditeurs populaires disposent d’options ou de plugins pour indenter et formater le code automatiquement.
En plus du formatage, des outils plus avancés, communément appelés linter, vont analyser statiquement votre code pour détecter des erreurs telles que :
- des erreurs de syntaxe
- une variable inexistante ou inutilisée
- une méthode appelée avec des paramètres incorrects
Si vous utilisez un IDE, tel que RubyMine pour le Ruby, celui-ci est nativement capable de vérifier ce genre de règles. Il dispose vraisemblablement d’options extrêmement personnalisables pour afficher un message d’erreur ou d’avertissement dans les conditions souhaitées.
Si vous utilisez un éditeur de texte plus classique, vous pourrez trouver des outils remplissant la même fonction.
Ces outils existent pour Vim, Sublime Text, Atom, Visual Studio Code, etc.
Mais pour le Ruby, un outil sort du lot. Il s’agit du célèbre et répandu RuboCop.
Il est possible de l’utiliser de plusieurs manières, selon vos préférences et votre situation :
- il peut se contenter de vérifier le code, ou le corriger automatiquement
- il peut être exécuté à la main, intégré directement à l’éditeur de texte, exécuté en git hook avant un commit, intégré à un système de CLI…
De plus, RuboCop est configuré par défaut avec les règles de la Ruby style guide présentée plus haut.
En conclusion, avec un éditeur et un environnement bien configurés, vous n’aurez pas à gérer le style à la main, et détecterez la majorité des erreurs avant même d’exécuter votre code !
Et pour les règles plus “abstraites” ?
Si vous travaillez en équipe, vous souhaiterez probablement un moment mettre en place des règles moins… triviales : suivre des design patterns, guider l’utilisation de certaines gem, certaines API, etc.
Dans ce cas, l’analyse statique et automatique du code n’est pas suffisante, mais le regard humain d’un développeur expérimenté est nécessaire.
Cela est résolu par la mise en place de code review et l’utilisation systématique de pull requests (ou merge requests). Mais ceci est une autre histoire !
