Centralisez les déclarations

et
CLEAR, pour définir des variables de programme. Mais pour faciliter la
maintenance et pour clarifier le programme,
il vaut mieux adopter un
standard qui consolide toutes les définitions
de données, y compris les
champs de travail, dans des cartes D.

Déclarer toutes les variables
dans des cartes D. A l’exception des
listes de clés et des listes de paramètres,
ne déclarez pas les variables
dans des cartes C – pas même en utilisant
*LIKE DEFINE. Définissez les
listes de clés et les listes de paramètres
dans les premières cartes C du programme,
avant tout calcul exécutable.
Utilisez une définition de prototype au
lieu d’une liste de paramètres d’entrée
(*ENTRY PLIST).

Chaque fois qu’un littéral a une
signification précise, déclarez-le
comme une constante nommée dans
les cartes D. Cette pratique aide à  documenter
le code et rend sa maintenance
plus facile. Une exception évidente
à  cette règle est l’utilisation de 0
et de 1 quand ils sont pertinents dans
le contexte d’une instruction. Ainsi, si
vous devez initialiser un champ accumulateur
ou incrémenter un compteur,
il est bon d’utiliser un 0 ou 1 codé
en dur dans le source.

Mettez en retrait les noms d’é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
cartes D. Profitez de cette latitude pour
mieux documenter le code.

Utilisez la notation par longueur
plutôt que la notation positionnelle
dans les déclarations de structures
de données. Les cartes D 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
par longueur de manière cohérente.
Par exemple, codez :

D RtnCode DS

D PackedNbr 15P 5

au lieu de

D RtnCode DS

D PackedNbr 1 8P 5

N'utilisez la notation positionnelle
que quand la position réelle dans une
structure de données est importante.
Par exemple, lors du coding de la structure
de données de l'état du programme,
de la structure de données
des informations de fichier, ou de la
structure de données de renvoi provenant
d'une API, il faut utiliser la notation
positionnelle si votre programme
a ignoré certaines positions conduisant
à  un champ ou entre des champs.
Il vaut mieux utiliser la notation positionnelle
qu'utiliser des variables de
« remplissage » superflues avec la notation
par longueur. Au lieu de coder
comme illustré en figure 2A, par
exemple, il vaut mieux remplacer la variable
déclarée positionnellement par
une autre variable déclarée avec une
notation par longueur, pour mieux documenter
la variable.

Pour définir des champs en chevauchement,
utilisez le mot-clé OVERLAY
plutôt que la notation positionnelle.
Le mot-clé OVERLAY lie
explicitement la déclaration d'une variable
enfant à  celle de son parent. Non
seulement OVERLAY documente cette
relation, mais si le parent se déplace
dans le code du programme, l'enfant
suivra.

Si votre programme utilise des
tableaux de compilation, utilisez la
forme **CTDATA pour identifier les
données de compilation. Cette forme
documente clairement l'identité des
données de compilation, liant les données
à  la fin du programme à  la déclaration
de tableau dans les cartes D. La
syntaxe **CTDATA évite également
des erreurs en dispensant de coder les
données de compilation dans le même
ordre que celui des déclarations de tableaux
multiples.