Discussion :

[jeroc]

Bonjour,

Quelqu'un a-t-il une liste des choses à ne pas faire dans du code ABAP ?

Mon but est d'éviter d'insérer des bugs potentiels dans mes programmes et d'avoir des problèmes de performance. De plus, j'ai récupérer du code écrit par d'autres et je voudrais vérifier s'il a été écrit correctement afin de m'éviter de mauvaise surprise.

Où puis-je trouver de la doc sur la qualité du code ?

D'avance merci.

[cladsam]

Bonjour,

Quelqu'un a-t-il une liste des choses à ne pas faire dans du code ABAP ?

Mon but est d'éviter d'insérer des bugs potentiels dans mes programmes et d'avoir des problèmes de performance. De plus, j'ai récupérer du code écrit par d'autres et je voudrais vérifier s'il a été écrit correctement afin de m'éviter de mauvaise surprise.

Où puis-je trouver de la doc sur la qualité du code ?

D'avance merci.

Salut,

il y a plein de choses à ne pas faire en ABAP. A titre d'exemple :
- faire des requêtes sans inclure les indexes
- faire des tables internes trop volumineuses
- imbriquer des tonnes de select/and select
- ne pas tester les codes retour des modules fonction
- faire des select for all entries pour une table vide.
- attaquer des objets sans les avoir verrouillés
- utiliser des type au lieu des like dans les déclarations ce qui provoque du code difficile à maintenir
- a l'inverse, utiliser like ou structure dans un contexte objet

Bref le mieux reste de systématiquement :
- utiliser des conventions de nommage
- passer le code inspector au plus strict
- passer la se30

Et après, il y a plein d'autres choses à apprendre au cas par cas dans la doc officielle

[jeroc]

Dans les 2 derniers points de la liste, sur l'utilisation de TYPE et de LIKE, je ne comprends pas bien dans quels cas utiliser plutôt l'un que l'autre. Quelles sont les conséquences ?

[cladsam]

POur le contexte objet : SAP oblige l'utilisation de type dans le contexte d'un code objet.
POur l'avant dernière, soit une table A avec les champs

ch1 type A
ch2 type B

Toi derrière tu veux récupérer les données de ch1 dans une variable. Si tu défini ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 data : mavariable type A.

Ca marche. Seulement demain pour une raison x ou y, on vient faire une maintenance de la table et on la fait ainsi :

ch1 type C
ch2 type D

Ton code qui fait toujours référence à type A va foirer ... bon courage pour le maintenir.
En revanche si tu avais écrit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
DATA : ma variable like TABLEA-ch1.

Meme après la maintenance de la table, ton code restait vrai...
C'est très bête mais c'est des astuces qui coutent parfois très cher ...

[jeroc]

Donc, dans un Form ou une fonction, il vaut mieux utiliser like et dans une méthode il faut utiliser type.

Pour revenir à ta liste, à partir de quel volume peut-on raisonnablement considérer qu'une table interne est trop volumineuse ?

Une autre question me vient au sujet des ASSIGN : on m'a dit qu'il était possible de faire des références à une variable définie dans un autre programme. Est-ce vrai ? C'est dangereux si l'autre programme est modifié, non ? A quoi puis-je voir qu'il y a une telle référence ? (j'ai peu d'expérience en ABAP, comme tu peux le remarquer, et donc je n'en ai jamais vu)

[Celdrøn]

Salut à tous,

J'aurais une question sur ce que t'as cité plus haut cladsam:

il y a plein de choses à ne pas faire en ABAP. A titre d'exemple :
[...]
- imbriquer des tonnes de select/and select

Le mieux ne serait pas plutot d'interdire complètement de mettre en place des SELECT/ENDSELECT?
Parce que d'un, en débugage ça dump 9 fois sur 10 donc déjà c'est une bonne prise de tête pour tester nos traitements et puis de deux, c'est consommateur de temps car on multiplie l'accès à la base donc coté perf, c'est pas génial...
Ne serait-il pas plus judicieux de privilégier les SELECT[...] FOR ALL ENTRIES?
Ca limite le nombre d'accès aux bases, et pour croiser les données, on travail avec des données en mémoire donc accès 1000 fois plus rapide.

J'attends ton avis.

@++.

[cladsam]

Bah mon avis est simple : je n'utilise jamais de select / and select !!! Je deteste. Si je dois faire un traitement particulier pour chaque ligne, je fais le for all entries puis je fais un loop sur la table.
Je parlais de l'imbrication du select /and select plutot pour la partie de la question qui dit

et je voudrais vérifier s'il a été écrit correctement afin de m'éviter de mauvaise surprise.

Bah la clairement s'il voit une imbrication de cette horrible commande, il sait qu'il peut épurer ... après je ne prétend pas que l'on ait la meilleure vision qui soit, peut-être certains ont ils d'excellents arguments pour justifier l'existence de cette instruction ?

[Celdrøn]

Merci pour ta réponse cladsam. Ravie de voir qu'on partage la même vision des choses, 'fin point de vue accès à la base en tout cas ^_^.

Sinon comme tu dis, chacun sa vision des choses mais c'est vrai que de mon coté, j'ai rien trouvé de mieux que le SELECT [...] FOR ALL ENTRIES suivi d'un LOOP, voire LOOP indexé s'il y a lieu qu'il y en est, si y'a besoin de traiter les données récupérées.

Bonne fin de journée,
@++.

[splash1]

juste petite précision
le select/endselect fait un accès base a chaque itération
le for all entries découpe la table par paquets de 5 enregistrements (traces ST05 pour preuve)
conséquences: avant le for all entries il faut: trier la table et supprimer des doublons

[kitty2006]

Bonjour,

Pourquoi conseillez-vous de passer la SE30 à quoi sert-elle?

salutations

[Celdrøn]

Cette transaction permet de mesurer la durée d'execution d'un programme.

Si on constate que la durée de traitement est excessive, on essait de voir si il n'y aurait pas un peu, voire beaucoup, d'optimisation à faire.

Voila.