Les règles de l’art pour l’écriture du code

Le code est un « texte » rédigé dans l’un des nombreux langages de programmation existants. Les logiciels PC, les projets de jeux vidéo et les sites web fonctionnent selon des règles contenues dans ce code, qui influence à la fois l’aspect visuel et la structure interne du produit. De plus, le code analyse une tâche donnée pour lui apporter une solution. Un « code propre » est un bon code : il est écrit simplement, sans fioritures et sans doublons. Sa structure est pensée pour être facilement lisible, tant par les humains que par les machines. Nous allons examiner ci-dessous les principales règles d’écriture qui visent à simplifier le travail des développeurs.

Principes généraux

Voici quelques principes fondamentaux pour rédiger un code de qualité :

• Clarté et lisibilité : Il est crucial d’éviter les projets trop complexes. L’objectif principal est la simplicité et la concision. Lors de la création d’un programme ou d’une application, n’oubliez pas qu’il devra être maintenu ; le code doit donc être explicite, même pour quelqu’un qui n’a pas participé à sa création initiale.
• Uniformité et structuration : Moderniser un système sans briser sa structure de base implique que l’ajout ou la modification d’un élément ne doit pas impacter négativement les autres. Il est également essentiel que chaque option ou chaque méthode ne remplisse qu’une seule tâche précise.
• Éviter les commentaires superflus : Si vous utilisez des solutions de contournement (des « hacks ») ou des méthodes inhabituelles, celles-ci doivent être accompagnées de commentaires pour expliquer le « pourquoi ». Il vaut mieux écrire une ou deux lignes de commentaire plutôt que de laisser vos collègues s’interroger sur l’utilité d’un bloc de code. Cependant, ils ne doivent pas être excessifs : on ne commente que là où c’est nécessaire.

Nommage des variables et des fonctions

Par convention, les programmes en C# utilisent le « PascalCase » pour les noms de types, les espaces de noms (namespaces) et tous les membres publics.

• Les noms d’interfaces commencent par une majuscule I.
• Tous les types d’attributs se terminent par « Attribute ».
• Les énumérations utilisent un nom au singulier pour les valeurs simples et au pluriel pour les drapeaux (flags).
• Les identifiants ne doivent pas comporter deux underscores de suite (__).
• Choisissez des noms significatifs et descriptifs pour vos variables, méthodes et classes.
• Évitez les noms composés d’une seule lettre, sauf pour les compteurs de boucles simples.
• La clarté prime sur la brièveté.
• Appliquez le « PascalCase » pour les noms de classes, de méthodes, de constantes et de champs.

Utilisation du camelCase, snake_case et autres conventions

• camelCase : Une convention où chaque mot, sauf le premier, commence par une majuscule. Utilisé pour nommer les variables et les fonctions dans de nombreux langages.
• PascalCase : Chaque mot commence par une majuscule. En règle générale, cette convention est appliquée pour nommer les classes.
• snake_case : Les mots sont séparés par un underscore (_) au lieu d’un espace. On l’utilise généralement pour les noms de champs dans les bases de données, les variables et les fonctions.
• kebab-case : Les mots sont séparés par des tirets (-). On le retrouve principalement dans les URL et le CSS. En Lisp, tous les noms sont écrits de cette manière.

Mise en forme : retraits et espaces

L’indentation peut être de 2 ou 4 espaces. Le nombre total d’espaces par retrait se configure dans votre environnement de développement (IDE). En général, on utilise 2 espaces pour rendre le code plus compact.

• Retraits horizontaux : Deux ou quatre espaces, ou l’utilisation de la touche Tabulation.
• Retraits verticaux : Utilisation de lignes vides pour diviser le code en « blocs logiques ». Même une fonction unique peut souvent être segmentée.
• Espaces : Entourez les opérateurs binaires d’un espace de chaque côté (affectations, opérateurs de comparaison, opérateurs booléens). Bien que la gestion des espaces puisse être personnalisée selon vos préférences, elle doit toujours viser à rendre le code plus cohérent.
• Alignement : Il convient d’aligner le code pour améliorer sa lisibilité. En HTML, on utilise généralement la balise de paragraphe <p> ou des blocs <div> avec des attributs d’alignement ou, mieux encore, des propriétés CSS dédiées.

Commentaires et documentation

Pour ne pas surcharger les interfaces de classes, la documentation des méthodes peut être déportée dans le fichier d’implémentation. Dans les blocs de code, il est possible de limiter le nombre de lignes ou de mots par commentaire. La documentation peut suivre le standard « Javadoc », un format pratique reconnu par la plupart des IDE et supporté par Doxygen. 

Recommandations générales de documentation :

• Documentez ce qui semble « inhabituel ».
• Donnez des exemples d’utilisation du code.
• Si une solution est atypique, expliquez les raisons de ce choix.
• Cherchez le juste milieu entre l’absence totale de documentation et le commentaire de chaque ligne.
• Ne reformulez pas ce que le code dit déjà.
• N’oubliez pas que vos commentaires seront lus par d’autres experts. Documentez pour simplifier le travail de l’équipe, pas par simple formalité.
• Le Docstring : Très proche du commentaire, il est souvent entouré de triples guillemets. Chaque fonction devrait avoir un Docstring décrivant son rôle, tandis que les commentaires internes expliquent le fonctionnement détaillé.

Éviter les « nombres magiques » et les chaînes de caractères en dur

Utilisez des noms de constantes explicites qui permettent une recherche facile. Éviter les noms d’une seule lettre pour les constantes, car ils peuvent apparaître à de nombreux endroits, rendant la recherche difficile. Deux règles d’or :

1. Utiliser des variables constantes au lieu du « hardcoding ».
2. Déporter les valeurs fixes dans des fichiers de réglages ou de configuration.

Gestion des erreurs et des exceptions

En Python, les exceptions sont gérées via des blocs try/except. L’opération susceptible de provoquer une erreur est placée dans le bloc try, et le code à exécuter en cas d’erreur se trouve dans le bloc except. Parallèlement, le logging consiste à créer des journaux (logs) pour enregistrer et structurer les données sur le fonctionnement du système. Ces fichiers permettent de surveiller les erreurs, d’analyser le code source et de transmettre des informations cruciales pour la maintenance du site web ou de l’application.

Optimisation et performance

L’optimisation repose sur trois piliers : le naturel, la performance et le temps investi.

• Le naturel : Le code doit être élégant, compact et lisible. Chaque module doit s’intégrer sans effort. Le code doit être facile à éditer, permettant d’ajouter ou de supprimer des options sans modifier lourdement le reste du programme.
• La performance : L’optimisation doit entraîner un gain de rapidité. En général, une application bien optimisée gagne entre 25 et 35 % de performance par rapport à sa version initiale.
• Le temps : L’optimisation et les réglages ne doivent prendre qu’un minimum de temps (environ 10 à 20 % du temps total de développement). Dans le cas contraire, l’investissement n’est pas rentable.

Tests de code

Dans les tests unitaires, les développeurs créent des scénarios pour vérifier le bon fonctionnement de modules isolés. Si un test échoue, les bugs sont identifiés et corrigés jusqu’à l’obtention d’un résultat satisfaisant. Pour l’automatisation des tests fonctionnels, les outils les plus populaires sont : TestComplete, Selenium, Soap UI, QTP/UFT, UI Automator, etc. Pour les petits projets, il suffit de choisir un outil, d’écrire des scripts automatisés et de préparer les données de test pour assurer une plus grande stabilité.

Versionnage et contrôle de version

Le versionnage consiste à créer et gérer plusieurs versions d’un programme possédant des fonctions similaires ou améliorées. Une version témoigne de l’évolution du produit. Les systèmes les plus connus sont : RCS, CVS, Subversion, Bazaar, Perforce, TFS et bien sûr Git. Les systèmes de contrôle de version peuvent être locaux, centralisés ou distribués (comme Git, qui utilise le stockage local et le cloud). Une historique de « commits » bien tenue est un atout majeur. Des commandes comme git blame, revert, rebase, log ou shortlog sont essentielles pour rendre l’historique des modifications compréhensible par les autres développeurs. 

Règles pour un bon message de commit :

• Laissez une ligne vide entre le titre et la description.
• Le titre ne doit pas dépasser 50 caractères.
• Commencez le titre par une majuscule.
• Ne mettez pas de point à la fin du titre.
• Utilisez l’impératif dans le titre.
• Le corps du message ne doit pas dépasser 72 caractères par ligne.
• Expliquez le « quoi » et le « pourquoi », plutôt que le « comment ».

Respect des standards du langage

La syntaxe en programmation est l’ensemble des règles définissant comment écrire le code dans un langage spécifique (agencement des commandes, symboles à utiliser, structure, etc.). Alors que la syntaxe définit la forme, la sémantique détermine la manière dont le code sera exécuté et son comportement. Un code sans fautes de syntaxe permet au compilateur ou au traducteur de fonctionner sans erreur, mais cela ne garantit pas que le programme ait un sens ou soit performant. Les standards de codage sont des conventions partagées par une équipe pour harmoniser le code, réduire la charge cognitive lors de la lecture et faciliter la maintenance. Pour un créateur de site web, suivre ces standards permet de gagner du temps et d’assurer que les outils d’analyse (parsers) traitent correctement le code. De nombreuses communautés ont déjà établi des standards : le standard GNU pour le C, ou les guides de style spécifiques pour Ruby.

Vous recherchez une entreprise pour effectuer un stage ? N’hésitez pas à nous envoyer votre CV, nous l’examinerons avec plaisir !