Avant de commencer, je souhaite vous présenter mes meilleurs voeux à tous en cette nouvelle année qui démarre. Et surtout, je tiens à remercier les quelques fidèles qui ont découvert récemment ce petit weblog sans prétention (pour le moment, mouhahaha !).

Quoi de mieux pour entamer 2k11 que la poursuite de notre série sur l’ABAP ? Rien, évidemment, alors reprenons là où nous en étions resté.
Nous avions abordé un petit Hello World, que nous avions après coup rendu un peu dynamique. C’était très basique, mais l’objectif était juste de fournir un aperçu du langage.

Aujourd’hui, nous aborderons les sous-programmes. Un article à venir se penchera sur les traitements de la base de données.

Sous-programmes

L’ABAP est un langage très bien fait (on sent l’ironie là ou pas ?) et offre de multiples possibilités pour moduler le code, le rendre réutilisable et plus maintenable. Parmi toutes les solutions, citons le sous-programme (ou routine).
Le sous-programme est l’équivalent d’une fonction dans les langages tels le PHP ou le Javascript, si ce n’est qu’il est – idéalement – local à un programme.

Exemple : dans le programme Hello World évolué (cf. article précédent), j’aurai pu créer un sous-programme chargé de sortir à l’écran le fameux « Hello name ». Un tel sous-programme aurait pris en paramètre d’entrée le nom à afficher, et aucun paramètre de retour.

Je disais plus haut que les sous-programmes sont idéalement locaux au programme pour lequel ils sont créés. C’est l’idéal selon ma vision des bonnes pratiques de développement ABAP. Car dans les faits, un sous-programme créé dans un programme X peut être appelé depuis tout développement ABAP (programme Y, mais également module fonction par exemple). Si l’on ajoute à cela le fait qu’il est possible dans un sous-programme de manipuler (en lecture et en écriture) les variables globales, ça peut rapidement devenir un bordel monstre à maintenir et débuguer. Et quand je parle des variables globales, ce sont celles globales au programme dans lequel le sous-programme est créé, et non celles globales au programme appelant le sous-programme.

Exemple : le programme A possède une variable globale v1 et un sous-programme A1. Ce sous-programme n’a pas de paramètre d’entrée/sortie, mais incrémente la variable globale v1. Le programme B peut faire appel au sous-programme A1, la variable v1 sera incrémentée, mais dépilée et donc perdue en sortie du sous-programme, lors du retour dans le programme B.
Cet exemple est simple, mais si le sous-programme appelé est censé mettre à jour la base de données en fonction de la valeur d’une variable globale théoriquement valorisée en amont du programme originel A, mais que le sous-programme est appelé par un autre programme B sans faire attention à cette variable globale (inconnue et inaccessible pour le programme B), la base de données peut-être rendue incohérente.

La bonne pratique, selon moi, est de ne pas utiliser un sous-programme en dehors de son programme d’origine et dans tous les cas, de ne jamais accéder aux variables globales dans un sous-programme. Les paramètres d’entrée/sortie des sous-programmes sont là pour ça : ils doivent être les seules sources de données extérieures au sous-programme auquel ce dernier peut avoir accès. Ainsi, on maîtrise complètement les effets du sous-programme et l’on réduit le risque de dommage collatéral.

Un dernier point sur les sous-programmes : dans l’exemple de code ABAP présenté plus haut, on peut lire « USING value(iv_nickname) ». le mot-clé VALUE permet d’indiquer que le paramètre est passé par valeur. Cela signifie que par défaut, il est passé par référence. Le mot-clé USING indique qu’il s’agit d’un paramètre fournit en entrée, par opposition avec le mot-clé CHANGING définissant les paramètres susceptibles d’être modifiés en sortie du sous-programme.
L’incohérence se situe dans l’utilisation de USING sans VALUE ou de CHANGING avec VALUE. Les paramètres d’entrée comme les paramètres de sortie peuvent être passés par valeur ou par référence.

• USING par référence : si la valeur est modifiée dans le sous-programme, elle sera modifiée en sortie (malgré le mot-clé USING qui suggère le contraire) ;
• CHANGING par référence : idem, mais c’est plus logique dans ce cas ;
• USING par valeur : la valeur de sortie restera inchangée peu importe le traitement du sous-programme ;
• CHANGING par valeur : contrairement au CHANGING par référence, une modification sur la valeur n’est pas reportée directectement sur la valeur de la variable utilisée lors de l’appel au sous-programme. La valeur modifiée par le sous-programme n’est transmise au programme appelant qu’à la fin du sous-programme, sous réserve qu’il se termine normalement. Si une exception est levée par exemple, la valeur restera inchangée.

Il faut donc rester très prudent sur l’utilisation d’un sous-programme (d’autant plus si l’on n’est pas l’auteur du-dit sous-programme). Personnellement, je passe systématiquement les paramètres USING par valeur et les CHANGING par référence, car c’est le plus logique a priori. D’un point de vue performance, on y perd un peu car une copie locale des données est faite lors d’un passage par valeur, mais j’estime que la perte est minime par rapport au gain en maintenabilité du développement.

Voilà je pense tout ce que l’on pouvait dire sur les sous-programmes. N’hésitez pas si vous avez la moindre question/remarque/critique/autre… Les commentaires sont ouverts pour ça.