Bonjour à tous,

L’article du jour ne sera pas très technique. En effet, il relatera quelques bonnes pratiques en terme de mise en forme et de sémantique dans les programmes ABAP. Ces conseils sont directement tirés des recommandations officielles fournies par SAP.

Pas de minuscules mélangées au majuscules

La première recommandation est donc d’être cohérent sur la casse des programmes. Contrairement à d’autres langages tels le Javascript, l’ABAP n’est pas sensible à la casse. Ainsi, il sera impossible de déclarer les deux variables suivantes dans une même procédure, au risque d’obtenir un beau message du compilateur :

C’est un peu frustrant au début, lorsque l’on vient du développement Web où l’on a l’habitude d’utiliser les majuscules en début de « mot », puis l’on s’y fait et l’utilisation du trait de soulignement devient une habitude. Cependant, ce n’est pas parce que l’ABAP n’est pas sensible à la casse que l’on doit changer la casse des variables d’une instruction à l’autre. Cela rendrait le code illisible et… peu esthétique. Le prochain lecteur du code aurait l’impression de se retrouver dans un skyblog !
Le pretty printer aide à ne pas faire cette erreur en reformatant automatiquement (mais à la demande) le code. Selon son paramétrage, il peut tout mettre en majuscules, en minuscules, ou uniquement les mots-clés. Personnellement, je mets tout en minuscules systématiquement.
Pour la petite histoire, cela fait des années que par convention les mots-clés des instructions ABAP sont en majuscules, cela vient du temps où la coloration syntaxique n’existait pas. Désormais celle-ci est suffisamment évoluée pour ne pas avoir à utiliser les majuscules.

Pas de ligne trop longue

La deuxième recommandation concerne la taille des lignes de code (et de commentaire). Les lignes ne sont pas (ne sont plus) techniquement limitées en nombre de caractères, mais ce n’est pas une raison pour utiliser toute la largeur d’écran disponible. Là encore, la lisibilité s’en ressentirait, et la maintenant ne serait pas facilitée du tout.
Un exemple tout bête : le debugging. Lorsque l’on débug, on a quasi systématiquement l’écran divisé en deux parties. D’un côté le code en cours d’exécution, de l’autre le contenu des variables ou la pile d’appels. Ainsi, on comprend qu’une ligne très longue sera horrible à lire car probablement invisible en une fois.
Dans tous les cas, il est bon de rappeler que pour optimiser la lecture à l’écran, une ligne ne doit pas dépasser, en gros, une centaine de caractères.

Une instruction par ligne

En ABAP, une instruction débute par un mot-clé (la plupart du temps) et se termine par un point. Le retour à la ligne n’est pas obligatoire. Et parfois on peut tomber sur une condition IF très courte avec les trois instructions sur une ligne, du type :
IF lv_error IS NOT INITIAL. RETURN. ENDIF.
Certes cela limite le nombre de ligne, mais l’effort de lecture est accru car le lecteur ne peut pas se fier à l’indentation pour visualiser le code.
À éviter donc !

Utiliser des noms anglais, pour le code et les commentaires

Je pense que sur ce point je ne vais pas me faire des amis, mais je partage complètement cette recommandation. Pour rappel, SAP est allemand d’origine et il n’est pas rare qu’au cours d’un debug approfondi des fonctions du standard je tombe sur du code commenté en allemand. Eh bien il m’est impossible de comprendre de tels commentaires sans Google Translate à côté. On me rétorquera que pour certaines personnes, des commentaires et/ou des variables en anglais ne sont pas plus compréhensibles que de l’allemand. Certes. Mais l’anglais est universel dans l’informatique aujourd’hui et le niveau technique est facilement atteignable pour quiconque s’en donne un peu la peine.
Donc : les commentaires doivent être en anglais, et les noms des variables aussi.
Exception : certaines entités sont bien connues dans les systèmes SAP et dans ces cas là, il est sans doute préférable de les utiliser, même si elles sont d’origine allemande et/ou abbréviées (je pense à ANLAGE ou VKONT par exemple, respectivement Installation et Compte de contrats). Il faut faire la part des choses entre tout angliciser et reprendre les termes « clés » standard.

Utiliser des noms descriptifs

Ce point recoupe un peu le précédent. Et c’est peut-être le plus important de cette liste. Utiliser des noms descriptifs. La sémantique est très importante pour une bonne maintenance du code. Imaginez un code source où toutes les variables sont vides de sens, avec des lv_a, lv_number1, lv_number_bis, ls_struct, lt_table. Comment savoir à quoi chacune d’elle sert ? Quel est leur but ? Impossible à déterminer sans une étude du code. On répondra qu’un petit commentaire suffira. Je ne suis pas d’accord, car si l’on peut prendre le temps de commenter :
" table des partenaires
DATA lt_table TYPE STANDARD TABLE OF but000.
alors on a tout autant le temps d’écrire :
DATA lt_partner TYPE STANDARD TABLE OF but000.

Le commentaire devient superflu (car redondant) et donc disparaît.
L’idée est là d’ailleurs : un code bien écrit peut se passer presque complètement de commentaire. Les noms des variables, des classes et des méthodes doivent être suffisamment explicites pour qu’il n’y ait pas besoin de commentaire, sauf pour expliquer la raison d’un choix technique.
Sur l’exemple suivant, à quoi servent les commentaires ?

À rien, eh oui. La redondance est flagrante. Le code ne présente pas de subtilité, donc les commentaires ne servent pas. Car les noms sont explicites.

Je résume cet article par la phrase suivante (qui n’est pas de moi mais je n’en connais pas son auteur) :
« Un code facilement lisible est au moins aussi important qu’un code qui fonctionne.«