Les règles de codage, ou bonnes pratiques, ou conventions, sont un ensemble de règles visant à uniformiser le code source d’un projet.
Trop souvent oubliées par les développeurs freelance débutants, il est pourtant important de respecter certaines conventions lorsqu’on code, surtout en équipe.
Pourquoi utiliser ces règles ? Lesquelles appliquer en priorité ? Comment s’assurer de leur bonne utilisation ? C’est ce que nous allons expliquer dans cet article !
Pourquoi utiliser des normes ?
Il y a plusieurs raisons pour lesquelles ils est important d’établir et utiliser des normes de codage. Et bien qu’elles prennent plus d’importance lorsqu’on travaille en équipe, il est quand même intéressant de les mettre en place lorsqu’on travaille seul.
Voici les principales raisons qui font que l’utilisation de règles de codage est essentiel lors du développement d’un projet :
- Une meilleure lisibilité du code. En effet, appliquer ces règles permet d’écrire, et donc de pouvoir lire, du code plus facilement. C’est encore plus vrai si vous travaillez en équipe ; il faut écrire du code propre pour que vos collègues puissent vous relire. Vous n’aimeriez pas qu’on vous refile du code mal écrit, si ?
- Ce qui découle de cette première raison, c’est une meilleure maintenabilité. Un code plus lisible, plus commenté, est bien plus facile à modifier, en cas de bugs ou d’ajout de nouvelles features. C’est un gain de temps et d’énergie ;
- Un respect des spécificités du langage utilisé. Lorsque des bonnes pratiques sont établies, elles doivent respecter les spécificités du langage avec lequel vous codez. Donc, suivre ces bonnes pratiques vous permettra de moins faire d’erreurs lors de l’écriture dudit code ;
- Une meilleure gestion des performances. Les conventions de codage devraient également être pensées de manière à mieux gérer les ressources physiques d’une machine, pour optimiser le produit, que ça soit au niveau du temps de chargement que des ressources demandées.
Ce sont les principales raisons pour lesquels on devrait appliquer des normes de codage. Maintenant, voyons quelques-unes de ces conventions !
Le top 7 des normes
Bien que ces règles puissent se compter par dizaines et dépendent de chaque entreprise, j’ai sélectionné ici 7 règles qui devraient, selon moi, être utilisées partout et pour tout projet informatique.
L’organisation des fichiers et l’arborescence du projet
Il est important, dès le commencement d’un projet, de bien réfléchir et définir une arborescence propre. C’est-à-dire, une organisation des fichiers qui soit adaptée au projet, au langage et/ou aux frameworks utilisés.
Typiquement, lorsqu’on débute dans le développement, on a créé souvent tous les fichiers dans le même répertoire. Or, il est important de bien séparer les fichiers qui ont des utilités différentes.
Plus concrètement, et bien que cela dépende du langage et des outils, on pourrait voir créés des dossiers du genre :
- services : pour les fichiers contenant du code générique pouvant être utilisé ailleurs ;
- models/views/controllers : pour les projets utilisant le pattern MVC ;
- components/views : pour les projets utilisant un framework avec une approche par composant ;
- styles : pour stocker des fichiers de style type CSS.
Cette liste n’est pas complète, on peut y ajouter par exemple un dossier images, fonts, etc. Mais vous avez compris le principe : le but est ici d’éviter d’avoir des dizaines de fichiers dans le même répertoire.
Le nommage des fichiers
De même, il convient de nommer correctement ces fichiers. Souvent, cette règle dépend des entreprises et des conventions définies dans celles-ci. Mais, un des principes qu’on retrouve, c’est de nommer ces fichiers du même nom qu’on y nomme ce qui est défini.
Par exemple, pour une classe Automobile, on nommera le fichier Autmobile.extension.
Pour un service NetworkService, on appellera le fichier NetworkService.extension.
C’est une règle simple mais importante, car elle permet de comprendre l’utilité d’un fichier rien qu’en regardant son nom.
Le nommage des classes, variables, fonctions, etc.
Si on doit faire attention à la façon dont on nomme ces fichiers, il est encore plus important de faire attention à la façon dont on nomme ce qui s’y trouve : classes, fonctions, variables, etc.
Encore une fois, si ces règles vont changer d’une entreprise à l’autre, voire d’une équipe à l’autre, il y a certaines conventions qui restent plus ou moins invariables.
Déjà, il faut que le nom de ces éléments aient du sens. Évitez d’appeler un objet contenant les données d’un utilisateur myObject. user (si c’est une instance) ou userData aurait plus de sens.
Pour rentrer un peu plus dans les détails, on retrouve souvent ces règles dans le monde du codage :
- Pour une classe, on utilise du camelCase en commençant avec une majuscule : User ;
- Pour une fonction, on utilise du camelCase en commençant avec une minuscule : connectUser ;
- Idem pour une variable : connectedUser ;
- Une constante devrait s’écrire uniquement en majuscule : USER_ID.
Il y a d’autres règles, mais globalement, ce sont les plus importantes. Pour les résumer :
L’indentation du code
L’indentation consiste à ajouter des tabulations ou des espaces à ses lignes de code ; c’est une autre composante importante des règles de codage. Cette convention, bien qu’unanime, est parfois un sujet de discorde entre les développeurs.
Certains utilisent les tabulations ; d’autres des espaces. Certains préfèrent utiliser deux espaces ; d’autres quatre.
Ces règles dépendent donc de chaque développeur, équipe ou entreprise. Mais quelle qu’elle soit, avoir un code bien indenté est essentiel à sa bonne lecture et maintenabilité.
Les commentaires
Souvent oubliés par les développeurs débutants, les commentaires ont pourtant une importance primordiale. Bien qu’ils n’aient aucune valeur ajoutée au niveau de l’exécution du code – d’où leur oubli – les commentaires sont essentiels à la bonne compréhension d’un morceau de code.
Sans toutefois tomber dans l’excès et commenter chaque ligne de code, il est important de mettre des commentaires pour chaque classe, fonctions, et blocs un peu complexes.
Ça sera utile non seulement pour vos collègues qui regarderont votre code, mais aussi pour vous-même, quand vous voudrez reprendre votre code après plusieurs semaines sans avoir travaillé dessus.
Un exemple de bonne pratique en ce qui concerne les commentaires, c’est l’utilisation des commentaires Javadoc. Par exemple, utiliser cette norme pour commenter l’utilité d’une fonction revient à rajouter les lignes suivantes :
Comme on le voit, grâce à ces commentaires, on comprend parfaitement le fonctionnement de la fonction. Certains IDE permettent de générer automatiquement des commentaires Javadoc ; pour d’autres, il existe des plugins.
Taille des fichiers, fonctions
Ici, on va plus parler d’optimisation que que de vraie convention, mais la taille (en nombre de lignes) d’un fichier et d’une fonction ont également une importance.
Lorsqu’on est développeur, on n’aime pas ouvrir un fichier JavaScript de 3000 lignes ni parcourir une fonction de 400 lignes. Tout simplement parce que comprendre ce que fait cette fonction requiert de la lire entièrement. Et lire 400 lignes de code sans perdre le fil, ce n’est pas simple !
Comment faire pour les réduire ? En ce qui concerne les fonctions, il est bon, lorsqu’elles deviennent trop imposantes, de les séparer en plusieurs fonctions. Vous trouverez facilement des redondances, ou des morceaux de code exécutant des fonctions annexes, et donc bons à exporter dans de nouvelles méthodes.
Certains développeurs disent même qu’une fonction ne doit pas dépasser, en hauteur, la taille de l’écran.
En ce qui concerne les fichiers, c’est encore plus simple. Si un fichier possède 40 ou 50 fonctions, il faut en externaliser certaines. On trouvera facilement des points communs entre certaines méthodes, et on pourra ainsi créer des groupes de fonctions qu’on exportera dans de nouveaux contrôleurs, services, etc.
Les parenthèses, point-virgules, etc.
La dernière bonne pratique que nous allons aborder ici, c’est celle qui concerne l’utilisation des parenthèses, des point-virgules, sauts de ligne, etc.
Cette règle, ou cet ensemble de règles, est souvent complètement dépendante d’une entreprise, et en particulier d’un CTO.
Par exemple, l’utilisation d’espace avant et après une parenthèse, et le saut à la ligne à la fin d’une condition if. Cela est totalement arbitraire.
Ou encore, l’utilisation ou non des ‘;’ dans les langages où ils ne sont pas obligatoires, comme JavaScript ou Python. C’est encore une fois arbitraire.
Si vous travaillez dans une entreprise et que ça n’est pas défini, il serait bon d’en parler à votre CTO ou chef de projet, pour créer ces règles et ainsi uniformiser le code source d’un même projet.
Comment s’assurer de leur mise en place ?
On a vu quelques règles essentielles à un code beau, propre et maintenable. Cependant, comment être sûr qu’elles soient respectées ? Comment être sûr que chaque développeur d’une même équipe utilise les mêmes conventions ?
Il y a quelques moyens pour veiller à cela.
Via un outil d’analyse de code
Il existe, qu’ils soient intégrés ou installés à travers des plugins, des outils de lecture et d’analyse de code. Par exemple, un outil de ce genre bien connu des développeurs web, c’est ESLint.
Sous Visual Studio Code, ESLint est un plugin configurable, qui vous permet de définir des conventions, des règles, de codage. Si vous ne respectez pas ces règles, des warnings apparaîtront dans votre éditeur, voire pire, ils vous sera impossible de commit vos modifications sans les avoir corrigés… C’est peut-être un peu violent, mais c’est le moyen qu’ont trouvé certains CTO pour être sûrs que les conventions soient respectées.
Heureusement, via ce type d’outils, vous pouvez formater automatiquement votre code à chaque sauvegarde, par exemple.
Les revues de code
Plus classique mais presque aussi efficace, le respect des conventions de codage peut aussi être vérifié via des revues de code, notamment par des développeurs plus expérimentés, plus anciens dans l’entreprise, ou directement avec le CTO.
Ces revues de code, qu’elles soient effectuées ensemble ou au travers de pull requests, permettent de faire comprendre aux développeurs en quoi leur code peut être amélioré, et en quoi ils ne respectent pas les conventions établies.
Pas toujours agréables pour le développeur débutant, ces revues sont pourtant importantes dans une équipe de développement.
En conclusion
On vient de le voir, l’utilisation de normes de codage est importante. Elle permet, via le respect de diverses règles, de garder un code source propre, facile à lire et optimisé. Ce qui est essentiel, qu’on travaille seul ou en équipe, pour maintenir un projet sur le long terme.
Et vous, avez-vous des recommandations en ce qui concerne les règles de codage ? Dites-les nous en commentaire !
