(Rappel : L’ABAP est le langage dans lequel tout SAP R/3 est développé. On parle là d’un ERP à beaucoup de millions d’euros de license, avec une industrie entière qui gravite autour. Il montre parfois qu’il a trois décennies d’âge.)

Ce code compile (sans rien faire mais ce n’est pas le problème) :

REPORT ZCCO_TEST.
IF 1 > 2 .
ENDIF.

Ceci ne compile pas :

REPORT ZCCO_TEST.
IF ( 1 * 5 ) > 2 .
ENDIF.

Relational operator "*" is not supported”, qu’il dit. On ne fait donc pas de calcul dans une condition. Je suis condamné à utiliser une variable de travail (une de plus).

Ceci non plus ne passe pas :

REPORT ZCCO_TEST.
IF 1>2.
ENDIF.

Pourquoi ? Il manque des espaces autour du >. Un scandale, effectivement.

C’est pareil pour les parenthèses (IF ( 1 > 2 ) .), il faut les séparer de ce qu’elles contiennent par des espaces. Sauf dans le cas d’un ordre SQL comme SELECT... INTO (variable1, variable2) WHERE... où, là, les parenthèses doivent être collées au reste.

Les limites de ce genre sont pléthore en ABAP. Je hais ce langage. On peut faire son boulot avec, mais c’est comme taper sur un clavier avec des moufles.

Il y a aussi des incohérences un peu pénibles. Par exemple, deux syntaxes totalement différentes selon que l’on recherche une donnée dans une table réelle (de la base de données) ou interne (un bête tableau en mémoire, de même structure que la table réelle).

Le premier ressemble à ça (recherche d’un poste de commande sur sa clé primaire constituée de vbeln et posnr) :

SELECT ... FROM vbap
WHERE vbeln = ...
AND posnr = ...

Par contre pour la table interne :

READ TABLE t_vbap ...
WITH KEY vbeln =...
posnr = ...

Vous avez remarqué : dans un cas il y a un AND entre les deux critères de recherche. Dans l’autre, non. Pourquoi ? Mystère. Petit détail, oui. Mais à la fin de la journée on en perd, des minutes à faire plaisir au compilateur.