Goldene Regeln der Programmierung

Hinweise, Tips und Tricks, FAQs - keine Anfragen!!

Goldene Regeln der Programmierung

Postby Laureen5398 » Wed Jun 07, 2006 11:27 am

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)
Laureen5398
...
...
 
Posts: 335
Joined: Thu Jul 31, 2003 10:47 am

goldene regel

Postby Justine2264 » Fri Jun 09, 2006 9:29 am

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

auswertung via se30 freizugeben


joachim
Justine2264
...
...
 
Posts: 216
Joined: Fri Oct 01, 2004 10:01 am

Postby Lucienne935 » Thu Sep 28, 2006 4:07 pm

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 /".
Lucienne935
...
...
 
Posts: 162
Joined: Mon Sep 20, 2004 3:26 pm

Kommentare im Code

Postby Lukas943 » Sat Jan 27, 2007 7:54 pm

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
Lukas943
..
..
 
Posts: 16
Joined: Wed Aug 18, 2004 2:06 pm

Postby Lucienne935 » Mon Apr 02, 2007 9:11 am

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.
Lucienne935
...
...
 
Posts: 162
Joined: Mon Sep 20, 2004 3:26 pm

Postby Holly2100 » Mon Apr 02, 2007 10:03 am

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 :)
Holly2100
.
.
 
Posts: 7
Joined: Thu Jan 19, 2006 5:17 pm

Postby Roman2791 » Mon Apr 02, 2007 7:38 pm

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."
Roman2791
...
...
 
Posts: 106
Joined: Sun Mar 05, 2006 11:11 am

Postby Erich410 » Tue May 27, 2008 8:25 am

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.  
  12. READ TABLE lt_tabelle assigning <lt_tabelle>
  13. index Zahl.
  14. * oder
  15. ...
  16. with key feld1 = 'XX'
  17. .
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
Erich410
....
....
 
Posts: 680
Joined: Thu Feb 05, 2004 4:22 pm

Re: Goldene Regeln der Programmierung

Postby Alexandra1568 » Sat Jan 14, 2012 11:29 am

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.
Alexandra1568
.
.
 
Posts: 4
Joined: Thu Sep 22, 2011 3:14 pm

Re: Goldene Regeln der Programmierung

Postby Tarek1391 » Mon Sep 30, 2013 12:09 pm

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/
Tarek1391
...
...
 
Posts: 132
Joined: Fri Nov 18, 2005 3:01 pm


Return to Tips + Tricks & FAQs

Who is online

Users browsing this forum: No registered users and 2 guests

cron