The magic of abapLint

Aus der Feder von Lars Hvam, dem Erfinder von abapGit, gibt es seit einiger Zeit ein weiteres geniales Tool. Es heißt abapLint. Mit diesem Tool ist es möglich, statische Syntaxprüfungen von ABAP-Quelltexten durchzuführen – und zwar ohne SAP-System! Aber der Reihe nach…

Was ist ein Linter?

Die SAP-Programmier-Welt ist ein eigenes Multiversum, in dem so einiges anders gemacht wird als in anderen Programmiersprachen und Entwicklungsumgebungen. Da ich mich seit Beendigung meiner Ausbildung als Fachberater Softwaretechniken fast ausschließlich mit SAP beschäftigt habe, sind mir viele Begriffe aus der „normalen“ Entwicklungswelt gar kein Begriff. Als ich im Zusammenhang mit abapLint das erste Mal den Begriff „Linter“ hörte, musste ich nachschlagen, was das wohl sein könnte.

Für alle diejenigen, die dem Begriff Linter ebenso ratlos gegenüberstehen, ein kurzer Ausflug in die Vergangenheit: Linter wurden erfunden, um die Schwächen der damaligen Compiler auszugleichen. Die Compiler verlangten einerseits fehlerfreies Coding, erkannten andererseits jedoch wichtige Abhängigkeiten nicht. Zudem war es dem Compiler egal, wie der Quelltext aussah. Ursprünglich für C wurde das Programm lint entwickelt, das erweiterte Programmprüfungen vornahm. Der Begriff wurde dann auch für andere Programmiersprachen verwendet.

Ein Linter führt statische Analysen durch und erkennt formale Fehler. Also genau das, was auch die ABAP-Syntaxprüfung tut. Die Prüfungen des ABAP-Compilers reichen aus, um zu gewährleisten, dass ein Programm frei von Syntaxfehlern ist. Allerdings benötigt man dafür immer ein SAP-System.

Da viele wichtige Dinge jedoch von der Syntaxprüfung nicht erkannt werden, stellt SAP weitere Tools zur Verfügung, wie zum Beispiel:

• Die erweiterte Programmprüfung SLIN
• Den Code-Inspector
• Paketprüfungen

Typische Fehler, die dem Syntaxcheck egal sind, jedoch zu Problemen bei der Programmausführung führen, sind beispielsweise:

• Falscher Parametername beim Aufruf von Funktionsbausteinen
• Verwendete Meldungsnummer ist nicht vorhanden oder hat eine abweichende Parameteranzahl

Was leistet abapLint?

Wenn SAP bereits jede Menge Hilfen zur Verfügung stellt, um Programme und Klassen umfassend zu prüfen, wozu benötige ich dann abapLint?

abapLint ist ein Open-Source-Projekt. Das bedeutet, dass sich jeder beteiligen und weitere Prüfungen beitragen kann. Während die SAP-Tools sich in erster Linie auf funktionale Prüfungen beschränken, bietet abapLint eine Vielzahl von Regeln, die sich auf die Lesbarkeit und Standardisierung von Quelltext konzentrieren. Verschiedene Prüfungen weisen darauf hin, wenn standardisierte Code-Formatierungen nicht eingehalten wurden.

Die Regeln orientieren sich eng am Clean-ABAP-Styleguide der SAP. Genau das sind die Prüfungen, die man in den SAP-Tools vergeblich sucht.

Beispiele für Prüfungen, die abapLint bezüglich Clean-Code durchführt:

• Hinweis, wenn das EXPORTING-Schlüsselwort beim Aufruf einer Methode entfallen kann (EXPORTING can be omitted)
• Sicherstellen, dass sich zwischen dem letzten Befehl und dem abschließenden Punkt keine Leerzeichen befinden (Space before dot)
• NEW-Konstrukt gegenüber CREATE OBJECT bevorzugen (Use NEW)

Andere hilfreiche Regeln:

• Vermeidung von Yoda-Ausdrücken (No Yoda Conditions): IF 0 = sy-subrc
• Sicherstellen, dass vor einem Call Transaction eine Berechtigungsprüfung erfolgt (Call Transaction Authority-Check)
• Inline-Deklarationen bevorzugen (Prefer Inline Declarations)
• Unerwünschte Anweisungen finden (Avoid use of certain statements). Beispielsweise kann die Prüfung eingeschaltet werden, damit Tabellendeklarationen WITH DEFAULT KEY gefunden werden. Die Anweisung ist bei Standardtabellen unsinnig. Es sollte besser WITH EMPTY KEY verwendet werden, wenn der Schlüssel nicht benötigt wird.

Die verfügbaren Regeln (aktuell sind es 163) sind dokumentiert und können online auf dem abapLint-Spielplatz ausprobiert werden.

Verwendung auf github

abapLint integriert sich in die Oberfläche von github. Ein kleines unscheinbares „X“ zeigt an, wenn Prüfungen fehlgeschlagen sind:

Sie können auf das X klicken und erhalten daraufhin eine Liste mit Details zu den fehlgeschlagenen Prüfungen:

Über die Datei abaplint.json, welche im Hauptverzeichnis des Repositories liegen muss, kann eingestellt werden, welche Prüfungen ausgeführt werden sollen.

Abgrenzung zu ABAP-Cleaner

Das Open-Source-Projekt ABAP-Cleaner schlägt teilweise in die gleiche Kerbe wie abapLint. Es findet Konstrukte, die hinsichtlich des Clean-Code-Leitfadens nicht gewünscht sind und behebt diese auch gleich. Der ABAP-Cleaner ist ein reines Eclipse-Plugin und verfolgt damit einen anderen Ansatz als abapLint.

Abgrenzung zu SAP-Code-Pal

Das Open-Source-Projekt SAP-Code-Pal hat ebenfalls zum Ziel, die Code-Qualität zu verbessern. Das Projekt ist in Github verfügbar und importiert zusätzliche Prüfregeln in den Code-Inspector, die dort aktiviert werden können.

abaplint.app

Unter der Internetadresse https://abaplint.app/stats sind alle öffentlich verfügbaren ABAP-Repositories von github.com aufgelistet. Die App zeigt, welche zusätzlichen Möglichkeiten abapLint bietet. Zu jedem Repository werden die Issues aufgelistet, die apapLint gefunden hat.

Der Zugriff mit der abapLint-App ist auf öffentliche Repositories kostenfrei. Wenn Sie die App für private Repositories nutzen möchten, ist eine Gebühr von derzeit $19 pro Benutzer und Monat notwendig, die über den Github-Account bezahlt werden muss.

Zu den Repositories gibt es interessante Kennzahlen wie:

• Methodenlänge
• Methodenkomplexität

Die Methodenlänge zeigt übersichtlich, wie viele Methoden es mit wie vielen Anweisungen gibt. Unter der Grafik werden die Methoden aufgelistet, absteigend nach der Anzahl der Zeilen. Das folgende Beispiel stammt aus dem Projekt ABAP2UI5:

Es bietet sich bei Refaktorierungen an, bei den Methoden mit vielen Anweisungen zu beginnen, da hier die Wahrscheinlichkeit sehr hoch ist, dass einzelne Anweisungsblöcke ausgelagert werden können.

Sehr interessant finde ich die Kompatibilitäts-Sicht. Hier wird dargestellt, mit welchen SAP-Releases der Quelltext kompatibel ist.

Hier ein Beispiel vom :

Unter dem Diagramm werden die jeweils zum Release inkompatiblen Anweisungen aufgeführt.

Ebenfalls hilfreich finde ich die Übersicht Void Types, in der die verwendeten Datentypen aufgelistet werden. Zusätzlich werden hier Informationen darüber aufgezeigt, ob die Datentypen für Cloud freigegeben oder als veraltet gekennzeichnet sind. Wenn es einen offiziellen Nachfolger gibt, wird dieser ebenfalls aufgelistet. Hier ein Beispiel vom Coding unseres ABAP-Kochbuchs:

Ebenfalls sehr aufschlussreich und ein guter Indikator, wie sich ein Projekt entwickelt, sind die Kennzahlen durchschnittliche Komplexität und durchschnittliche Methodenlänge. Der folgende Screenshot aus dem ABAP2XLSX-Projekt zeigt sehr schön, dass sich die durchschnittliche Methodenlänge im Laufe der Zeit verringert hat:

Ein Indikator dafür, dass sich die Code-Qualität verbessert hat.

Relativ neu hinzugekommen ist der Intra Class Call Graph, der ein Sequenzdiagramm innerhalb einer Methode aufzeigt. Hier erneut ein Beispiel aus dem ABAP2XLSX-Projekt:

War das etwa schon alles?

Mitnichten. Eigentlich fängt es hier erst an. Mit der abapLint-Initiative hat Lars ein eigenes Universum mit vielen Möglichkeiten geschaffen. So geht es weiter:

• Einbindung abapLint in VSCode
• ABAP-Anweisungsdiagramme zu jedem Befehl
• abapLint Transpiler: Ausführung von ABAP-Code im Browser mittels Javascript

Der abapLint-Transpiler ermöglicht es, ABAP auf einem Raspberry Pi laufen zu lassen, oder dass ABAP als Sprache bei Exercism verfügbar ist.

Wer sich für die weiteren Entwicklungen interessiert, sollte Lars auf LinkedIn folgen. Er postet hier in unregelmäßigen Abständen interessantes rund um ABAP-Programmierung.