Les règles de la programmation structurée du code

La programmation structurée et la maintenance d'un programme de gestion d'informations dépendant du respect de certaines règles de programmation structurée. Ainsi, le programme devrait être conçu de haut en bas pour le rendre compréhensible tout en utilisant une conception modulaire. Toutefois, il est a noter que les règles ne s'appliquent pas nécessairement bien à tous les langages de programmation, ainsi dans certains langages, il peut être presque impossible à appliquer, dans d'autres langages de programmation, comme le Python par exemple, il semble indispensable. Voici donc maintenant les règles générales de la programmation structuré du code :

• Il ne devrait pas y avoir plus d'une instruction par ligne. A moins d'avoir une instruction conditionnelle ou une instruction de boucle sur la même ligne, il y a pas beaucoup de contexte, où il y a vraiment un gain important de mettre plusieurs instructions sur la même ligne.
• Le programme devrait être divisé en fonctions, en procédures, en méthodes,...
• Une fonction ne devrait avoir qu'un seul objet ou une seule tâche à accomplir.
• Les noms de variables devraient être significatif, ainsi il n'est pas qu'elle est une majuscule au début d'un mot, entre les mots et des caractères de soulignement, il faut d'abord et avant tout qu'elle veuille dire quelle chose !
• L'utilisation de variable globale devrait être éviter dans la mesure du possible, toutefois il n'est pas anormal d'avoir des variables globales, ainsi données pourrait s'adresser à l'ensemble, de plus des optimisations par souci de performance pourrait amené se genre de situation.
• Toutes les variables devraient être déclarées et initialisées idéalement au début d'une fonction.
• Des structures de données hiérarchiques devraient être utilisées pour maintenir les données et les programmes structurés.
• Avant chaque fonction, procédure ou méthode, il devrait avoir un commentaire expliquant le but ou l'objet de la fonction. De plus, chaque paramètre devrait avoir explication sur la manière de l'utiliser.
• L'indentation devrait être cohérente. Ainsi, lorsqu'il y a des blocs de codes, il devrait facilement distinguable par l'indentation.
• Les noms en majuscules devraient être utilisés pour des constantes et les minuscules pour variables ou des variables en majuscule et des constantes en minuscule. Il faut être capable de faire la différence entre une variable et une constante facilement ! Cette règle est impossible à appliquer dans des langages de programmation comme le GWBASIC par exemple.
• Des variables de boucles devraient être simple comme I, J, K, L, M et N. Cette pratique provient du langage de programmation. La lettre I indiquait la première boucle, le J la deuxième boucle et ainsi de suite. Il difficile de comprendre pour un novice pourquoi une variable "significative" doit être aussi court, mais il y a deux raisons principales, la première provient du fait que quand une variable est appliquée dans un contexte mathématique, il est préférable qu'elle soit courte, la deuxième raison tiens du fait qu'il faut distinguer plus facilement une variable ayant une porté sur un bloc de code uniquement et non l'ensemble d'une fonction, ainsi il serait beaucoup plus logique d'avoir un nom de variable court car il s'adresse qu'à une courte partie du code.
• Lorsqu'on indique des coordonnées d'écran, d'affichage ou de géométrie, on devra utiliser, des noms de variables comme x, y et z.
• Une variable d'identification ne devrait pas seulement s'appeler «id» mais indiquer à quoi elle s'applique, et devrait plutôt avoir son contexte d'inclus dans sa signification. Par exemple, pour indiquer un identificateur de famille, on devrait retrouvé «IdFamily» et non pas «Id». Si vous avez des requêtes SQL impliquant la jointure de 10 ou 20 tables, vous allez voir que cela évite de nombreuses confusions.
• La surconsommation des blocs, soit les accolades en langages de programmation C ou les «BEGIN» ou «END» en Pascal peut provoquer une forme d'incompréhension du code à cause de dissolution. Ainsi, s'il y a tellement de blocs d'accolades que programme de 10 lignes en prend 300 lignes, le code est devenu incompréhensible car il a fallu est effectuer 3 défilements d'écran pour comprendre qu'est-ce que cette fonction fait.

Les règles de la programmation structurée du code sont d'abord une ligne de conduite générale, assez souvent un idéale, mais n'amène en cas à un code parfait.

Remarques

• Ses règles ne devraient pas surpasser le gros bon sens dans un code, ainsi, il est peu pratique d'étaler une fonction mathématique dans trois fichiers différents, à l'inverse une formule trop rétrécie à la manière d'un regex de Perl pourra paraitre incompréhensible.
• Certains langages de programmation comme le PHP par exemple, propose des instructions comme «goto», lequel peut également engendré un code spaghetti, lequel peut également conduire à de la confusion de la part d'un programmeur.