Procédures et prototypes RPG IV et au delà 

La manière dont on nomme les procédures influence grandement le travail
de développement. En suivant trois directives simples, on évitera des pièges de
développement souvent associés à  de mauvaises pratiques d’intitulé des procédures.



Donner des noms uniques aux procédures. Il est possible,
et parfois tentant, de construire des programmes de service multiples partageant
le même nom de procédure, au prétexte qu’il n’y aura pas de conflit, les applications
n’utilisant jamais ces programmes de services en même temps. Il faut absolument
éviter cela. On ignore en effet s’il ne faudra pas un jour utiliser plus d’un
de ces programmes de service en même temps. En outre, les procédures qui partagent
le même nom mais exécutent des fonctions différentes peuvent être source d’erreur
pendant le développement d’applications.



Choisir des noms de procédures facilement reconnaissables en tant que
tels. Une procédure sans paramètre peut facilement être confondue
avec un champ ; une procédure avec un seul paramètre peut être confondue avec
un élément de tableau. Examinons les lignes de code suivantes :



Eval TotalCost =

BaseCost + TaxAmt

Eval TotalCost =

BaseCost + TaxAmt(State)



Dans le premier exemple, TaxAmt est-il un champ ou une procédure ? Dans le second
exemple, TaxAmt est-il un élément de tableau avec l’index State ou une procédure
avec le paramètre State ? Pour savoir que TaxAmt est une procédure, il faut analyser
le reste du code source. Une méthode préconise de faire toujours précéder un nom
de procédure d’un préfixe donné  » p  » ou  » prc  » en minuscule. Ce qui donnerait
sur les exemples précédents :



Eval TotalCost =

BaseCost + pTaxAmt

Eval TotalCost =

BaseCost + pTaxAmt(State)



Bien entendu, dans ce cas, seules les procédures doivent commencer par le préfixe
en question.

Je préfère des standards plus fondés sur l’intuition que sur la mémorisation.
Ainsi, les champs et les éléments de tableau représenent des choses (noms), tandis
que les procédures indiquent des actions (verbes). Par conséquent, il faut donner
aux champs et aux tableaux des noms de choses et donner aux procédures des noms
d’actions. Exemple :  » TaxAmt  » pour un champ ou un tableau contenant un montant
de taxe, et  » RtvTaxAmt  » pour une procédure chargée d’extraire un montant de
taxe. Cette structure verbe/subjet pour nommer des procédures est cohérente avec
la manière dont IBM nomme les commandes. Avec ce standard plus intuitif, les noms
de procédures n’ont plus besoin d’un préfixe spécial. On reconnaît une procédure
d’après le contexte. Sur les lignes suivantes il est clair que RtvTaxAmt est une
procédure parce que son nom indique une action.





Eval TotalCost =

BaseCost + RtvTaxAmt

Eval TotalCost =

BaseCost + RtvTaxAmt(State)





Donner aux procédures des noms significatifs et homogènes.
Le nom d’une procédure doit indiquer sa fonction. Et s’il faut pour cela que le
nom de la procédure soit long, il faut l’accepter. La clarté est plus importante
qu’une frappe courte !