Le but de ce paragraphe est de compléter les règles précédemment établies pour
chaque section d’un programme afin d’optimiser la qualité de la gestion préventive de ses
possibles failles d’exécution. Il permettra aussi de simplifier ses futures corrections ou
évolutions. Pour ce faire j’ai déterminé un certain nombre de règles et solutions qui sont les
suivantes:
- Pour tout traitement du programme aussi simple qu’il soit, un test sur son bon
déroulement sera toujours effectué et pour tous les cas d’anomalie
correspondants, la routine de gestion des erreurs sera appelée et l’exécution du
programme sera arrêtée pour le débogage.
– On limitera au maximum l’utilisation de la clause d’arrêt de l’exécution des
programmes.
– On n’imbriquera pas plus de quatre opérateurs de test conditionnel.
– Des commentaires doivent être automatiquement positionnés avant chaque
fonction afin de préciser son rôle.
– Pour toute modification d’un programme existant, le tag précisé – en général
composé des deux premières initiales du nom plus le mois ou la date de
modification – en section de signature doit apparaître à toutes les lignes faisant
l’objet d’un ajout, d’une suppression ou d’une modification.
– Lors de la modification d’un programme, toute ligne devant être supprimée sera
plutôt mise en commentaire.
– Dans la section secondaire des traitements, l’ordre des fonctions sera établi
selon leur nature c’est-à-dire par exemple que pour des accès en base de
données les fonctions réalisant une suppression seront toutes positionnées et
regroupées en-dessous de celles réalisant une insertion – ou toute autre type de
requête interagissant avec une base de donnée -.
- Dans un cartouche – ensemble des renseignements correspondant à la dernière
modification d’un programme – la dernière modification doit apparaitre en
premier.
- Pour tous les traitements liés à des fichiers, toujours comptabiliser le nombre
d’enregistrements lus, écrits et modifiés et les faire afficher en sortie
d’exécution de programme.
- Les structures de données pour fichiers de sortie seront plutôt présentes sous
formes d’inclusion d’autres fichiers contenant la description de ces structures –
ce qui facilite notamment la consultation des fichiers en sortie après exécution
du programme -.
- Tous les codes retours doivent être contrôlés quel que soit leur type.
– En tout début d’une fonction, une variable stockera l’identifiant de la fonction.
- Les nommages des fonctions devront respecter la logique de fonctionnement
attendu du programme concerné et devront être descriptifs des traitements
contenus dans ces fonctions, de même que pour les variables et structures.
– Concernant les imbrications globalement, on les limitera au maximum et on ne
dépassera pas quatre imbrications – dans la mesure du possible -.
– Les traitements faisant des accès aux bases de données seront réalisés à
l’intérieur de fonctions avec paramètres.
– On réduira au maximum les traitements directs dans une même fonction avec
ou sans paramètres.
- Pas plus de cinq traitements directs au sein d’une même fonction avec
paramètres dans la mesure du possible.