Il y a quelques semaines, je découvrais le dépôt github SAP Clean ABAP.
J’ai commencé à mettre en pratique certains points lorsque ça n’était pas encore le cas. Je vais tâcher d’en donner mon avis point par point, au cours de – probablement – plusieurs articles.
Utiliser des noms descriptifs
L’idée principale est de nommer les choses (variables [simples, structures, tables internes…], classes, tables, etc.) par rapport à ce qu’elles représentent, plutôt que par leur contenu.
Ceci est une évidence pour moi, et j’espère pour la majorité des développeurs (mais qui n’a jamais vu une constante déclarée ainsi gc_a type c value 'A' ?).
La recommandation ajoute de ne pas utiliser les commentaires pour clarifier le nommage. Ce qu’il faut entendre comme : si un commentaire est requis pour cela, c’est qu’il y a un problème à résoudre. Donc changer ce nommage, plutôt.
Je suis également d’accord avec le principe d’utiliser des mots prononçables et d’éviter les abréviations.
Là où je trouve que c’est plus compliqué, c’est le paragraphe traitant de l’évitement de la notation hongroise et des préfixes.
C’est peut-être – probablement – lié à mon expérience de quelques années dans l’ABAP, mais j’ai toujours trouvé confortable l’utilisation de ces préfixes et cette notation hongroise (dont je ne connaissais pas le terme officiel jusqu’à présent).
Une variable locale de type structure, on écrira par exemple : ls_partner_address. Pour moi il est plus simple de savoir ce que l’on traite.
J’ai tenté de me passer de préfixes. Ce n’est pas si facile, les habitudes ont la vie dure. Globalement c’est faisable, je comprends mon code d’une journée à l’autre. Mais deux points sont soulevés :
1. Qu’en sera-t-il dans quelques semaines/jours ou pour un autre que moi ?
2. Plus pragmatiquement, comment faire la distinction entre les attributs et les paramètres.
Je précise ce second point par un exemple : une classe possède un attribut qu’on appellera partner_name. Hop, pas de préfixe, tout va bien.
Maintenant j’ai besoin d’une méthode setter pour cet attribut. Mon réflexe est de nommer le paramètre de la méthode partner_name. Mais je me retrouverai alors dans le code avec partner_name = partner_name.
Pas très propre. Ma solution pour le moment est de conserver les préfixes pour les paramètres des méthodes.
Les recommandations conseillent d’utiliser dans ce cas précis la référence à l’instance ; on aurait donc : me->partner_name = partner_name.
Certes oui, mais je trouve ça assez inélégant d’utiliser cette auto-référence ici, mais pas ailleurs, sachant qu’il est je crois recommandé de ne pas l’utiliser lorsque ce n’est pas nécessaire.
J’ai donc le sentiment que conserver les préfixes de paramètres est un bon compromis. L’usage me dira si j’ai tort ou pas.
En outre, le problème se pose aussi lorsque l’on traite des références. Par exemple, lorsque je boucle sur une table interne vers une référence, il peut devenir difficile de comprendre, si l’algorithme devient compliqué, que je traite une référence, donc à utiliser avec le déréférencement, etc.
Exemple :loop at partner_addresses reference into data(partner_address).
La simple lecture du code à l’intérieur de cette boucle ne permet pas de savoir que l’on traite une référence à une ligne (et que donc toute modification sera répercutée instantanément dans la table interne).
La documentation adresse ce souci en précisant que de toute façon les méthodes doivent être le plus court possible, et que donc le problème ne se posera pas. Là encore, l’usage dira si ça marche correctement pour moi. Sachant que j’essaye déjà depuis quelques années d’avoir des méthodes courtes.