> Tech > Procédures et prototypes RPG IV et au delà 

Procédures et prototypes RPG IV et au delà 

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Gary Guthrie
Bien organiser les sources et les objets ILE facilite grandement le développement des applications RPG IV

Il est bien connu qu'avec le couple ILE (Integrated Language Environment) et RPG IV, on peut écrire des applications plus modulaires et plus robustes. Les modules et programmes de service permettent de construire très simplement des programmes à  l'aide de plusieurs petits fragments de code faciles à  maintenir et réutilisables. Quant aux procédures RPG IV, elles permettent de scinder facilement des applications en fonctions bien définies.

Si tout cela favorise le développement d'applications, il faut aussi en payer le prix. Avec ces améliorations, gérer le code source et les objets devient une tâche indispensable. Plus on étendra le développement pour y inclure davantage le RPG IV, plus les procédures seront utilisées dans les applications. Et, face à  l'augmentation du nombre de procédures, on constate qu'il devient difficile de suivre les procédures disponibles et les programmes de service qui les contiennent. Pour alléger le travail de développement, il faut choisir les bonnes techniques d'administration.

La manière dont on nomme les procédures influence grandement le travail de développement

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 !


Téléchargez gratuitement cette ressource

Guide de facturation électronique, voie royale pour le DAF et la digitalisation de la fonction finance

Guide de facturation électronique, voie royale pour le DAF et la digitalisation de la fonction finance

Ce livre blanc expose les problématiques auxquelles sont confrontés les DAF modernes et souligne les bénéfices de la facturation électronique pour la trésorerie. Il dévoile également le processus de déploiement de ce projet de transformation digitale que la réglementation rendra bientôt obligatoire.

Tech - Par iTPro.fr - Publié le 24 juin 2010