Retour au Blog

Les conventions de codage

Les conventions de codage

Introduction

Tout d'abord, mettons-nous d'accord sur la notion de code de qualité, elle dépend de 6 critères :

  • l’organisation ;
  • la rapidité ;
  • la lisibilité ;
  • la concision ;
  • la non-répétition ;
  • et la cohérence des différentes méthodes.

Le meilleur moyen pour améliorer la qualité de votre code est bien sûr la veille technologique, elle vous permet de vous informer régulièrement sur les nouveautés, les conventions, les standards associés de votre langage de programmation. Et il y a bien ce qui nous intéresse aujourd’hui : les bonnes pratiques !

Il en existe un grand nombre pour chaque langage, il serait donc difficile de toutes vous les citer, mais je vais en faire une liste exhaustive avec les principales et plus efficaces à connaître.

Quel est l'intérêt ?

Le premier intérêt de ces bonnes pratiques est la maintenance. Un site web, une application ou tout autre projet n'est jamais éternel, cela signifie que quelqu'un devra intervenir pour faire des modifications sur un code qu’il n’a pas forcément écrit lui-même.

Le problème étant que chaque fonction peut être écrite de centaines de manières différentes et que chaque développeur aura ses préférences quant à la manière de coder celle-ci.

Chacun de ces codes n'est pas forcément mieux qu'un autre, mais si un code se met à répondre à une liste de conventions communes, cela permet d'améliorer sa compréhension et ainsi d'en faciliter la maintenance.

Il existe également certains logiciels de scan du code qui permettent de repérer les erreurs et de faire du code review tel que les linters (voir prochains paragraphes) qui nécessitent une écriture du code selon certaines de ces conventions.

Cela permet également de donner de l'uniformité dans le code : si plusieurs personnes travaillent sur différentes fonctions d'un projet, le code finira rapidement moins organisé et aura donc moins de lisibilité.

Or si tout le monde programme de la même façon, le code sera uniforme d’une fonction à l’autre. Les conventions permettent également d'avoir un code "validé" par l'expérience des autres développeurs, ce code aura donc moins tendance à contenir des bugs et sera par la même occasion plus facile à sécuriser.

Nomenclature et conventions associées

Parmi les conventions les plus connus et les plus simples , il y a aussi les conventions de nommage.

Il s'agit d'écrire correctement ses variables, ses méthodes, fichiers pour que le code soit lisible et compréhensible en un coup d’œil. Puis lors d'une code-review, cela permet au lecteur de passer plus de temps sur l'efficacité du code en général: gain de temps et gain d’efficacité !

Si l'on prend l'exemple du PHP et de Symfony, il y a les nomenclatures :

  • Le PascalCase (La première lettre de chaque mot sera en majuscule) est utilisé pour les classes, les interfaces et les noms des fichiers PHP
  • Le camelCase (La première lettre de chaque mot sera en majuscule sauf le premier mot qui sera lui en minuscule)est utilisé pour les fonctions, méthodes et variables
  • Le snake_case (Les mots seront en minuscule et séparés par un underscore ( _ ))est utilisé pour les noms des keys dans un tableau et pour les fichiers Sql, Yaml, Twig.
  • Le kebab-case (Les mots seront en minuscules et séparés par un tiret ( - ))est utilisé pour les images, PDF et URL.
  • Le ALL_CAPS (Les mots seront en majuscule séparé par un underscore ( _ ))pour les constantes.

Indentations

Parmi les conventions les plus connues, il y a également les indentations. L'indentation est un sujet qui donne lieu à des débats depuis très longtemps, certains programmeurs justifient que l'indentation doit être faite avec des espaces, d'autres avec des tabulations.

Chaque code possède ses spécificités, mais globalement l'indentation du code se réalise avec des tabulations de 2 ou 4 espaces selon l'environnement de travail. Si 2 personnes travaillent sur des environnements différents, il se peut que la mise en commun du code fasse apparaître des conflits. Il faut donc pour cela se mettre sur une même indentation avant le début de la programmation du projet.

La bonne indentation est celle reconnue par les bonnes pratiques du langage associé. S’il n’en existe pas, il faut prendre l’indentation associée au projet pour éviter les problèmes de compatibilité entre deux développeurs.

Il y a également les différences entre les systèmes d’exploitation :

  • Windows utilise un CR (retour du chariot en début de ligne) + un LF (descente du chariot d’une case) pour passer à la ligne
  • Linux utilise un simple LF qui lui suffit pour passer à la ligne

Il est donc important de bien penser à adapter son environnement de travail pour ne pas créer des conflits. Certains environnements de développement (IDE) fournissent la possibilité de les définir et ainsi d’éviter tous les problèmes de compatibilité possible lors du travail en équipe.

Documentations & commentaires

Une autre bonne pratique est l'écriture de commentaires durant la programmation. Cela semble avoir un effet minime sur la lisibilité, mais un bon commentaire sur une fonction compliquée fait toujours plaisir pour un lecteur cherchant à comprendre le fonctionnement. PHP possède aussi des PHPDocs, commentaires de méthodes et fonctions permettant de résumer les entrées et sorties de celles-ci et ainsi savoir en un coup d'œil l'essentiel de son utilité (à condition d'avoir des noms de variables explicites).

Méthode SOLID

Parmi les conventions de programmation, il y a également quelques méthodes ou concepts plutôt connus et importants à connaître (parfois nécessaire pour certaines entreprises) tel que la Méthode SOLID (ou ROSSI en français ).

Chaque lettre correspond à une règle de programmation qui est considérée comme bonne pratique :

S - Single responsibility principle - Responsabilité unique

Une classe, une fonction ou une méthode ne doivent avoir qu’une et une seule responsabilité soit une seule raison possible à son changement.

Cela signifie qu’il faut associer une classe à une seule responsabilité afin de rendre cette partie plus robuste : si quelque chose dans la classe venait à casser, toutes les fonctionnalités présentes seraient impactées.

Or si les classes sont séparées par avance, le problème n'impacte peu ou pas les autres tâches et sera facilement identifié.

O - Open/closed principle - Ouvert/fermé

En programmation orientée objet, ce principe impact le comportement d'une classe, il affirme qu'une classe doit être à la fois ouverte à l'extension et fermée à la modification. Elle peut donc être uniquement modifiée par extension sans modification de son code source. L'idée est qu'une fois qu'une classe a été approuvée via des revues de code, des tests unitaires et d'autres procédures de qualification, le code est considéré comme fonctionnel et sera ensuite étendu. Prenons par exemple un framework Javascript utilisant des Views (React, Angular, ...). Ces mêmes View ont une seule fonction qui est d'afficher son contenu. Une fois cela terminé, elle est fermée pour mettre en place toute autre modification envisagée.

L - Liskov Substitution Principle - Substitution de Liskov

Le principe de substitution de Liskov est un concept, une définition particulière de la notion de sous-type. Il infère qu'"une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme”

Si l'on prend l'exemple le plus connu pour visualiser le concept :Prenons une classe Rectangle, elle possède nécessairement une largeur et une hauteur, elle possède également ces dernières modulables. Maintenant prenons un Carré qui "est un" Rectangle. Il hérite donc de Rectangle et il possède quant à lui les mêmes propriétés (hauteur et largeur) mais ces propriétés sont liées entre elles (un carré a une largeur égale à sa hauteur). Cela signifie que le carré est un rectangle avec une spécificité supplémentaire. Si l'on venait donc à remplacer l'utilisation d'un Rectangle par celle d'un Carré qui est son sous-type, la partie immuable du carré risque de poser des problèmes à l'utilisation du programme.

Cela ne respecte donc pas le principe de substitution de Liskov. Cet exemple cherche à montrer que le concept d'héritage pour un programme doit être considéré comme différent de celui de notre vie quotidienne. Un carré est forcément un rectangle, mais le considérer comme tel dans un programme n'est pas une bonne idée et il faut donc réfléchir à l'utilité de l'héritage des classes dans chaque cas précis.

I - Ségrégation des interfaces

Le principe de ségrégation des interfaces est plus une bonne pratique qu'un concept, il stipule qu'aucune classe ne devrait dépendre de méthodes non utiles à son fonctionnement. Pour cela, il est donc nécessaire de diviser les interfaces volumineuses en plus petites plus spécifiques. Ainsi, l'appel à ces interfaces permet de récupérer les fonctions dont on a vraiment besoin. Cette compartimentation permet également de pouvoir, par la suite, séparer son code facilement si l'on souhaite par exemple passer par un service externe pour remplacer une méthode existante (micro-services). Cela permet également de faciliter l'entretien du projet, au lieu de modifier l'interface globale pour modifier une fonction, il suffit de chercher l'interface adaptée et de la modifier sans impacter le projet dans son ensemble.

D - Inversion des dépendances

Le principe d'inversion des dépendances fait référence à une forme spécifique de découplage des modules logiciels, le but est d'utiliser des abstractions entre une classe et sa classe parente plutôt qu'une implémentation qui, quant à elle, crée des dépendances entre les deux classes. Aucune vraie dépendance n'est ainsi créée du parent vers l'enfant par le biais d'abstractions. Cela permet aux classes et modules de niveaux supérieurs d'être réutilisables plus facilement et de pouvoir modifier les deux classes par le biais des interfaces créées.

PSR

PSR est l’abréviation de PHP Standards Recommandation. Contrairement aux conventions précédentes, il s’agit de règles spécifiques à PHP. Il s’agit de conventions et standards de programmation permettant de réunir les différentes méthodes de codage pouvant exister à travers les framework utilisés sous PHP (Symfony, Laravel, …).

Il y a une liste assez conséquente de ces standards PSR qui est en constante évolution et sera amenée à changer avec le temps. Voici donc la liste actuelle valide :

  • PSR 1 Basic Coding Standard
  • PSR 3 Logger Interface
  • PSR 4 Autoloading Standard
  • PSR 6 Caching Interface
  • PSR 7 HTTP Message Interface
  • PSR 11 Container Interface
  • PSR 12 Extended Coding Style Guide
  • PSR 13 Hypermedia Links
  • PSR 14 Event Dispatcher
  • PSR 15 HTTP Handlers
  • PSR 16 Simple Cache
  • PSR 17 HTTP Factories
  • PSR 18 HTTP Client

Linters

Ce sont des outils d'analyse du code, afin de vérifier la conformité à un PSR par exemple, la qualité du code, le respect des bonnes pratiques et conventions.Les plus connus sont SonarQube, Junit,... Mais un outil simple et utile à mettre en place est un Linter, qui va associer le code en développement à une suite de règles concernant les conventions et règles (vues dans les paragraphes précédents). Ils existent dans pratiquement tous les langages de programmation, et une fois installé, ils signalent en continu l'apparition d'erreurs et de warning accompagnant le développeur dans son écriture pour favoriser la qualité du code produit. Certains environnements de travail (IDE, éditeurs de texte) en possèdent un de base tout comme certains Framework tel que Symfony avec SensioLabs.

Les design Pattern

Les patrons de conception ou design pattern sont des modèles de développement (template) permettant de répondre en diverses occasions récurrentes du code. Établis au cours des expériences des développeurs, ces bonnes pratiques sont une référence dans le milieu, et servent également lors de la conception d'un algorithme, dans la communication entre les développeurs. Il est certes difficile de tous les retenir, mais il est important d’en avoir connaissance et de retenir le nom des plus communs afin d’améliorer la qualité du code. Quelques exemples :

  • Singleton
  • Fabrique (Factory)
  • Adaptateur (Adapter)
  • Observer
  • Composite

Conclusion

Un des objectifs des développeurs est d'améliorer sa manière de coder, et de devenir toujours plus efficient dans ses interventions. Tout ceci en maintenant un code lisible et maintenable par des tiers, et pour y répondre, toutes les conventions et méthodes énoncées ci-dessus sont devenues indispensables à tout bon codeur. Elles ne sont bien sûr pas les seules existantes, il est donc nécessaire de continuer à s’informer sur les bonnes pratiques afin de ne pas perdre en qualité.

Contactez-nous pour plus d'informations sur ce sujet.

Contactez-nous !
Je veux en savoir plus !