Abap Forum on Gate²App

Es täte mich mal interessieren, was für euch als Programmierer als "goldene Regeln" der ABAP-Programmierung anzusehen ist.


Für mich wäre das z.B. folgendes:

Oftmals steht man vor der Aufgabenstellung, SAP-Standard-Tabellen zu manipulieren (z.B. um Drucker zu sperren o.ä.). Die Aufgabensteller, oftmals mit äußerst ungesundem Halbwissen gesegnet, haben dann auch gleich die passenden Tabellen nebst zu änderndem Feld gefunden, wo man mit "einem einfachen UPDATE die Einträge ändern kann".

Es kostet meist einige Überredungskünste, sie davon wieder abzubringen und davon zu überzeugen, daß es für die allermeisten Fälle diverse Funktionsbausteine gibt, die die gestellte Aufgabe zur Zufriedenheit erfüllen und bei denen man vor unliebsamen Seiteneffekten sehr viel sicherer sein kann.


Goldene Regel Nr. 1 für mich wäre also:

• Niemals Standard-Tabellen direkt manipulieren, sondern ausschließlich mit den passenden Funktionsbausteinen, Report, Programmen (evtl. über BATCH-INPUT).

(Nebenbei bemerkt wäre es ganz nett, wenn man seine Texte hier ein wenig formatieren könnte. Ein solch spartanischer Editor ist mir in Foren nicht mehr untergekommen, seit ich mit meinem ersten 14,4 Modem einen Geschwindigkeitsrausch bekam)

meine goldene regel no. 1 ist, niemals ein programm ohne

auswertung via se30 freizugeben


joachim

Regel Nr 1: Verwende so wenig globale Variablen wie möglich!

Meine Erfahrung hat mir gezeigt, dass globale Variablen eine sehr bösartige Fehlerquelle sein können. Programme, die alle benötigten Informationen als Parameter an Unterprogramme übergeben und die Ergebnisse wieder als Rückgabeparameter übernehmen, sind dagegen viel besser zu lesen. Auch wenn man mehr tippen muss.

Regel Nr 2: Vermeide das Kopieren von Coding!

Sowohl das Kopieren von ganzen Sourcen als auch von größeren Bereichen in Programmen verursacht gefährliche Redundanzen. Wenn an der kopierten Logik etwas zu ändern ist, muss man mehrfach ändern. Versuche also immer, ein Unterprogramm oder wenigstens ein Makro zu nutzen!

Regel Nr. 3: Gehe sparsam mit Kettenbefehlen um (write: / matnr, maktx, ... )

Macht man sich die Mühe, z.B. write-Befehle oder datas jeweils extra zu codieren, fällt später das Umstellen der Reihenfolge oder auch das Einfügen einzelner Anweisungen viel leichter. Einfach die Zeile mit der Maus verschieben! Ich benutze auch "new-line" anstatt "write /".

Für bestimmte Blöcke, Unterprogramm, Datenfelder, Historie Kommentar zu hinterlegen ist für mich eine goldene Regel:

Blöcke:
- was passiert in diesem logischen Block
- warum macht man manche Dinge so und nicht anders

Unterprogramm:
- Kurze Funktionsbeschreibung
- Parameter und mögliche Rückgabwerte

Datenfelder:
- halbwegs sprechende Namen (deutsch oder englisch)
- Namenskonventionen ('t' für Tabelle, 's' für Struktur/Workarea, Sichtbarkeit: 'g' global, 'l' lokal, 'p' parameter...)

Historie:
- im Kopf (wer hat, was, wann, wieso geändert)
- in den jeweiligen Zeilen (Zeilen nicht löschen, sondern nur auskommentieren ...)

uvm.

...

Grüße

Cray

Regel Nr 4: Verwende Typdefinitionen!

Die vereinfachte Form von DATA BEGIN OF /END OF, und DATA ... LIKE TABLE erzeugen Datenobjekte, die sich nicht typisiert an Unterprogramme übergeben lassen. Damit kommen wir auch schon zur...

Regel Nr 5: Verwende möglichst Parameter in Unterprogrammen (FORM...)

Es macht das Programm viel besser lesbar, wenn z.B. anstatt

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. perform material_lesen

GeSHi ©

dasteht:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. perform material_lesen using lv_matnr changing ls_mat

GeSHi ©

Die Routinen werden dadurch auch vielseitiger einsetzbar!

Regel Nr 6: Verwende Präfixe zur Verdeutlichung der Beschaffenheit von Variablen

meine aktuelle Nomenklatura ist:
GS_... Globale Struktur
GT_... Globale Tabelle
GV_... globale Einzelvariable
GC_... globale Konstante
LS_... Lokale Struktur usw.
US_... Using-Struktur
CS_... Changing-Struktur
Natürlich nur als Anregung. In größeren Teams ist allerdings eine einheitliche Festliegung sinnvoll.

Regel Nr 6: die goldenste Regel : Kommentare

Kommentare an den richtigen stellen. Kurz und bündig. Einleitende Kommentare + Dokumentation der Inserts & Delets inkl. Namen/Datum/Changeauftrag etc. je nach Organisation, aber einheitlich.

aber : keine Kommentarüberlastung.

Regel Nr 7: Übersichtlicher Programmierstil

- Pretty Printer verwenden (sofern möglich)
- aussagekräftige, kurze Variablen benutzen
- Funktionsbausteine nach Muster überflüssige Zeilen löschen
- etc.

.. so dass auch Andere oder ich selbst nach nem Jahr schnell erkenne, welche Bedeutung diese Programmzeilen haben

Eine kleine Anleihe aus einem Perl Buch: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."

Hallo,

meine goldene Regel zu internen Tabellen:

Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA: lt_tabelle TYPE irgendeine Tabelle.
2. FIELD-SYMBOLS: <lt_tabelle> LIKE LINE OF lt_tabelle.
3.  
4. * füllen
5. APPEN INTITIAL LINE TO lt_tabelle ASSIGNING <lt_tabelle>.
6. <lt_tabelle>-Feld1 = ...
7.  
8. LOOP AT lt_tabelle ASSIGNING <lt_tabelle>.
9. <lt_tabelle>-feld2 = ...
10. * mach sonstwas
11. ENDLOOP.
12.  
13. READ TABLE lt_tabelle assigning <lt_tabelle>
14. index Zahl.
15. * oder
16. ...
17. with key feld1 = 'XX'
18. .

GeSHi ©

Man "fährt" direkt auf der Tabellenzeile rum und muß sie nicht "modifyen".

Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. APPEND <lt_tabelle> to LT_TAB2 &#40;ASSIGNING <lt_tab2> "wenn man will"&#41;.

GeSHi ©

Gruß
babap

Auf Anfrage kann ich gerne per Mail eine komplette Programmierrichtlinie zuschicken, ist wirklich nützlich.

Performance Tips findet man unter:
SE38 -> Umfeld -> Beispiele -> Performance Beispiele
Ausserdem ist es wert das Trainingsmaterial BC490 - ABAP Performance Tuning sich zu besorgen.

Hier meine Lieblingsregeln:

- grössere Programme mit OO Technik implementieren
- bei Schleifen ASSIGNING <feldsymbol> statt INTO <variabel> verwenden. Bei grossen Tabellenzeilen ist es performanter, und so kann die Tabellenzeile direkt modifiziert werden, ohne aus einem Variabel zurückschreiben zu müssen.
- MESSAGE … RAISING statt RAISE verwenden - so erhält man gleich eine Fehlermeldung zu der Ausnahme
- keine Macros verwenden
- statt Literalketten Text Symbole oder andere übersetzbare Text Elemente verwenden
- Parametertypen der Semantik entsprechend auswählen (IMPORTING, EXPORTING, CHANGING, RETURNING), EXPORTING und RETURNING immer initialisieren

Lesbarkeit des Codes:

- die standard Namenskonventionen für Variabeln immer einhalten (gv_, lv_, ls_, lt_ usw.)
- alle Datendeklarationen immer am Anfang eines Forms oder Funktionsbausteins platzieren. ABAP reserviert sowieso den Speicher für einen Variabel, auch wenn es z.B. in einem IF Block ist, und theoretisch nicht immer erzeugt werden sollte.
- kein Coding in PBO oder PAI Modulen, hier möglichst nur Form-Aufrufe. In Modulen können keine lokale Variabeln deklariert werden, alle hier deklarierten Variabeln sind programmglobal.
- wenn es um ein Programm geht mit mehr Dynpros, ist der Prefix der Form Routinen die Screen-Nummer: f0100_, f0200_ usw. Auf dieser Weise sind die Forms im Navigationsbereich des SE80 einfach zu identifizieren. Das selbe mache ich manchmal auch mit globalen Variabeln: z.B. go_0100_alv_grid.
- um aus einer Routine, FuBa oder Methode auszusteigen immer RETURN verwenden. EXIT oder CHECK sollte nur in Schleifen verwendet werden. So werden die Anweisungen eindeutig.
- Kommentare gleich den Code einrücken
- ist nur geschmackssache, aber ich mag bei jedem MESSAGE den Meldungstext in Kommentar zu kopieren.

Die Deutschsprachige SAP-Anwendergruppe (DSAG) veröffentlichte 2013 einen Best-Practice-Leitfaden zum Schwerpunkt ABAP-Entwicklung.

Nicht nur für den Einsteiger eine tolle Sache...

http://www.dsag.de/ueber-dsag/presse/pr ... akt-1.html

http://www.dsag.de/fileadmin/media/Leit ... lash-Book/