Cette section est également une condition préalable au codage, comme le souligne McConnell:  » Établissez des conventions de programmation avant de commencer la programmation. Il est presque impossible de changer le code pour les faire correspondre plus tard. »

Comme indiqué vers la fin des conventions de codage, il existe différentes conventions pour différents langages de programmation, il peut donc être contre-productif d’appliquer les mêmes conventions à différents langages. Il est important de noter qu’il n’existe pas de convention de codage particulière pour un langage de programmation. Chaque organisation a une norme de codage personnalisée pour chaque type de projet logiciel. Il est donc impératif que le programmeur choisisse ou compose un ensemble particulier de directives de codage avant le début du projet logiciel. Certaines conventions de codage sont génériques et peuvent ne pas s’appliquer à tous les projets logiciels écrits avec un langage de programmation particulier.

L’utilisation de conventions de codage est particulièrement importante lorsqu’un projet implique plus d’un programmeur (il y a eu des projets avec des milliers de programmeurs). Il est beaucoup plus facile pour un programmeur de lire du code écrit par quelqu’un d’autre si tout le code suit les mêmes conventions.

Pour quelques exemples de mauvaises conventions de codage, Roedy Green fournit un long article (ironique) sur la façon de produire du code non maintenable.

CommentantEdit

En raison de restrictions de temps ou de programmeurs enthousiastes qui veulent des résultats immédiats pour leur code, les commentaires de code prennent souvent une place de choix. Les programmeurs travaillant en équipe ont trouvé préférable de laisser des commentaires car le codage suit généralement des cycles, ou plus d’une personne peut travailler sur un module particulier. Cependant, certains commentaires peuvent réduire le coût du transfert de connaissances entre les développeurs travaillant sur le même module.

Dans les premiers jours de l’informatique, une pratique de commentaire consistait à laisser une brève description des éléments suivants:

1. Nom du module
2. Objet du Module
3. Description du Module
4. Auteur original
5. Modifications
6. Auteurs qui ont modifié le code avec une description expliquant pourquoi il a été modifié.

La « description du module » doit être aussi brève que possible mais sans sacrifier la clarté et l’exhaustivité.

Cependant, les deux derniers éléments ont été en grande partie obsolètes par l’avènement des systèmes de contrôle des révisions. Les modifications et leur paternité peuvent être suivies de manière fiable en utilisant de tels outils plutôt qu’en utilisant des commentaires.

De plus, si une logique compliquée est utilisée, il est recommandé de laisser un « bloc » de commentaire près de cette partie afin qu’un autre programmeur puisse comprendre ce qui se passe exactement.

Les tests unitaires peuvent être une autre façon de montrer comment le code est destiné à être utilisé.

Conventions de nommagedit

L’utilisation de conventions de nommage appropriées est considérée comme une bonne pratique. Parfois, les programmeurs ont tendance à utiliser X1, Y1, etc. comme variables et oubliez de les remplacer par des variables significatives, provoquant la confusion.

Il est généralement considéré comme une bonne pratique d’utiliser des noms descriptifs.

Exemple : Une variable de prise de poids comme paramètre pour un camion peut être nommée TrkWeight ou TruckWeightKilograms, les TruckWeightKilograms étant préférables, car ils sont immédiatement reconnaissables. Voir Nom CamelCase des variables.

Conservez le code simpleEdit

Le code qu’un programmeur écrit doit être simple. La logique compliquée pour réaliser une chose simple devrait être réduite au minimum car le code pourrait être modifié par un autre programmeur à l’avenir. La logique mise en œuvre par un programmeur peut ne pas avoir de sens parfait pour un autre. Donc, gardez toujours le code aussi simple que possible.

Par exemple, considérons ces lignes équivalentes de code C :

if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}

et

if (hours < 24 && minutes < 60 && seconds < 60) return true;else return false;

et

return hours < 24 && minutes < 60 && seconds < 60;

La 1ère approche, qui est beaucoup plus couramment utilisée, est considérablement plus grande que la 3ème. En particulier, il consomme 5 fois plus d’espace vertical d’écran (lignes) et 97 caractères contre 52 (bien que les outils d’édition puissent réduire la différence de frappe réelle). Il est cependant discutable, ce qui est « plus simple ». Le premier a un if / then else explicite, avec une valeur de retour explicite évidemment liée à chacun; même un programmeur novice ne devrait avoir aucune difficulté à le comprendre. Le 2ème se contente de jeter les accolades, coupant la taille « verticale » de moitié avec peu de changement dans la complexité conceptuelle. Dans la plupart des langues, les instructions « return » peuvent également être ajoutées aux lignes précédentes, ce qui porte la taille « verticale » à une seule ligne de plus que la 3ème forme.

La troisième forme minimise évidemment la taille, mais peut augmenter la complexité: Il laisse implicites les valeurs « vrai » et « faux » et mélange les notions de « condition » et de « valeur de retour ». C’est probablement évident pour la plupart des programmeurs, mais un novice peut ne pas comprendre immédiatement que le résultat de l’évaluation d’une condition est en fait une valeur (de type booléen, ou son équivalent dans n’importe quel langage), et peut donc être manipulé ou renvoyé. Dans des exemples plus réalistes, le 3ème formulaire pourrait avoir des problèmes en raison de la priorité de l’opérateur, renvoyant peut-être un type inattendu, où les formulaires précédents signaleraient dans certaines langues une erreur. Ainsi, la « simplicité » n’est pas simplement une question de longueur, mais de structure logique et conceptuelle; raccourcir le code peut le rendre moins ou plus complexe.

Pour les programmes de grande envergure et de longue durée, l’utilisation d’alternatives verbeuses pourrait contribuer au ballonnement.

La compacité peut permettre aux codeurs d’afficher plus de code par page, ce qui réduit les gestes de défilement et les frappes au clavier. Compte tenu du nombre de fois où le code peut être vu lors du processus d’écriture et de maintenance, cela peut représenter une économie significative de frappes au clavier du programmeur dans la vie du code. Cela peut ne pas sembler important pour un étudiant qui apprend d’abord à programmer, mais, lors de la production et du maintien de programmes volumineux, la réduction du nombre de lignes de code permet à une plus grande partie du code de s’adapter à l’écran, une simplification mineure du code peut améliorer la productivité et réduire la fatigue des doigts, du poignet et des yeux, qui sont des problèmes médicaux courants subis par les codeurs de production et les travailleurs de l’information.

Le codage Terser accélère très légèrement la compilation, car moins de symboles doivent être traités. De plus, la 3ème approche peut permettre de comparer plus facilement des lignes de code similaires, en particulier lorsque de nombreuses constructions de ce type peuvent apparaître sur un même écran en même temps.

Enfin, les mises en page très laconiques peuvent mieux utiliser les écrans d’ordinateur à écran large modernes, en fonction de la disposition et de la configuration du moniteur. Dans le passé, les écrans étaient limités à 40 ou 80 caractères (ces limites sont apparues bien plus tôt: les manuscrits, les livres imprimés et même les parchemins utilisent depuis des millénaires des lignes assez courtes (voir par exemple la Bible de Gutenberg). Les écrans modernes peuvent facilement afficher 200 caractères ou plus, permettant des lignes extrêmement longues. La plupart des styles et normes de codage modernes n’occupent pas toute cette largeur. Ainsi, si vous utilisez une fenêtre aussi large que l’écran, beaucoup d’espace disponible est gaspillé. D’autre part, avec plusieurs fenêtres, ou en utilisant unE ou un autre outil avec diverses informations dans les volets latéraux, la largeur disponible pour le code est dans la plage familière des systèmes antérieurs.

Il convient également de noter que le système visuel humain est grandement affecté par la longueur de la ligne; les lignes très longues augmentent légèrement la vitesse de lecture, mais réduisent la compréhension et ajoutent aux erreurs de suivi oculaire. Certaines études suggèrent que les lignes plus longues se portent mieux en ligne qu’en version imprimée, mais cela ne va encore qu’à environ 10 pouces, et principalement pour la vitesse brute de lecture de la prose.

PortabilityEdit

Le code du programme ne doit pas contenir de valeurs « codées en dur » (littérales) se référant à des paramètres environnementaux, tels que des chemins de fichiers absolus, des noms de fichiers, des noms d’utilisateur, des noms d’hôte, des adresses IP, des URL, des ports UDP/TCP. Sinon, l’application ne s’exécutera pas sur un hôte dont la conception est différente de celle prévue. Un programmeur attentif peut paramétrer ces variables et les configurer pour l’environnement d’hébergement en dehors de l’application proprement dite (par exemple dans des fichiers de propriétés, sur un serveur d’applications ou même dans une base de données). Comparez le mantra d’un « point unique de définition » (SPOD).

En tant qu’extension, les ressources telles que les fichiers XML doivent également contenir des variables plutôt que des valeurs littérales, sinon l’application ne sera pas portable dans un autre environnement sans modifier les fichiers XML. Par exemple, avec les applications J2EE s’exécutant sur un serveur d’applications, de tels paramètres environnementaux peuvent être définis dans la portée de la JVM et l’application doit obtenir les valeurs à partir de là.

ScalabilityEdit

Code de conception avec l’évolutivité comme objectif de conception car très souvent dans les projets logiciels, de nouvelles fonctionnalités sont toujours ajoutées à un projet qui devient plus grand. Par conséquent, la possibilité d’ajouter de nouvelles fonctionnalités à une base de code logicielle devient une méthode inestimable dans l’écriture de logiciels

Réutilisabilityedit

La réutilisation est un objectif de conception très important dans le développement de logiciels. La réutilisation réduit les coûts de développement et réduit également le temps de développement si les composants ou modules réutilisés sont déjà testés. Très souvent, les projets logiciels commencent par une ligne de base existante qui contient le projet dans sa version antérieure et, selon le projet, de nombreux modules et composants logiciels existants sont réutilisés, ce qui réduit le temps de développement et de test, augmentant ainsi la probabilité de livrer un projet logiciel dans les délais.

Directives de construction en bref

Un aperçu général de tout ce qui précède: