Règles de codage

Exemple de code avec le langage de programmation Bash

Les règles de codage sont un ensemble de règles à suivre pour uniformiser les pratiques de développement logiciel, diffuser les bonnes pratiques de développement et éviter les erreurs de développement "classiques" au sein d'un groupe de développeurs.

Les règles de codage s'articulent autour de plusieurs thèmes, les plus courants étant :

• Le nommage et l'organisation des fichiers du code source
• le style d'indentation
• Les conventions de nommage, ou règles de nommage
• Les commentaires et documentation du code source
• Recommandations sur la déclaration des variables
• Recommandations sur l'écriture des instructions, des structures de contrôle et l'usage des parenthèses dans les expressions.

Les règles de codage permettent d'assurer une meilleure lisibilité du code en utilisant le même style de codage et en évitant les constructions qui rendent le code difficile à lire ou à modifier. Elles permettent également d'éviter les erreurs liées au langage pouvant donner des résultats incorrects, pouvant entraîner des crashs systèmes ou des failles de sécurité. Certaines règles sont également liées aux buts poursuivis par le projet logiciel : portabilité, contraintes mémoires, criticité, etc.

Les règles de codage participent à la qualité logicielle. Ainsi, plus l'importance des développements est élevée, plus les besoins en règles de codages sont nécessaires. Ainsi, les normes DO-178B pour l'avionique et MISRA C pour l'automobile imposent un ensemble d'objectifs à atteindre sur le logiciel selon la criticité qui lui est attribuée. Cette criticité est déterminée par les contraintes soumises au logiciel (mémoire et CPU disponible, fiabilité, robustesse, etc.) et les risques liés à l'utilisation de ce logiciel (risques humains, risques financiers, etc.). Les règles de codage sont adaptées en conséquence. Par exemple, un logiciel embarqué disposant de peu de mémoire ne devra pas utiliser l'allocation dynamique de mémoire. Autre exemple : le logiciel redondant d'une fusée doit être développé par une équipe totalement indépendante et séparée (pas de partage de code, pas de partage de la conception, etc.) de l'équipe développant le logiciel redondé, le développement devant se faire avec les mêmes contraintes pour les deux équipes.

Il n'y a pas de règle de programmation absolue, et il appartient à chaque projet logiciel de définir celles qui lui correspondent le mieux.

Tout manquement à une règle de programmation est appelée une violation de règle.

Exemples

Exemples de règles visant à faciliter la maintenance du code :

• pour la lecture :
  • les identificateurs des constantes doivent être composés de majuscules ou de tirets bas.
  • les identificateurs des types doivent être écrits en camelCase en commençant par une lettre minuscule.
  • les identificateurs des fonctions doivent être écrits en PascalCase en commençant par une lettre majuscule.
• pour la modification :
  • en C, C++ et Java, le corps des structures de contrôle (if, for, etc.) doit toujours être entre accolades.

Exemples de règles visant à limiter les erreurs de programmation :

• en C, ne jamais lire une variable non initialisée.
• en C, ne jamais utiliser la fonction char* gets(char* tampon) (dépassement de tampon assuré lorsque la chaîne de caractère à lire est plus longue que le tampon).
• en C, ne jamais utiliser l'allocation dynamique^[réf. nécessaire] (cas d'un projet embarqué avec une ressource mémoire limitée)^[pas clair].
• en Java, ne pas utiliser l'affectation dans la condition d'un if.

Exemples de règles visant à faciliter la portabilité :

• en C et C++, deux nombres flottants ne doivent pas être comparés pour une stricte égalité.
• en C et C++, ne pas faire d'hypothèse sur l'endianness (big-endian ou little-endian) du processeur.

Vérification des règles de programmation

La vérification d'un ensemble de règles de programmation est généralement faite lors d'une revue de code ou bien d'un audit de code, manuellement ou bien automatiquement afin de trouver les violations de règles de programmation, dans le but de les corriger.

La revue de code vérifie entre autres qu'un nouveau code source est conforme aux règles de programmation avant que ce nouveau code source n'intègre la base de code existante.

L'audit de code vérifie que la base de code existante est conforme aux règles de programmation.

L'analyse statique de programmes permet de vérifier automatiquement qu'une base de code satisfait des règles de programmation. Elle permet de gagner un temps précieux lorsque le nombre de règles est important, ou lorsque la base de code est grande (nombre de lignes de code).

Logiciels liés aux règles de codage

• Logiciels indentant le code source :
  • environnement de développement intégré (existent pour de multiples langages)
  • indent (C)
  • Perltidy (Perl) [1]
• Logiciels vérifiant le respect des conventions de nommage :
  • Checkstyle, FindBugs, PMD (Java)
  • Perl-Critic (Perl) [2]
  • PyChecker pour Python
• Logiciels vérifiant les commentaires et la documentation
  • Checkstyle (Java)
  • Perl-Critic (Perl) [2]
• Logiciels détectant les erreurs de codage statiquement :
  • Les bons compilateurs et interpréteurs sont capables d'émettre des avertissements lors de l'utilisation de constructions dangereuses :
    • clang (C, C++, Objective-C)[3].
    • GCC
    • Utilisation du mode strict pour Perl
  • CodeSonar, de la société GrammaTech (C, C++)
  • FindBugs, PMD (Java)
  • LDRA, (C, C++, Ada, Java)
  • KLEE, pour les langages pouvant être compilés en bytecode LLVM.
  • PolySpace (Ada, C)
  • Pylint pour Python
  • PHPMD[4] et PHP CodeSniffer[5] pour PHP
  • Gendarme[6] pour .Net

Règles de programmation

• Java
  • Sun Coding Convention [7]
• C
  • GNU coding standards [8]
• Python
  • PEP 8 : Style Guide for Python Code[9]

Règles de programmation normalisées

• MISRA C : ensemble de règles initialement réalisées pour l'automobile et maintenant largement utilisées.
• MISRA C++ : version de MISRA C adaptée au langage C++
• DO-178B : le niveau C impose de définir des règles de programmation pour le projet.

Références

1. Site officiel de perltidy
2. Page Perl-Critic sur le CPAN
3. « Clang C Language Family Frontend for LLVM », sur llvm.org (consulté le 9 avril 2023).
4. [1]
5. [2]
6. [3]
7. (en) http://www.oracle.com/technetwork/java/codeconv-138413.html
8. (en) http://www.gnu.org/prep/standards/
9. (en) http://www.python.org/dev/peps/pep-0008/