Programmierrichtlinien

Es sei auf das gute Buch ABAP-Programmierrichtlinien (siehe Bücherrezension) hingewiesen. Hier im folgenden nur ganz knapp einige wenige essentielle Hinweise für den Eigengebrauch.

Eine Programmierrichtlinie geht deutlich über eine reine Namenskonvention hinaus. Auch Regeln zum Programmaufbau, zur Modularisierung, zur Nichtverwendung gewisser Sprachelemente und anderes gehören zu einer Programmierrichtlinie. Im Endeffekt erzeugen sie einen einheitlichen Programmierstil. Und genau das ist das Ziel. 

• es wird international = englischsprachig programmiert und im Programm dokumentiert
• nur englischsprachige Variablennamen erzeugen
• nur englischsprachige Routinen, Funktionsbausteine etc. erzeugen
• natürlich den neuen Frontend-ABAP-Editor verwenden, Einstellung:
  • alle Syntaxfehler anzeigen
  • abwärtskompatible Zeilenlänge [wenn möglich]
• Pretty Printer konsequent verwenden. Einstellung:
  • Einrücken verwenden
  • keinen Standardkommentar einfügen
  • Groß-Kleinkonvertierung für Schlüsselwörter groß verwenden
• im Registerblatt Muster anhaken:
  • Fubaus: Name Aktualparameter gleich Name Formalparameter
  • Fubaus: Bei Ausnahmeklassen CALL FUNCTION mit TRY...ENDTRY generieren
  • Class Builder: Name Aktualparameter gleich Name Formalparameter
  • Funnktionale Schreibweise für Call METHOD
• Selbstverständlich im Editor dann auch den 'Muster'-Button verwenden
• eweiterte Programmprüfung (mit allem angehakt) verwenden. Es muss komplett 'grün' sein!
• Code-Inspektor verwenden
• pro Codingzeile nur eine Anweisung

 

• Namensgebung (Bestandteile werden durch Unterstrich getrennt, sprechende Namen verwenden):
  • cl_ = Klassen, z.B. cl_demo_update
  • if_ = Interfaces, z.B. if_demo_update
  • is_ = Wahrheitswert, z.B. is_checked
  • on_ = Ereignisbehandler, z.B. on_button_klicked
  • get_ = Methoden mit Rückgabewert, z.B. get_max_count
  • do_ = auszuführende Methode, z.B. do_this_work
  • set_ = auszuführende Methode, z.B. set_this_value
  • cx_ = Ausnahmemethode, z.B. cx_value_not_allowed 
• Programminterne Namensgebung:
  • g_ = globales Datenobjekt, z.B. g_dataobject
  • l_ = lokales Datenobjekt, z.B. l_dataobject
  • i_ = Importing-Parameter, z.B. i_vebln
  • e_ = Exporting-Parameter, z.B. e_vbeln
  • c_ = Changing-Parameter, z.B. c_count
  • r_ = Returning-Parameter, z.B. r_value
• Datentypen Namensgebung:
  • e oder v = elementare Type, z.B. lv_help_count (lokale Variable Help_count)
  • s = Strukturen. z.B. gs_structure (globale Struktur 'structure')
  • t = Tabelle, z.B. lt_return (lokale Tabelle für Return-Werte)
  • r = Datenreferenzvariablen
  • o = Klassenreferenzvariablen
  • i = Interface-Referenzvariablen
  • b = BADI-Referenzvariablen
  • x = Ausnahmeklassen-Referenzvariablen

 

• Kommentare: viel und reichlich verwenden!
  • * - am Beginn jeden größeren Abschnittes
  • " - z.B. an einem Endif: endif. " sy-subrc = 0. ' select mara
  • Kommentare sollten natürlich auch in Englisch sein
  • 7-bit ASCII-Zeichen verwenden, also z.B. keine Umlaute
  • kein Sprachmischmatsch
  • beschreiben warum etwas gemacht wird, nicht wie
  • es kann nicht zu viel kommentiert werden!
  • Kommentare vor Kontrollanweisungen (z.B. vor if / when) beziehen sich auf die Bedingung
  • Kommentare nach Kontrollanweisungen (z.B. nach if, else) beziehen sich auf den jeweiligen Block
  • Kommentarzeilen genauso tief einrücken wie die Anweisungen auf die sie sich beziehen 

 

• Modularisierung
  • Includes können separat von verschiedenen Programmierern entwickelt und auch transportiert werden
  • gleiche / fast gleiche Coding auslagern: perform mit Wertübergabe
  • Kapselung in Funktionsbausteine