Centraliser les déclarations

pour la procédure principale

Dans chaque type de définition, alphabétisez les déclarations. Au lieu d’utiliser des littéraux, les déclarer comme constantes nommées.Cette pratique aide à documenter le code et facilite sa maintenance. Cette règle souffre d’une exception évidente : l’utilisation autorisée de 0 et 1 quand ils sont parfaitement clairs dans le contexte d’une instruction. Par exemple, si vous avez l’intention d’initialiser un champ d’accumulateur ou d’incrémenter un compteur, vous pouvez parfaitement utiliser un 0 ou 1 codé en dur dans le source.

Mettre en retrait les noms des éléments de données pour améliorer la lisibilité et documenter les structures de données.Contrairement à beaucoup d’autres entrées RPG, le nom d’un élément défini n’a pas besoin d’être justifié à gauche dans les Dspecs (figure 2). Profitez-en pour documenter le code plus clairement.

Pour améliorer la lisibilité, laissez toujours la colonne 7 vierge. (La même règle s’applique aux H-specs – laissez la colonne 7 vierge.)

Utiliser la notation en longueur au lieu de la notation positionnelle dans les déclarations de structures de données.Les D-specs permettent de coder les champs soit avec des positions « de » et « à » spécifiques, soit simplement avec la longueur du champ. Pour éviter toute confusion et mieux documenter le champ, utilisez la notation en longueur de manière homogène. Par exemple, codez :

D RtnCode DS
D PackedNbr 15P 5

au lieu de :

N’utilisez la notation positionnelle que quand la position réelle dans une structure de données est importante. Par exemple, lors du codage de la structure de données d’état du programme, de la structure de données d’information de fichier, ou de la structure de données de retour d’une API, vous utiliseriez la notation positionnelle si votre programme ignorait certaines positions conduisant à un champ ou entre des champs. Il vaut mieux utiliser la notation positionnelle que des variables de « remplissage » inutiles avec la notation en longueur. Cependant, même avec la notation positionnelle, songez à recouvrir la variable déclarée positionnellement par une autre variable qui est déclarée avec la notation en longueur, de manière à mieux documenter la variable, comme dans la figure 3.

Lors de la définition des champs en chevauchement, utilisez le mot-clé OVERLAY au lieu de la notation positionnelle. Ce mot-clé lie explicitement la déclaration d’une variable « enfant » à celle de son « parent ». Non seulement OVERLAY documente cette relation, mais si le parent est déplacé ailleurs dans le code du programme, l’enfant suivra.

Eviter les matrices à la compilation.Lorsque vous décomposez un programme en ses procédures individuelles, il est utile d’avoir tous les morceaux de code associés physiquement et logiquement autonomes. Le coding de la matrice de compilation traditionnelle sépare la définition de la matrice des données de celle-ci parfois par plusieurs milliers de lignes de code dans le programme. Il vaut mieux coder la matrice à l’intérieur d’une structure de données (figure 4).

Eviter l’occurrence multiple de structures de données.La structure de données de matrice de la V5R2 présente une meilleure structure parce qu’elle utilise la notation de matrice standard dans votre programme, qu’elle ne vous limite pas à traiter une occurrence unique dans la même ligne, et qu’elle vous permet de traiter les cas où les matrices imbriquées (multidimension) sont utiles.

Utiliser des structures de données QUALIFIED.Les structures de données QUALIFIED vous obligent à qualifier leurs noms de sous-champs avec le nom de la structure de données (comme Customer.name, Customer. Address). Cette fonction donne bien sûr une bonne documentation pour l’élément de données, en indiquant son origine ; mais elle permet aussi d’avoir des sous-champs nommés identiquement dans des structures de données différentes (par exemple, Before.Name, After.Name). Pour définir une structure de données qualifiée, utilisez le mot-clé QUALIFIED dans sa définition.

Les mots-clés LIKEDS et LIKEREC (V5R2) sont aussi utiles quand une structure de données « hérite » ses sous-champs d’une autre structure de données ou d’un autre format d’enregistrement. De plus, dans la V5R2, vous pouvez contrôler les sous-champs qui apparaîtront dans une structure de données LIKEREC ou une structure de données décrite en externe, en spécifiant les champs *ALL, *INPUT, *OUTPUT ou *KEY.