Goldene Regeln der Programmierung
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:
(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)
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)
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
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 /".
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 /".
Jörg Krause, Anwendungsentwickler und SAP-Betreuer MM/PP
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
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
dasteht:
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.
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: Alles auswählen.
perform material_lesenCode: Alles auswählen.
perform material_lesen using lv_matnr changing ls_matRegel 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.
Jörg Krause, Anwendungsentwickler und SAP-Betreuer MM/PP
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
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
Hallo,
meine goldene Regel zu internen Tabellen:
Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.
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
Gruß
babap
meine goldene Regel zu internen Tabellen:
Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.
Code: Alles auswählen.
DATA: lt_tabelle TYPE irgendeine Tabelle.
FIELD-SYMBOLS: <lt_tabelle> LIKE LINE OF lt_tabelle.
* füllen
APPEN INTITIAL LINE TO lt_tabelle ASSIGNING <lt_tabelle>.
<lt_tabelle>-Feld1 = ...
LOOP AT lt_tabelle ASSIGNING <lt_tabelle>.
<lt_tabelle>-feld2 = ...
* mach sonstwas
ENDLOOP.
READ TABLE lt_tabelle assigning <lt_tabelle>
index Zahl.
* oder
...
with key feld1 = 'XX'
.Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen
Code: Alles auswählen.
APPEND <lt_tabelle> to LT_TAB2 (ASSIGNING <lt_tab2> "wenn man will").babap
(meine) Regel Nr. 7: Klassen verwenden
Die Verwendung von Reports mit Form-Routinen wurde von SAP durch das wesentlich bessere Konzept von Klassen und Methoden abgelöst. Ich vermeide, wo es geht, überhaupt Reports anzulegen. Muss ich einen Online-Report schreiben, lege ich eine Klasse mit einer MAIN-Methode an, die ich direkt mit der Transaktion verknüpfe. Alles weitere mache ich dann in den Methoden der Klasse.
Da Hintergrundprogramme doch einen Report benötigen, lege ich in diesem Fall immer einen minimal-Report an:
Das mache ich auch, wenn ich einen Selektionsschirm benötige (obwohl man den auch in eine function library packen könnte...)
Regel Nr. 8: Trenne Verarbeitungslogik von Bildschirmlogik
Ein Beispiel: In einem Programm soll eine Materialnummer abgefragt werden, für die daraufhin eine Anzeige von ausgewählten Materialstammfeldern erfolgen soll. In so einem Fall lege ich einen Funktionsbaustein an, der das Dynpro ruft:
Das Dynpro 1 ist so gehalten, dass es bei jeder Benutzerinteraktion sofort einen set screen 0 macht. Die rufende Methode macht dann in etwa folgendes:
Der Vorteil? Auf diese Weise entstehen Klassen mit der Verarbeitungslogik, die man problemlos an anderen Stellen verwenden kann (z.B. für Webdynpro, RFC-Calls oder sonstiges).
Die Verwendung von Reports mit Form-Routinen wurde von SAP durch das wesentlich bessere Konzept von Klassen und Methoden abgelöst. Ich vermeide, wo es geht, überhaupt Reports anzulegen. Muss ich einen Online-Report schreiben, lege ich eine Klasse mit einer MAIN-Methode an, die ich direkt mit der Transaktion verknüpfe. Alles weitere mache ich dann in den Methoden der Klasse.
Da Hintergrundprogramme doch einen Report benötigen, lege ich in diesem Fall immer einen minimal-Report an:
Code: Alles auswählen.
report ...
parameters p_mypar as checkbox.
data go_myapp type ref to zcl_myapp.
start-of-selection.
create object go_myapp.
go_myapp->set_mypar( p_mypar ).
go_myapp->main( ).
Regel Nr. 8: Trenne Verarbeitungslogik von Bildschirmlogik
Ein Beispiel: In einem Programm soll eine Materialnummer abgefragt werden, für die daraufhin eine Anzeige von ausgewählten Materialstammfeldern erfolgen soll. In so einem Fall lege ich einen Funktionsbaustein an, der das Dynpro ruft:
Code: Alles auswählen.
* Eingabeparameter des FUBA: is_screen
* Ausgabeparameter: es_screen, ev_ucomm
* Die Funktionsbibliothek verwaltet die Bildschirmdaten als globale Struktur:
gs_screen = is_screen.
call screen 1.
es_screen = gs_screen.
ev_ucomm = sy-ucomm.
Code: Alles auswählen.
do.
call function 'Z_SHOW_THE_SCREEN'
exporting
is_screen = ls_screen_defaults
importing
es_screen = ls_screen_inputs
ev_ucomm = lv_user_command.
process_input( ls_screen_inputs ).
lv_exit = process_user_command( lv_user_command ).
if lv_exit = abap_true.
exit.
endif.
enddo.
Jörg Krause, Anwendungsentwickler und SAP-Betreuer MM/PP
Meine Regeln:
Regel 1:
Verwende möglichst Klassen und Methoden statt Funktionsgruppen und FuBa's
Regel 2:
Manipuliere in einer Methode keine globalen Variablen, sondern nur Aktualparameter.
Regel 3:
Manipuliere Standardtabellen niemals direkt, sondern immer per Batch-Input.
Regel 4:
Übergebe Variablen soweit sinnvoll (und nicht zu riskant) immer per Referenz.
Regel 5:
Verwende Feldsymbole statt Workareas, es sei denn du benötigt noch eine Prüfung,
bevor du entscheidest, ob du die Tabelle aus dem Workarea updatest oder
ob du die manipulierten Daten aus dem Workarea verwirft.
Regel 6:
Verwende nie die Listenausgabe per write, sondern verwende immer eine ALV.
Regel 7:
Bezieh dich bei der Variablen-Deklaration immer auf auf eine Dict-Typ,
falls kein passender vorhanden ist; lege einen an und versorge Ihn mit den
entsprechenden Metadaten, Übersetzungen und Dokumentationen.
Regel 1:
Verwende möglichst Klassen und Methoden statt Funktionsgruppen und FuBa's
Regel 2:
Manipuliere in einer Methode keine globalen Variablen, sondern nur Aktualparameter.
Regel 3:
Manipuliere Standardtabellen niemals direkt, sondern immer per Batch-Input.
Regel 4:
Übergebe Variablen soweit sinnvoll (und nicht zu riskant) immer per Referenz.
Regel 5:
Verwende Feldsymbole statt Workareas, es sei denn du benötigt noch eine Prüfung,
bevor du entscheidest, ob du die Tabelle aus dem Workarea updatest oder
ob du die manipulierten Daten aus dem Workarea verwirft.
Regel 6:
Verwende nie die Listenausgabe per write, sondern verwende immer eine ALV.
Regel 7:
Bezieh dich bei der Variablen-Deklaration immer auf auf eine Dict-Typ,
falls kein passender vorhanden ist; lege einen an und versorge Ihn mit den
entsprechenden Metadaten, Übersetzungen und Dokumentationen.
No 1. Hole aus der Datenbank nur das, was du wirklich brauchst.
statt
statt
No 2. Hole 1x ganze customizing Tabelle, als 100x das gleiche aus Datenbank lesen.
No 3. Entsprechenden Tabellentyp nutzen.
Hashed für customizing.
Sorted für die Tabellen, wo ich ein LOOP oder READ TABLE mache.
Standard für den Rest.
No 4. Tabellenoperationen verwenden.
Code: Alles auswählen.
SELECT COUNT(*)Code: Alles auswählen.
SELECT SINGLE *Code: Alles auswählen.
SELECT ... field1 field2...Code: Alles auswählen.
SELECT *Code: Alles auswählen.
INITIALIZATION.
SELECT field1 field2
INTO TABLE gt_t...
FROM t...
FORM ....
READ TABLE gt_t...Hashed für customizing.
Sorted für die Tabellen, wo ich ein LOOP oder READ TABLE mache.
Standard für den Rest.
No 4. Tabellenoperationen verwenden.
Code: Alles auswählen.
TYPES: BEGIN OF t_matnr,
matnr type matnr,
END OF t_matnr.
DATA: gt_mara TYPE TABLE OF mara,
gt_matnr TYPE TABLE OF t_matnr.
....
gt_matnr = gt_mara.
bei diesem Beispiel bin ich nicht der Meinung, dass es das Ergebnis erzielt, welches beabsichtigt ist.kotelna hat geschrieben:...
No 4. Tabellenoperationen verwenden.Code: Alles auswählen.
TYPES: BEGIN OF t_matnr, matnr type matnr, END OF t_matnr. DATA: gt_mara TYPE TABLE OF mara, gt_matnr TYPE TABLE OF t_matnr. .... gt_matnr = gt_mara.
Wenn ich es richtig verstehe, soll die Materialnummer von der GT_MARA in die GT_MATNR übertragen werden. Das kann aber so m.E. nicht funktionieren, denn die Struktur MARA hat als erstes Feld den Mandanten und dann erst kommt die Materialnummer.
Gruß
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
babap hat geschrieben:Hallo,
meine goldene Regel zu internen Tabellen:
Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.Man "fährt" direkt auf der Tabellenzeile rum und muß sie nicht "modifyen".Code: Alles auswählen.
DATA: lt_tabelle TYPE irgendeine Tabelle. FIELD-SYMBOLS: <lt_tabelle> LIKE LINE OF lt_tabelle. * füllen APPEN INTITIAL LINE TO lt_tabelle ASSIGNING <lt_tabelle>. <lt_tabelle>-Feld1 = ... LOOP AT lt_tabelle ASSIGNING <lt_tabelle>. <lt_tabelle>-feld2 = ... * mach sonstwas ENDLOOP. READ TABLE lt_tabelle assigning <lt_tabelle> index Zahl. * oder ... with key feld1 = 'XX' .
Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen
GrußCode: Alles auswählen.
APPEND <lt_tabelle> to LT_TAB2 (ASSIGNING <lt_tab2> "wenn man will").
babap
Ebenfalls auch eine gute Möglichkeit welche kein Modify benötigt sind Referenzen.
Code: Alles auswählen.
DATA: lt_tadir type table of tadir,
doceX hat geschrieben:babap hat geschrieben:Hallo,
meine goldene Regel zu internen Tabellen:
Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.Man "fährt" direkt auf der Tabellenzeile rum und muß sie nicht "modifyen".Code: Alles auswählen.
DATA: lt_tabelle TYPE irgendeine Tabelle. FIELD-SYMBOLS: <lt_tabelle> LIKE LINE OF lt_tabelle. * füllen APPEN INTITIAL LINE TO lt_tabelle ASSIGNING <lt_tabelle>. <lt_tabelle>-Feld1 = ... LOOP AT lt_tabelle ASSIGNING <lt_tabelle>. <lt_tabelle>-feld2 = ... * mach sonstwas ENDLOOP. READ TABLE lt_tabelle assigning <lt_tabelle> index Zahl. * oder ... with key feld1 = 'XX' .
Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen
GrußCode: Alles auswählen.
APPEND <lt_tabelle> to LT_TAB2 (ASSIGNING <lt_tab2> "wenn man will").
babap
Ebenfalls auch eine gute Möglichkeit welche kein Modify benötigt sind Referenzen.
Code: Alles auswählen.
DATA: lt_tadir type table of tadir,
Zusatz zum obigen Beitrag
*Wurde zu früh gesendet 
Code: Alles auswählen.
DATA: lt_tadir type table of tadir,Code: Alles auswählen.
lr_tadir type ref to tadir.Code: Alles auswählen.
DATA: l_obj_name type sobj_name.Code: Alles auswählen.
LOOP AT lt_tadir REFERENCE INTO lr_tadir.Code: Alles auswählen.
l_obj_name = lr_tadir->obj_nameCode: Alles auswählen.
ENDLOOP.Vergleichbare Themen
1
Antw.
Antw.
1794
Views
Views
2
Antw.
Antw.
991
Views
Views
SAP Entwicklungssystem und RFC Programmierung
von sNud » 28.08.2021 13:36 • Verfasst in ABAP® für Anfänger
von sNud » 28.08.2021 13:36 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
2180
Views
Views
0
Antw.
Antw.
1306
Views
Views
SAP Workflow Programmierung
von Yeliz92 » 25.01.2018 12:59 • Verfasst in Material Management & Produktionsplanung
von Yeliz92 » 25.01.2018 12:59 • Verfasst in Material Management & Produktionsplanung
0
Antw.
Antw.
1452
Views
Views
Unicodevorgaben bei der Programmierung
von JürgenFFM » 07.11.2007 11:29 • Verfasst in Dialogprogrammierung
von JürgenFFM » 07.11.2007 11:29 • Verfasst in Dialogprogrammierung
Frage die ABAP Experten
Über diesen Beitrag
- zzcpak
- joachim
- cosmo
- crayfish
- Anonymous
- M. Lahr
- babap
- Alpha
- UserBC
- kotelna
- ereglam
- doceX
- ralf.wenzel
- foessleitnerj
- a-dead-trousers
- black_adept
- ewx
- erp-bt
- Pyro
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.