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
Mac en entreprise : le levier d’un poste de travail moderne
Ce livre blanc répond aux 9 questions clés des entreprises sur l’intégration du Mac : sécurité, compatibilité, gestion, productivité, coûts, attractivité talents, RSE et IA, et l’accompagnement sur mesure proposé par inmac wstore.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Pilotage de la DSI : lucidité, exigences et engagement
- Les entreprises n’ont plus le luxe d’expérimenter l’IA
- Le changement, moteur d’engagement au travail
- Cloud 2026 : 5 tendances à anticiper pour les PME françaises
Articles les + lus
Alliée ou menace ? Comment l’IA redessine le paysage cyber
CES 2026 : l’IA physique et la robotique redéfinissent le futur
Les 3 prédictions 2026 pour Java
Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
Face à l’urgence écologique, l’IT doit faire sa révolution
À la une de la chaîne Tech
- Alliée ou menace ? Comment l’IA redessine le paysage cyber
- CES 2026 : l’IA physique et la robotique redéfinissent le futur
- Les 3 prédictions 2026 pour Java
- Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
- Face à l’urgence écologique, l’IT doit faire sa révolution
