Définir les standards de programmation en 4 étapes rapides

Les standards de programmation sont des règles que les développeurs d’un logiciel doivent respecter dans le formatage visuel du code. Soit elles sont définies au sein de l’équipe, soit elles sont imposées par l’acquisition d’un code existant. Peut importe, elles sont primordiales et doivent être respectées.

L’art de programmer

En développement de logiciels, nous avons la chance que le code source d’une application soit caché à l’utilisateur. Cela qui signifie que nous pouvons produire un code horrible en autant que l’utilisateur ne s’en aperçoive (tant que ça “marche”). Vrai?

Tous ceux et celles qui ont lu Clean Code de Robert C. Martin s’entendent sur la définition d’un code propre. Bien qu’il soit un personnage coloré avec des opinions tranchées, il a tout de même sensibilisé beaucoup de programmeurs à porter une attention particulière à la qualité du code qu’ils produisent. Il doit être modulaire, testable (testé!), respecter les principes de développement logiciel (SOLID, YAGNI, DRY, etc.) et tous les autres aspects du code qui en font une application à l’épreuve du futur.

Mais qu’est- ce qu’un beau code?

Réponse: Celui qui ne vous fait pas saigner des yeux lorsque vous l’ouvrez. Vous ne devriez pas être capable d’identifier un développeur par l’apparence de son code.

Étape 1: Définir les standards

Cette étape est la plus compliquée puisqu’il existe plusieurs styles dans le formatage. Il est vrai que la plupart des langages ont leurs propres conventions, mais les standards sont aussi un préférence personnelle. Il faut simplement s’assurer que toute l’équipe est d’accord, ce qui justifie que tous les développeurs doivent être impliqués dans le processus afin de facilité l’acceptation et d’assurer le respect de ces conventions. Voici quelques idées de conventions à prévoir:

• Définissez les tabulations (tabulations vs espaces, 2-4 caractères)
• Déterminez la règle de nomenclature (CamelCase, snake_case, kebab-case, etc.)
• Définissez les règles de nomenclature des classes. Par exemple, les classes de la couche métier doivent porter le suffixe Service (UserService, InvoiceService, etc.), ou encore, les implémentations de patrons conception doivent être identifiées dans le nom des classes (UserFactory, UserBuilder, UserAdapter, etc.)
• Définissez tous les préfixes des variables, attributs et paramètres le cas échéant. Par exemple, les propriétés privées d’une classe doivent être préfixées d’un trait de soulignement (private string _firstName;), ou encore, les paramètres des fonctions doivent être préfixés de d’un p (public void setName(String pName))
• Stipulez sur la position des accolades:
  
  if (true) { // Faire quelque chose } else { // Faire autre chose } // ou if (true) { // Faire quelque chose } else { // Faire autre chose } // ou if (true) { // Faire quelque chose } else { // Faire autre chose }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

  if (true) {   // Faire quelque chose } else {   // Faire autre chose }   // ou   if (true) {   // Faire quelque chose } else {   // Faire autre chose }   // ou   if (true) {   // Faire quelque chose } else {   // Faire autre chose }

• Décidez si l’utilisation du mot clé this est obligatoire pour accéder aux membres des classes.
• Décidez si les méthodes de vos classes ne retournant rien devraient plutôt retourner this pour permettre le chaînage d’opérations.
• Définissez ce qui est acceptable comme commentaires. Par exemple, interdire tous les commentaires à l’intérieur d’une fonction ou méthode.
• Prononcez-vous sur:
  • les one-liners if (param == null) return;
  • l’indentation des lignes tronquées
    
    myFactory.getInstance(Type.ONE) .doSomthing() .doSomeOtherThing() .oneLastThing(); // Ou myFactory.getInstance(Type.ONE) .doSomthing() .doSomeOtherThing() .oneLastThing();

    1 2 3 4 5 6 7 8 9 10 11

    myFactory.getInstance(Type.ONE)   .doSomthing()   .doSomeOtherThing()   .oneLastThing();   // Ou   myFactory.getInstance(Type.ONE)     .doSomthing()     .doSomeOtherThing()     .oneLastThing();

  • etc.

La limite à cet exercice est la patience de l’équipe.

Étape 2: Créer des fichiers configuration pour le formatage

De nos jours, la grande majorité des EDI offre la possibilité de configurer les règles de formatage automatique et de les exporter pour ensuite les partager avec l’équipe. Lorsque vous avez défini les standards, configurez votre EDI. Vous pourrez ensuite exporter le fichier de configuration.

Eclipse: Window > Preferences, Java > Code Style > Formatter

Visual Studio: Tools > Import and Export settings

Ceci permettra aux développeurs de l’équipe d’utiliser la fonction de formatage automatique de l’EDI.

Eclipse: ctrl + shift + f

Visual Studio: ctrl + k, ctrl + d

Étape 3: Intégrer les outils de validation

Encore une fois, votre EDI est votre meilleur allié. Les outils de validation des standards de programmation sont assez nombreux et ils sont pour la plupart assez configurables. Pour l’écosystème Java, on pense notamment à Checkstyle ou PMD. L’avantage de ces outils est qu’ils facilitent le respect des conventions par tous les développeurs de l’équipe en mettant l’accent sur ces fautes de style.

Étape 4: Respectez les standards

Avec un outil de validation du formatage, il sera tout simplement impossible pour un développeur d’archiver son code s’il ne respecte pas les standards de programmation. Il existe aussi des extensions disponibles pour les systèmes d’intégration continue afin de valider aussi le code archivé dans le gestionnaire de source.

Par contre, ne faites pas que simplement produire ces fichiers de configuration et intégrer ces outils de validation. Consolidez toutes les règles de formatage dans un document texte. Ceci permettra d’avoir un cadre de référence et facilitera l’intégration de nouveaux développeurs à l’équipe.

Bon code!

60

SHARES

Partager sur Facebook

Partager sur Twitter

Suivez-nous!

Share

Share

Share

Share

Share