ABAP - Namenskonventionen
Wie wichtig sind heutzutage noch die Einhaltung von Namenskonventionen oder überhaupt die Verwendung von Namenskonventionen im modernen ABAP Umfeld? Das wollen wir uns in diesem Artikel anschauen.
Inhaltsverzeichnis
In diesem Artikel wollen wir uns einmal das Thema Namenskonvention anschauen und wie man mit dieser in der heutigen Zeit noch umgehen sollte. Sind diese Konventionen überhaupt noch zeitgemäß oder sollten sie so, wie formbasierte Reports, einmal überarbeitet werden?
Clean ABAP
Mit Clean Code oder auch Clean ABAP versucht SAP langsam etwas mehr Ordnung in den ABAP Code zu bringen und unserer Meinung nach, ist das auch wichtig, um vielen alten Balast aus der Vergangenheit loszuwerden. Daneben sind seit Jahren auch schon Unit Tests mit ABAP Unit im kommen und Webtechnologien wie REST Services und ODATA Schnittstellen bestimmen mehr und mehr das Bild der modernen Landschaft. Sogenannte Microservice Architekturen sind ein Beweis dafür, keine monolitischen Systeme mit allen Funktionen vorzuhalten, sondern Services zur Verfügung zu stellen, die dann konsumiert werden können.
Mit dem Manifest möchte SAP dir Hinweise geben, wie du in Zukunft sauberen Quellcode schreibst, auf die modernen Prinzipien der Objektorientierung setzt und eben wie du die Namenskonventionen in Zukunft einsetzt.
Namenskonventionen
Im Dokument wird im Kapitel "Names" beschrieben, dass ihr keine Ungarische Notation oder sonstige Encodings mehr verwenden sollt. Dazu liefert SAP noch eine ganze Unterseite, wieso ihr diese Konventionen nicht benötigt und wieso ihr lieber auf keine Konvention setzen solltet. Daraus die drei Punkte zusammengefasst:
- Altes Relikt - Code wurde früher oft ausgedruckt und gelesen, dabei wollte man das Suchen nach Variablendefinitionen oder das Blättern vermeiden und jeder Variable ansehen, was für ein Datentyp dahinter steckt und welchen Sinn diese hat.
- Länge - Für gewissse Typen und Namen gibt es Begrenzungen der Länge, sodass du nicht immer einen sprechenden Namen vergeben kannst. Somit würdest du einige Zeichen sparen, um deinen Wunschnamen zu vergeben.
- Namenskonflikte - Verschattung von Variablen beachten (mehr siehe unten).
Was gibt es eigentlich noch zu beachten dabei? ABAP unterstützt leider kein CamelCase, wie zum Beispiel "getCompanyCode", sondern du musst mit Unterstrichen arbeiten und erhältst "get_company_code". Nicht unbedingt ein negativer Aspekt, wird aber Entwickler aus anderen Bereichen erst einmal vor den Kopf stoßen mit der Lesbarkeit.
Namensräume
Doch eigentlich ist mal als ABAP Entwickler immer an den Namensraum von SAP gebunden und kann nur die freigegebenen Namespaces verwenden. So kannst du typischerweise nur Objekte im Y oder Z Namensraum erzeugen und hast damit auch eine Vorgabe, wie deine Objekte beginnen müssen. Ebenso wenn dein Unternehmen einen eigenen Namespace hat "/NSPC/", dann bist du erst einmal an diese gebunden.
Innerhalb der Objekte hast du dann entsprechend deine Freiheiten und darauf bezieht sich im Großteil auch das Kapitel, wie du deine Variablen und Schnittstellen innerhalb eines Objekts benennst und verwendest.
Gründe
Wie sieht es nun eigentlich mit den Vor- und Nachteilen bei der Verwendung der jeweiligen Alternative aus? In der Welt der Entwicklung setzen die meisten Sprachen auf keine Namenskonventionen und du erkennst den Typ und die Verwendung am Namen und den entsprechenden Entwicklertools.
Für Namenskonventionen
- Geben klare Richtlinien für eine Grundbenennung von Variablen und Schnittstellen vor, sodass auch "faule" Kollegen eine gewisse Routine mitbringen müssen.
- Sie können automatisch mit Hilfe des ATC validiert werden, was mit freier Namensgebung ohne Review nicht möglich wäre.
- Ist bereits in der Standard-Routine des Entwicklers enthalten.
Für Clean ABAP
- Sprechender Code und Vermeidung von Abkürzungen, was den Code lesbarer, ohne viele Kommentare, macht.
- State of the Art der Entwicklung in sehr vielen anderen Sprachen.
- Untersützung durch die ABAP Development Tools (ADT) zur Feststellung der Typisierung.
Verschattung
Wie sieht es dann mit der Verschattung von Variablen aus? Eine Verschattung ist dann der Fall, wenn eine Variable lokal definiert wird, die den gleichen Namen hat wie eine Variable im globalen Kontext. Dann kannst du je nach Art des Objekts nicht mehr auf die globale Variable zugreifen, sondern nur noch auf die lokale Definition. Hier mal ein Beispiel:
CLASS zcl_bs_demo_shadowing DEFINITION PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES if_oo_adt_classrun.
METHODS:
constructor.
PROTECTED SECTION.
PRIVATE SECTION.
DATA:
name TYPE string,
age TYPE i.
ENDCLASS.
CLASS zcl_bs_demo_shadowing IMPLEMENTATION.
METHOD constructor.
name = 'John Doe'.
age = 18.
ENDMETHOD.
METHOD if_oo_adt_classrun~main.
DATA(name) = 'Jane Doe'.
DATA(age) = 20.
out->write( name ).
out->write( age ).
ENDMETHOD.
ENDCLASS.
Im Konstruktor initialisieren wir die Variablen "name" und "age", die dann als Member im Objekt verfügbar sind. In der Main Methode definieren wir lokale Variablen mit dem gleichen Namen und weisen eigene Werte zu. Ab diesem Zeitpunkt können wir über den gleichen Namen nicht mehr auf die Variablen zugreifen und bei der Ausgabe wird dann "Jane" ausgegeben. Um dann wieder auf die globalen Variablen zugreifen zu können, musst du mit der Selbstreferenz arbeiten.
out->write( me->name ).
out->write( me->age ).
An dieser Stelle wirst du dir wahrscheinlich selbst denken, mit der entsprechenden Notation wäre das eigentlich kein Problem gewesen. Die Member beginnen mit M und die lokalen Variablen mit L, damit würde dieses Problem in einer Welt mit Namenskonventionen nicht entstehen.
Fazit
Aktuell ist die Verwendung von Namenskonventionen in vielen Unternehmen noch gesetzte Sache, das ABAP Test-Cockpit (ATC) unterstützt dabei automatisch, dass die Regeln eingehalten werden. Wenn in Zukunft immer mehr Entwicklungen auf den Clean ABAP Ansatz setzen werden, muss dies vor allem durch ausgebildete Entwickler und Code Reviews abgesichert werden, ansonsten wird die Code Qualität darunter leiden.
Quellen:
Clean ABAP (Github)
