Clean ABAP Teil 3/3
Nachdem ich Ihnen in den ersten beiden Teilen dieser Blogbeitragsreihe schon nähergebracht habe, was Clean ABAP ist, warum der Einsatz von Prinzipien für Clean Code auch ihn Ihrem Unternehmen lohnenswert ist und Ihnen bereits die wichtigsten Prinzipien gezeigt habe, werde ich in diesem Beitrag auf die noch verbleibenden Prinzipien eingehen, die Sie kennen sollten, um Ihre Entwicklung sauber zu strukturieren und gut lesbaren Quellcode zu produzieren.
Methoden
Funktionale Aufrufe vor prozeduralen Aufrufen
Wenn Sie Ihre Entwicklung an den Prinzipien von Clean ABAP orientieren, dann sollten Sie funktionale Methodenaufrufe verwenden. Der Aufruf einer Methode erfolgt also nicht mehr über den CALL METHOD Befehl. Das sorgt wieder dafür, dass unnötige Anweisungen vermieden werden und der Quellcode dadurch übersichtlicher wird.
Die Anzahl an Paramatern minimal halten
Wenn Ihre Methoden Paramater enthalten, dann sollte die Anzahl minimal gehalten werden, da sonst schnell die Übersichtlichkeit verloren geht. Clean ABAP setzt die Grenze bei drei Parametern pro Methode. Auch wenn das in der Realität schwer umzusetzen ist, sollten Sie sich dennoch bei der Erstellung Ihrer nächsten Methode fragen, ob die Anzahl der Parameter nicht reduziert werden kann.
RETURNING anstatt von EXPORTING
Die Nutzung von RETURNING-Parametern ermöglicht es, dass der Rückgabewert direkt einer Variablen zugeordnet werden kann, wodurch der Quellcode wieder schlanker und leichter lesbar wird.
Methoden haben immer eine Funktion
Wenn neue Methoden angelegt werden, dann sollten diese jeweils genau eine Funktion haben, um auf Dauer die Übersichtlichkeit zu gewährleisten und den Rumpf der Methode möglichst schlank zu halten und die Verständlichkeit zu erhöhen.
Kommentare
Code sollte für sich sprechen
Kommentare können hilfreich sein. Sie sollten aber nicht dafür genutzt werden, um offensichtliche Logik nochmals zusätzlich zu beschreiben. Wenn der Entwickler seinen Code an den Prinzipien von Clean ABAP ausgerichtet hat, dann kann die Anzahl an Kommentaren deutlich verringert werden, da der vorhandene Quellcode für sich spricht. Es gilt das Prinzip, dass Kommentare das “Warum” und nicht das “Wie” klar machen sollen.
Kommentare ersetzen keine anständigen Variablennamen
Anstatt den Sinn hinter einer Variable durch einen Kommentar zu erklären, sollten Sie bei der Benamung der Variable direkt eine treffende Bezeichnung wählen. Die Verwendung eines Kommentars an dieser Stelle ist meist Ausdruck davon, dass hier noch einmal nachgebessert werden sollte. Also nutzen Sie von Anfang an sprechende Namen, um Kommentare zur Erklärung von Variablen überflüssig zu machen.
Kommentare immer oberhalb des zugehörigen Codes platzieren
Kommentare sollten immer über dem zugehörigen Code platziert werden, um den Lesefluss nicht zu beeinträchtigen und Abhängigkeiten zwischen dem Quellcode und Kommentaren deutlich zu machen.
Nicht auskommentieren, sondern löschen
Wenn es einmal vorkommt, dass gewisse Passagen des Quellcodes nicht mehr benötigt werden, dann sollten diese auch wirklich gelöscht werden. Nichts macht den Code auf Dauer so unübersichtlich wie mehrere auskommentierte Stellen, die noch nicht gelöscht wurden, falls man sie irgendwann in ferner Zukunft noch einmal benötigt.
Formatierung
Pretty Printer verwenden
Nutzen Sie den Pretty Printer, um den Code vor dem Aktivieren zu formatieren. Dadurch werden sämtliche Statements direkt korrekt eingerückt und Schlüsselwörter werden groß geschrieben. Das zahlt sofort auf die Lesbarkeit des erzeugten Quellcodes ein.
Eine Anweisung pro Zeile
Auch wenn es für die Logik keinen Unterschied macht, sollten Sie sich dennoch auf eine Anweisung pro Zeile beschränken und nicht mehrere Anweisungen verketten. Auch dadurch ermöglichen Sie es Ihren Kollegen, Ihren Code leichter lesen und verstehen zu können.
Zeilenlängen beachten
Vor allem bei Select-Statements kann es häufig vorkommen, dass diese besonders lang werden und den Rahmen einer Zeile sprengen. Diese können Sie dann auch guten Gewissens auf mehrere Zeilen aufteilen, um die Lesbarkeit zu erhöhen.
Klammern am Ende der Zeile schließen
Wenn ihr Statement durch eine Klammer abgeschlossen wird, dann schließen Sie diese Klammer am Ende einer Zeile. Es ist nicht erforderlich, die Klammer in einer eigenen Zeile zu schließen. Das sorgt nur dafür, dass der Code unnötig lang wird.
Ich hoffe, dass ich Ihnen in dieser Blogbeitragsreihe näher bringen konnte, was Clean ABAP eigentlich ist, welche Vorteile es Ihnen bietet und welche Prinzipien der Thematik zugrunde liegen. Sollten Sie die Vorteile des Frameworks erkannt haben und es nun selbst in Ihre Entwicklungen einfließen lassen wollen, dann freue ich mich über Ihre Erfahrungsberichte in den Kommentaren. Sollten Sie Unterstützung benötigen oder weitergehende Fragen oder Anmerkungen haben, dann kommen Sie gerne auf mich zu. Meine Kollegen und ich stehen Ihnen mit Rat und Tat zur Seite.
