Derrière tout bon programme RPG, on trouve un programme CL. Il est généralement court et ciblé. Il définit les overrides, les paramètres, les chemins de fichiers, et les résultats de requêtes, puis il appelle le programme RPG. Parfois, le programme CL sera plus long et plus complexe, jusqu’à contrôler le flux d’une application ou de tout un système. Dans un environnement ILE, on peut packager un processus CL comme une procédure fréquemment utilisée dans un programme ou un programme de service.
Dans la réalité, les programmes CL sont souvent courts et généralement écrits après leur programme RPG compagnon. C’est pourquoi il est facile de sous-estimer le style, les standards, et les meilleures pratiques CL. Or, les programmes CL méritent autant un bon style et de bons standards que leurs homologues écrits en RPG ou tout autre langage.Les recommandations de style posent un problème particulier en CL à cause des fonctions d’invite (prompteur) intégrées dans le système d’exploitation. Il est facile d’utiliser l’invite (F4) pour afficher les paramètres et valeurs valides quand on ne connaît pas les exigences d’une commande. Et le code CL résultant est certainement constant. En effet, il est constamment laid, constamment illisible, constamment difficile à comprendre, et constamment « surchargé en guillemets ». Bien que, à court terme, il soit plus rapide de créer un programme CL opérationnel en utilisant le prompteur, une vue à plus long terme – prenant en compte les futures considérations de maintenance – exige que vous consacriez un peu plus de temps supplémentaire dès à présent à réaménager le code pour respecter les bons standards. L’avantage sera triple : gain de temps, moins de risque et moins d’erreurs en cours de route. Cela étant posé, voici 19 conseils pour écrire un code CL élégant.
19 étapes vers un meilleur style CL
Je sais, vous avez déjà entendu ce conseil. Mais il vaut pour CL autant que pour tout autre langage. Incluez des commentaires quand la finalité du code CL n’apparaît pas de manière évidente. Evitez les commentaires qui se contentent de répéter le code : ils sont sans intérêt et ne font qu’alourdir la compréhension générale du programme.
La syntaxe CL ouvre les commentaires par les deux caractères /* et les ferme par les deux caractères */. A l’exception de courts commentaires dans la ligne, les caractères d’ouverture devraient démarrer en colonne 1, et ceux de fermeture devraient être alignés verticalement dans le code source pour faciliter la lisibilité. Si un commentaire occupe plus d’une ligne de code source, chaque ligne doit inclure les caractères open/close.
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre dossier Green IT sur les actions engagés par inmac wstore pour réduire son impact environnemental
