Conventions de codage

Les conventions de codage sont un ensemble de directives pour un langage de programmation spécifique qui recommandent un style de programmation , des pratiques et des méthodes pour chaque aspect d'un programme écrit dans ce langage. Ces conventions couvrent généralement l'organisation des fichiers, l'indentation , les commentaires , les déclarations , les instructions , les espaces blancs , les conventions de nommage , les pratiques de programmation , les principes de programmation , les règles empiriques de programmation , les meilleures pratiques architecturales, etc. Il s'agit de directives pour la qualité structurelle des logiciels . Il est fortement recommandé aux programmeurs de logiciels de suivre ces directives pour améliorer la lisibilité de leur code source et faciliter la maintenance des logiciels . Les conventions de codage ne s'appliquent qu'aux mainteneurs humains et aux évaluateurs pairs d'un projet logiciel. Les conventions peuvent être formalisées dans un ensemble documenté de règles que toute une équipe ou une entreprise suit, ou peuvent être aussi informelles que les pratiques de codage habituelles d'un individu. Les conventions de codage ne sont pas appliquées par les compilateurs .

La réduction des coûts de maintenance des logiciels est la raison la plus souvent invoquée pour justifier le respect des conventions de codage. Dans la section d'introduction sur les conventions de code pour le langage de programmation Java, Sun Microsystems propose le raisonnement suivant :

Les conventions de code sont importantes pour les programmeurs pour plusieurs raisons :

• 40 à 80 % du coût du cycle de vie d’un logiciel est consacré à la maintenance.
• Pratiquement aucun logiciel n’est maintenu pendant toute sa durée de vie par l’auteur original.
• Les conventions de code améliorent la lisibilité du logiciel, permettant aux ingénieurs de comprendre le nouveau code plus rapidement et plus en profondeur.
• Si vous expédiez votre code source sous forme de produit, vous devez vous assurer qu'il est aussi bien emballé et propre que tout autre produit que vous créez.

L'évaluation par les pairs d'un logiciel implique souvent la lecture du code source. Ce type d'évaluation par les pairs est avant tout une activité de détection des défauts . Par définition, seul l'auteur original d'un morceau de code a lu le fichier source avant que le code ne soit soumis à l'évaluation. Le code écrit selon des directives cohérentes est plus facile à comprendre et à assimiler pour les autres évaluateurs, ce qui améliore l'efficacité du processus de détection des défauts.

Même pour l'auteur d'origine, un logiciel codé de manière cohérente facilite la maintenabilité. Rien ne garantit qu'un individu se souviendra de la raison précise pour laquelle un morceau de code particulier a été écrit d'une certaine manière longtemps après que le code a été écrit à l'origine. Les conventions de codage peuvent aider. L'utilisation cohérente d' espaces blancs améliore la lisibilité et réduit le temps nécessaire à la compréhension du logiciel.

Les conventions de codage conçues spécifiquement pour produire du code de haute qualité, puis adoptées officiellement, deviennent alors des normes de codage. Des styles spécifiques, qu'ils soient ou non communément adoptés, ne produisent pas automatiquement du code de bonne qualité.

La complexité est un facteur qui va à l’encontre de la sécurité.

La gestion de la complexité repose sur le principe de base suivant : minimiser la quantité de code écrit pendant le développement du projet. Cela permet d'éviter des travaux inutiles, qui à leur tour évitent des coûts inutiles, en amont comme en aval. En effet, s'il y a moins de code, cela représente moins de travail non seulement pour créer l'application, mais aussi pour la maintenir.

La complexité est gérée à la fois au stade de la conception (architecture du projet) et au stade du développement (en utilisant un code plus simple). Si le codage reste basique et simple, la complexité sera minimisée. Très souvent, cela signifie garder le codage aussi « physique » que possible, c'est-à-dire coder d'une manière très directe et non très abstraite. Cela produit un code optimal, facile à lire et à suivre. La complexité peut également être évitée simplement en n'utilisant pas d'outils compliqués pour des tâches simples.

Plus le code est complexe, plus il est susceptible d'être bogué, plus les bogues sont difficiles à trouver et plus il est probable qu'il y ait des bogues cachés.

Le refactoring fait référence à une activité de maintenance logicielle dans laquelle le code source est modifié pour améliorer la lisibilité ou améliorer sa structure. Les logiciels sont souvent refactorisés pour les rendre conformes aux normes de codage établies par une équipe après leur publication initiale. Tout changement qui ne modifie pas le comportement du logiciel peut être considéré comme un refactoring. Les activités de refactoring courantes consistent à modifier les noms des variables, à renommer les méthodes, à déplacer des méthodes ou des classes entières et à diviser les grandes méthodes (ou fonctions ) en plus petites.

Les méthodologies de développement logiciel agile prévoient un refactoring régulier (ou même continu), ce qui en fait une partie intégrante du processus de développement logiciel de l'équipe .

Les conventions de codage permettent aux programmeurs d'avoir des scripts ou des programmes simples dont le travail consiste à traiter le code source dans un but autre que de le compiler dans un exécutable. Il est courant de compter la taille du logiciel ( lignes de code source ) pour suivre l'avancement du projet en cours ou établir une base de référence pour les estimations de projets futurs .

Des normes de codage cohérentes peuvent, à leur tour, rendre les mesures plus cohérentes. Des balises spéciales dans les commentaires du code source sont souvent utilisées pour traiter la documentation, deux exemples notables étant javadoc et doxygen . Les outils spécifient l'utilisation d'un ensemble de balises, mais leur utilisation au sein d'un projet est déterminée par convention.

Les conventions de codage simplifient l'écriture de nouveaux logiciels dont la tâche consiste à traiter des logiciels existants. L'utilisation de l'analyse de code statique n'a cessé de croître depuis les années 1950. Une partie de la croissance de cette classe d'outils de développement provient de la maturité et de la sophistication accrues des praticiens eux-mêmes (et de l'accent moderne mis sur la sécurité ) , mais aussi de la nature des langages eux-mêmes.

Tous les praticiens du logiciel doivent faire face au problème de l'organisation et de la gestion d'un grand nombre d'instructions parfois complexes. Pour tous les projets logiciels, à l'exception des plus petits, le code source (instructions) est partitionné dans des fichiers séparés et souvent dans plusieurs répertoires . Il était naturel pour les programmeurs de rassembler des fonctions (comportements) étroitement liées dans le même fichier et de rassembler les fichiers liés dans des répertoires. Alors que le développement de logiciels est passé d' une programmation purement procédurale (comme celle trouvée dans FORTRAN ) à des constructions plus orientées objet (comme celles trouvées dans C++ ), il est devenu courant d'écrire le code d'une seule classe (publique) dans un seul fichier (la convention « une classe par fichier »). Java est allé encore plus loin : le compilateur Java renvoie une erreur s'il trouve plus d'une classe publique par fichier.

Une convention dans un langage peut être une exigence dans un autre. Les conventions de langage affectent également les fichiers sources individuels. Chaque compilateur (ou interpréteur) utilisé pour traiter le code source est unique. Les règles qu'un compilateur applique à la source créent des normes implicites. Par exemple, le code Python est indenté de manière beaucoup plus cohérente que, par exemple, Perl, car les espaces (indentation) sont en fait significatifs pour l'interpréteur. Python n'utilise pas la syntaxe d'accolades que Perl utilise pour délimiter les fonctions. Les changements d'indentation servent de délimiteurs. Tcl , qui utilise une syntaxe d'accolades similaire à Perl ou C/C++ pour délimiter les fonctions, n'autorise pas ce qui suit, ce qui semble assez raisonnable pour un programmeur C :

définir i = 0 tant que { $i < 10 } { met "$i au carré = [expr $i*$i]" incr i }

La raison est qu'en Tcl, les accolades ne servent pas uniquement à délimiter des fonctions comme en C ou en Java. Plus généralement, les accolades servent à regrouper des mots en un seul argument. En Tcl, le mot while prend deux arguments, une condition et une action . Dans l'exemple ci-dessus, while n'a pas son deuxième argument, son action (car Tcl utilise également le caractère de nouvelle ligne pour délimiter la fin d'une commande).

Il existe un grand nombre de conventions de codage ; consultez la section Style de codage pour de nombreux exemples et discussions. Les conventions de codage courantes peuvent couvrir les domaines suivants :

• Conventions de commentaires
• Conventions de style d'indentation
• Conventions de longueur de ligne
• Conventions de dénomination
• Pratiques de programmation
• Principes de programmation
• Conventions de style de programmation

Les normes de codage incluent la norme de codage CERT C , MISRA C et High Integrity C++ .