Die besten ABAP-Tricks beim Entwickeln

Du bist ABAP-Entwickler und möchtest die Qualität in Deinen ABAP-Programmen erhöhen? Mit Richtlinien beim Entwickeln kannst Du einfach und schnell die Qualität in Deine Code verbessern. Weniger Fehler und bessere Lesbarkeit erhöhen die Wartbarkeit und erhöhen die Kundenzufriedenheit.

Mit diesem Artikel zeige ich Dir die besten Tipps und Tricks, die jeder ABAP-Entwickler anwenden soll, um seine Qualität beim Programmieren zu erhöhen. Viel Spaß.

Richtige Editoreinstellungen

Im Editor (ABAP Editor) kannst Du viele nützliche Funktionen aktivieren, um Dir das Leben beim täglichen Entwickeln zu erleichtern.

Wenn Du im ABAP Editor (Transaktion SE38) oder in der ABAP Workbench (Transaktion SE80) als Beispiel bist, kannst Du die Editoreinstellungen unter „Hilfsmittel > Einstellungen“ erreichen.

Anschließend kannst Du im Reiter „ABAP Editor“ die Editoreinstellungen vornehmen. Im Reiter „Editor“ darunter nimmst Du allgemeine Einstellungen zum Editor vor. Hier sollte vor allem der „Quellcode-basierte Editor“ ausgewählt werden.

Der Reiter „Pretty Printer“ ist ebenfalls wichtig für eine leichtere Arbeit mit dem ABAP Editor. Der Pretty Printer ist ein Tool, die Du mit dem Button „Pretty Printer“ oder der Tastenkombination „Umschalt + F1“ ausführen kannst. Durch diese Kombination wird Dein Quellcode gemäß den Einstellungen formatiert. Dadurch erhöhst Du die Lesbarkeit Deines Codes enorm. Vor dem Aktivieren Deines Codes solltest Du deshalb immer den Pretty Printer ausführen.

Beim Pretty Printer ist das „Einrücken“ und eine Unterscheidung zwischen Groß- und Kleinschreibung von Vorteil. Hier ist es nützlich, alle Schlüsselwörter „groß“ zu schreiben, auch wenn ABAP als Programmiersprache nicht case sensitive ist.

Der Reiter „Splitscreen“ ist weniger relevant und kann mit den Standardeinstellungen belassen werden.

Gerade als Entwickler ist das Debugging und die Fehlersuche eine tagtägliche Arbeit. Teilweise muss man auch RFC- oder Remote-Aufrufe im Debugging testen und dafür einen externen Breakpoint setzen. Dieser wird dann aber vom RFC-Benutzer aufgerufen und nicht vom eigenen SAP-Benutzer. Der RFC-Benutzer kann deshalb im Reiter „Debugging“ eingetragen werden.

Beachte aber dabei, dass Du unbedingt nach dem Debuggen erneut Deinen SAP-Benutzer wieder einträgst oder den externen Breakpoints entfernst, da ansonsten jeder externe Aufruf vom externen Breakpoint gestoppt wird und Du den Aufruf fortführen musst.

Code-Vorlagen für übersichtliche und vordefinierte Kommentare

Code-Vorlagen – Übersicht und Beispiel

Jeder ABAP-Entwickler sollte mit Code-Vorlagen arbeiten. Das erleichtert Dir ungemein die tägliche Arbeit. Du kannst Dich mehr auf das Programmieren konzentrieren, anstatt typische und gleiche Kommentare immer und immer wieder einzufügen.

Im ABAP Editor erreichst Du ganz unten rechts in Deiner SAP GUI die Code-Vorlagen, wenn Du den entsprechenden Button drückst:

Nach Drücken des Buttons öffnen sich die Optionen. Hier kannst Du einfach den Knoten „Code-Vorlagen“ auswählen.

In dem Screenshot siehst Du bereits, dass ich eine Code-Vorlage namens „block“ gepflegt habe. Wenn man nun im Quellode die ID der Code-Vorlage schreibt und dann die TAB-Taste betätigt, kann man die Code-Vorlage nutzen. In diesem Beispiel wird noch ein Vorlagenparameter „Beschreibung“ verwendet. Das sorgt dafür, dass man in einem PopUp einen Text eingeben kann, der dann gemäß der Code-Vorlage eingefügt wird.

Dadurch kann man sehr einfach und schnell vordefinierte Kommentare nutzen und muss diese nicht jedes Mal von Neuem erstellen.

Code-Vorlagen im Muster nutzen

Man kann aber anstatt Code-Vorlagen auch Muster benutzen, um einen formatierten Kommentar einfach einzufügen. Unter „Hilfsmittel > Weitere Hilfsmittel > Muster bearbeiten > Muster anlegen“ kann man neue Muster anlegen. Dann kann man einfach den Text eingeben, den man einfügen möchte, wenn man dieses Muster aufruft.

Das angelegte Muster kannst Du einfach über „Muster > Anderes Muster“ auswählen bzw. aufrufen. Anschließend wird der vordefinierte Text 1:1 eingefügt.

Gerade wenn Deine Code-Vorlagen umfangreicher sind, ergibt es Sinn, die Code-Vorlagen in einem Funktionsbaustein auszulagern.

Namenskonventionen

Um die Lesbarkeit und Wartbarkeit Deines ABAP-Programms enorm zu erhöhen, sollte man unbedingt in Teams sich auf Namenskonventionen einigen. Dadurch wird sofort sichergestellt, wie Variablen, Strukturen, Tabellen, etc. heißen sollten. Sofort erkennt man im Programm selber, um welchen Typ es sich handelt, ohne jedes Mal in der Datendeklaration das nachzusehen.

Folgende Präfixe kann man dabei verwenden:

Typ	Lokal	Global	Feldsymbol	Klassenattribut	Import, Export, Return, Change in Fubas
Variable	lv_	gv_	<fv_	cv	iv_, ev_, rv_, cv_
Struktur	ls_	gs_	<fs_	cs	is_, es_, rs_, cs_
Tabellentyp	lt_	gt_	<ft_	ct	it_, et_, rt_, ct_
Referenz	lr_	gr_	<fr_	cr	ir_, er_, rr_, cr_
Konstante	lc_	gc_	<fc_	cc

Bessere Performance in ABAP-Programmen

Schnellerer Zugriff bei internen Tabellen

Bei internen Tabellen sollte man Feldsymbole verwenden anstatt Strukturen. Das hat folgende Vorteile:

• höhere Performance, da keine unnötigen Daten kopiert werden
• geringere Fehleranfälligkeit, da die interne Tabelle mit geändert wird, wenn sich das Feldsymbol ändert

LOOP AT lt_test ASSIGNING <ls_test>.
    <ls_test>-value = 'TEST'.
ENDLOOP.

Bei READ TABLE muss man prüfen, ob das Feldsymbol zugewiesen ist, da ansonsten eine Excpetion geworfen wird, die das Programm abstürzen lässt.

READ TABLE lt_test WITH KEY id = '1' ASSIGNING <ls_test>.
IF sy-subrc = 0.
" Zugriff auf das Feldsymbol <ls_test>
ENDIF.

Zugriff auf Datenbank

Das Verhalten und die Performance des Systems hängt davon ab wie viel Last auf der Datenbank entsteht, wie viele Daten zwischen der Datenbank und dem Applikationsserver übertragen werden müssen und letztlich auch wie viel Last auf dem Application Server selbst entsteht. Für diese Gründe ist es ratsam, die Anfragen auf die Datenbank so selten wie möglich ausführen zu lassen und auch nur die Daten abzufragen, die man wirklich benötigt.

Nur Daten lesen, die man wirklich benötigt

Beispiel für schlechten Code:

SELECT * FROM SPFLI INTO ls_spfli.
WRITE: / ls_spfli-carrid.
ENDSELECT.

Beispiel für besseren Code:

SELECT carrid FROM SPFLI INTO ls_spfli-spfli.
WRITE: / ls_spfli-carrid.
ENDSELECT. 

Vollständigen Schlüssel angeben

Beispiel für schlechten Code:

SELECT * FROM sflight INTO ls_sflight WHERE connid = '1234'.

Beispiel für besseren Code:

SELECT * FROM sflight INTO ls_sflight WHERE carrid = 'LH' AND connid = '1234'.

Wiederholte, einzelne Zugriffe vermeiden

Beispiel für schlechten Code:

SELECT SINGLE * FROM SPFLI INTO ls_spfli WHERE CARRID='LH' AND
CONNID='1234'.

SELECT SINGLE * FROM SPFLI INTO ls_spfli WHERE CARRID='LH' AND
CONNID='1235'.

SELECT SINGLE * FROM SPFLI INTO ls_spfli WHERE CARRID='LH' AND
CONNID='1236'.

Beispiel für besseren Code:

SELECT * FROM SPFLI INTO ... WHERE CARRID='LH'.

ENDSELECT.

Joins verwenden anstatt geschachtelter SELECTs

Beispiel für schlechten Code:

SELECT feld1 FROM tabelle1 INTO wa.
    SELECT feld2 FROM tabelle2 INTO wa2 WHERE feld2 = wa-feld1

    ENDSELECT.
ENDSELECT.

Beispiel für besseren Code:

SELECT feld1 feld2 FROM tabelle1 INNER JOIN tabelle2 ON tabelle1-feld1 = tabelle2-feld2.

ENDSELECT.

WHERE-Bedingungen, BETWEEN und LIKE

Bei WHERE-Bedingungen sollte man niemals negative Formulierungen wie z.B. „<>“ oder „NOT“ verwenden. Der Datenbank-Optimizer kann hier nicht mehr eingreifen und wird deshalb immer einen Full Table Scan durchführen. Das sorgt für Performanceeinbußen.

BETWEEN sollte ebenfalls nicht mehr verwendet werden. Stattdessen lieber „IN“ benutzen.

Versuche stets bei Zugriffen auf die Datenbank den LIKE-Operator zu vermeiden. Das ist einerseits keine eindeutige Suche und kann die Performance verschlechtern.

Nützliche Transaktionen für die Analyse

Ich habe einmal alle nützlichen Transaktionscodes notiert, die jeder ABAP-Entwickler kennen und einsetzen sollte. Diese sind für die tägliche Arbeit von enormen Nutzen.

Transaktionscode	Beschreibung
CODE_SCANNER	ABAP Suche
SCI	Code Inspector
ATC	ABAP Test Cockpit
SM12	Datenbanksperren lösen
DB13	Jobs DBA-Einplanungskalender
DB02	Datenbankanalyse
SM50	Übersicht über Workprozesse
ST05	SQL Performance-Trace
SM51	Instanz-Prozessübersicht
ST02	Tune Summary
ST04	DB Performance
SE30	Laufzeitanalyse
ST03N	Systemlastmonitor
STAD	SAP Workload Monitor
ST06	System-Monitor
RZ11	Dokumentation Profilparameter
DB05	Selektivanalyse der DB-Tabellen

Aktuelle ABAP-Syntax vermeiden

Verwende nicht die aktuelle ABAP-Syntax. Das klingt im ersten Moment konfus, kann Dir aber in Zukunft sehr viel Ärger ersparen. Warum sollte man nicht die aktuelle ABAP-Syntax wie z.B. Inline-Deklaration oder neuen Select-Statements nicht verwenden? Die Antwort ist einfach und simpel: Weil Deine Kunden nicht alle die gleiche ABAP-Version haben und es deshalb zu Problemen kommen kann.

Wenn Du natürlich exklusiv für einen Kunden oder ein Unternehmen entwickelst, dann sollte natürlich auch die aktuelle Syntax verwendet werden. Wenn Du Consultant oder Dienstleister bist, tunlichst nicht.

Oft nehmen Kolleginnen und Kollegen Deine Programmierung als Kopiervorlage. Das kann beim Ausliefern an den Kunden Probleme verursachen.

Beispiele für neue Syntax für ABAP in der Version >= 7.4

SELECT matnr, bukrs
  FROM ekpo
  WHERE ebeln IN selcrit
  AND   ebelp = ebelp
  INTO TABLE @DATA(lt_ekpo).

LOOP AT lt_ekpo ASSIGNING FIELD-SYMBOL(<ls_ekpo>).

ENDLOOP

Eine Übersicht über die aktuelle ABAP-Syntax findest Du unter help.sap.com.

Eindeutige Benamung in Transporten

Egal ob Customizing-, Workbenchtransporte oder Transporte von Kopien: Achte auf eine einheitliche Benamung und halte die Namenskonvention im Unternehmen ein.

Dabei eignet sich z.B. folgende Konvention:

<Projektkürzel> ddMMyyyy XxXx (T) <Beschreibung>

Konvention	Beschreibung	Beispiel
<Projektkürzel>	Wort, Kürzel oder kurze Beschreibung vom Projekt für das der Transport erstellt wird.	FI_2020
ddMMyyyy	Tag, Monat und Jahr der Erstellung	15092020
XxXx	Zwei Buchstaben des Vornamen und zwei Buchstaben des Nachnamen	AnGe
T	Buchstabe für Art des Transports C = Customizing-Transport W = Workbench-Transport T = Transport von Kopien L = Lokaler Transport	C
<Beschreibung>	Beschreibung was in dem Transport enthalten ist	Anpassung Kostenstelle für Kontierung

Insgesamt könnte also eine Bezeichnung für einen Beispiel-Transport folgendermaßen sein:

FI_2020 15092020 AnGe (C) Anpassung Kostenstelle für Kontierung