Transaktion SLIN (erweiterte Syntaxprüfung)

Mit der Transaktion SLIN oder aus dem Programm (Transaktionen SE38, SE80, SE37, SE24) lässt sich die sogenannte "erweiterte Syntaxprüfung" durchführen. Für eine Codingeinheit (Programm, Funktionsgruppe oder Klasse) werden hier tiefergehende Prüfungen durchgeführt, die die reguläre Syntaxprüfung aus Performancegründen nicht durchführt.

Die Durchführung der erweiterten Syntaxprüfung kann nur dringend empfehlen werden. Auch als erfahrenem SAP-Entwickler wird man hier auf Codingstellen hingewiesen, die mindestens überflüssiges Coding oder sogar logische Fehler beinhalten. Der Aufwand von vielleicht einer Stunde bei der Durchführung der Prüfung und der Behebung der Hinweise ist sehr gut investierte Zeit. Andere Entwickler werden diese Prüfung in fremden Programmen in aller Regel nicht mehr durchführen, da die berechtigte Befürchtung da sein wird bei den Korrekten auch Fehler einzubauen und dann die Frage kommen könnte "Warum hast du diese Stelle geändert? Sie hatte doch gar nichts mit der gewünschten Änderung an dem Ticket zu tun !?!" Daher sollte man als Ersteller eines Programms diese Prüfung unbedingt durchführen.

Zeitpunkt Erweiterte Synprüfung

Die erweiterte Syntaxprüfung sollte vor allem durchgeführt werden, wenn die Codingerstellung an einem Programm weitgehend abgeschlossen ist und ehe man das Programm zum Test übergibt. Ein versierter SAP-Entwickler wird selten bei den Korrekturen aufgrund der Hinweise der erweiterten Syntaxprüfung einen Fehler einbauen. Aber ausschließen lässt sich das nicht. Daher ist es besser diese Optimierungen vor dem Usertest durchzuführen und nicht erst unmittelbar vor dem Produktivtransport, wenn der Usertest bereits abgeschlossen ist.
Es ist auch möglich die erweiterte Syntaxprüfung durchzuführen und dessen Meldungen zu korrigieren, nachdem ein Programm lange schon produktiv läuft und der Entwickler bei der Durchführung der erweiterten Syntaxprüfung sieht, dass hier (viel) Potential für die Qualitätsverbesserung eines Programms ist. Hier sollte man jedoch einen guten Tester haben, der das Programm noch mal gründlich durchtestet oder den Fachbereich sensibilisiert, dass nach einem Produktivtransport doch kleine neue Fehler auftreten können. Dieses Risiko von neuen Fehlern ist nicht auszuschließen, aber in aller Regel sehr schnell korrigiert. Insofern ist das Risiko in aller Regel akzeptabel. Die Korrektur der Meldungen wird eigentlich immer die Codingqualität erhöhen und auch die spätere Wartbarkeit des Programms erhöhen.

Unterschied Fehler, Warnungen und Meldungen

SAP unterscheidet bei den Hinweisen zwischen "Fehler", "Warnungen" und "Meldungen". Das erscheint mir eine etwas willkürliche Abgrenzung. Letztlich sind alles Hinweise zur Verbesserung des Codings. Ein Fehler im Sinne der normalen Syntaxprüfung kann nicht dabei sein, sonst hätte die reguläre Syntaxprüfung bereits diese Fehlermeldung ausgegeben und man hätte den Fehler an dieser Stelle behoben.
In der Praxis sollte man alle Hinweise beachten und entweder die Hinweise so umsetzen, dass der Hinweis verschwindet oder mit einem Pragma kennzeichnen, sodass der Hinweis nur noch unter "ausgeblendete Fehler und Warnungen" erscheint.

Nutzen Erweiterte Syntaxprüfung

Die Bereinigung von Warnungen macht das Programm übersichtlicher und häufig findet man auch logische Fehler im Coding.
Es ist anzustreben die Anzahl der angezeigten Warnungen auf Null zu bringen. Ein Aufwand von wenigen Minuten steht ein hoher Nutzen gegenüber. Auch die Weiterbetreuung durch andere Entwickler ist deutlich einfacher, wenn das Coding z. B. keine ungenutzten Variablen mehr beinhaltet. Andere Entwickler werden sich meist nicht mehr trauen die erweiterte Programmprüfung durchzuführen, da sie befürchten an einer Stelle einen Fehler einzubauen, dessen Programmkorrektur nicht dringend nötig war.
Sind bei einem Kundenprogramm eine hohe zweistellige oder gar dreistellige Anzahl von Warnungen&Fehlern in der Fundstellenliste, dann ist das Programm mit sehr hoher Wahrscheinlichkeit von minderer Qualität und erfüllt auch nicht die geforderte Funktionalität. Der Entwickler, der das Programm entwickelt hat, sollte darauf angesprochen werden die Anzahl der Warnungen zu minimieren. Wenn es innerhalb der Entwickler einer Firma Standard ist, die erweiterte Syntaxprüfung vor einem Transport durchzuführen, wird die Fehlerfreiheit und Übersichtlichkeit der Programme mit sehr wenig Aufwand deutlich steigen.

Aufruf erweiterte Syntaxprüfung

Die erweiterte Syntaxprüfung lässt sich aufrufen über

Transaktion SLIN
Bei den Transaktionen SE38 und SE80 im Menü im Programmeditor "Programm - Prüfen - erweiterte Programmprüfung". Bei den anderen Entwicklungstransaktionen ist es sehr ähnlich.

Auswahl zu prüfende Objekte

Standardmäßig werden viele Prüfungen bei den Checkboxen gesetzt.

Einige Prüfungen werden defaultmäßig nicht markiert, wie z. B. "Zeichenketten". Es empfiehlt sich alle Checkboxen zu markieren mit dem Button .

Fundstellenliste

Im Optimalfall werden nach der Optimierung keine Hinweise mehr angezeigt.

Oft ist jedoch einige Arbeit zu investieren, um die Hinweise zu bereinigen.

Mögliche Fehler/Warnungen

Benutzernamen

Abfrage auf den Benutzernamen
Es macht speziell während der Entwicklung Sinn einen Breakpoint beim eigenen Benutzernamen ins Coding einzubauen an Stellen, wo z. B. ein SY-SUBRC <> 0 gesetzt wird und man erwartet, dass dies nicht eintritt. Aber es passiert dann doch aus den verschiedensten Gründen und durch den Breakpoint auf den eigenen Namen findet man in so einer Fehlerkonstellation den Fehler sehr viel schneller. Andere User werden aber durch diesen benutzerabhängigen Breakpoint nicht gestört. Vor dem Produktivtransport sollte man solche Breakpoints aus dem Coding entfernen oder zumindest mit einem Pragma kennzeichnen.

break <username> ##NO_BREAK ##USER_OK.

Hier würde sowohl die Warnung über den Breakpoint ausgegeben werden, als auch die Warnung über die bedingte Ausführung auf den Benutzernamen.

Berechtigungen

Prüfung der Existenz der Berechtigungsobjekte und Berechtigungsfelder

Breakpoint

"Break-Point" oder "break-point <username>" im Coding

CALL FUNCTION-Schnittstellen

Nicht verarbeitete Returncodes von Funktionsbausteinen
Die Exceptions beim Aufruf des Funktionsbausteins passen nicht zu Exceptions des Funktionsbausteins
Überprüfung der Übergabeparameter zu den Parametern im Funktionsbaustein

CALL METHOD-Schnittstellen

Nicht verarbeitete Returncodes von Methoden

Datenbankkompabilität

Pragma: ##DB_FEATURE_MODE[TABLE_LEN_MAX1]
Z. B. bei dem folgenden Coding kommt eine Warnung, dass das Coding nicht auf allen Datenbanken gültig ist.
Wenn die vorliegende Datenbank das nicht unterstützen würde, wüsste man es. Bei einem späteren Datenbankwechsel (was extrem selten vorkommt) wird man kaum auf eine Datenbank wechseln, die weniger Funktionalität unterstützt als die vorherige Datenbank. Insofern kann man mit diese Warnung gelassen mit einem Pragma ausblenden.

SELECT
  lgort
  INTO @<fs_itab>-lgort
  FROM lips
  UP TO 1 ROWS
  WHERE vbeln = @<fs_itab>-vbeln
  ORDER BY vbeln, posnr.
ENDSELECT.

oder

 SELECT SUM( lfimg )  
 INTO cv_summe
 FROM lips
 WHERE vbeln = iv_vbeln.

Es gibt die Meldung

und in der erweiterten Hilfe

Doppelte Anweisungen

2 Clears auf die gleiche Variable hintereinander

EXIT, CHECK und RETURN

Schlüsselbefehl EXIT nur in Loop-Schleifen verwenden, um Loop zu verlassen. Schlüsselbefehl "RETURN" für Verlassen Routine
Verwendung vom Befehl CHECK statt RETURN, wenn Befehl dem Verlassen der Routine dient

Feldeigenschaften

Variablen im globalen Bereich des Programms
Verwendung von global definierten Variablen in lokalen Programmroutinen
Variablen, die im Coding nicht genutzt werden
Variablen, die zwar im Coding gefüllt, aber nicht weiter verarbeitet werden (könnten z. B. für SAPScripts genutzt werden)
Angabe von "type table of .." statt "type standard/sorted/hash table of .."

MESSAGE

Prüfung auf Existenz der angegebenen Nachricht in Nachrichtenklasse mit Anzahl Parameter

PERFORM/FORM-Schnittstellen

Nicht aufgerufene Form-Routinen im Programm (Vorsicht: Sie können dynamisch oder von anderen Programmen gerufen werden)
Using/Changing-Parameter vom Perform-Aufruf passt nicht zur Schnittstelle in Form-Routine
Using-Variablen werden in der Form-Routine verändert

Selects

Abfrage einer Datenbanktabelle mit nicht voll qualifiziertem Schlüssel
Select-Single bei einem Inner-Join-Select -> Empfehlung Select-Endselect up to 1 rows zu nutzen
Verwendung von "Select *" ohne "Into-Klausel" (itab mit Kopfbereich)

Textsymbole und Zeichenketten

Zeichenketten ohne Textsymbole (mangelnde Übersetzbarkeit)
Textsymbole, die im Programm angelegt wurden, aber nicht verwendet werden
Textsymbole, die im Programmcoding angegeben wurden, aber noch nicht angelegt wurden
Textsymbole, die eine Länge von 50 Zeichen überschreiten (werden bei Messageboxen abgeschnitten)
Unterschiedliche Texte, die auf das gleiche Textsymbol verweisen

Überflüssige Anweisungen

Anweisungen, die im Programmcoding nicht erreichbar sind
Nicht erreichbare Programmteile
Überflüsse (doppelte) Punkte am Ende einer Zeile
identische Bedingungen bei CASE oder IF-ELSEIF-Bedingungen

Veraltete Anweisungen

Information über Programmcoding, welches als obsolet erkannt wird und durch neue Programmanweisungen in ABAP ersetzt wurden

Pragmas und Psydokommentare

Oftmals weist einen die erweiterte Syntaxprüfung auf Punkte hin, wo man als Entwickler aus guten Gründen entscheidet das Coding nicht zu verändern.
Um der erweiterten Syntaxprüfung mitzuteilen, dass man diese Warnungen gesehen hat, aber das Coding als korrekt ansieht und die Meldungen nicht mehr sehen will, kann man hinter die Zeile einen Psydokommentar oder Pragma hängen.
Pragmas werden vor dem abschließenden Punkt oder Komma eingefügt
Psydokommentare können vor dem abschließenden Punkt oder Komma eingefügt werden, aber können auch nach dem schließenden Punkt/Komma geschrieben werden, sofern der Psydokommentar auf der gleichen Zeile wie die Befehlszeile steht und vor anderen Kommentaren.
Die so markierten Meldungen werden anschließend bei der erweiterten Syntaxprüfung nur noch unter der Kategorie "Ausgeblendete Fehler und Warnungen" angezeigt.
Die passenden Psydokommentare oder Pragmas stehen jeweils bei den Meldungen.

Beispiele für zu akzeptierende Hinweise

Eine Form, die dynamisch von einem Programm gerufen wird, wo das Programm auf die mögliche Nichtverwendung hinweist
Variablen werden zwar gefüllt, aber dann nicht weiter verwendet. Diese Variablen werden jedoch von einem SAPScript-Formular verwendet, was auf globale Daten angewiesen ist.
Die Prüfung weist auf eine Nichtübersetzung eines Textes hin. Man möchte diesen Text jedoch so im Coding stehen lassen, weil der Text nie übersetzt wird.
Ein Abfrage einer Tabelle geht nicht über den voll qualifizierten Schlüssel, sondern über einen Index, der auch in der Praxis eindeutig ist.

Beispiel Anwendung Pragma bei Hinweis Nichtübersetzung Zeichenkette

Hier gibt es eine Warnung bei "Zeichenketten".

Die Meldung weist hin auf eine mangelnde Übersetzbarkeit eines Textes. Gleich dahinter steht auch der Hinweis auf einen Psydokommentar oder Pragma.

Hier entscheiden wir, dass der Text nicht zu übersetzen ist mit dem Pragma ##NO_TEXT am Ende der Zeile.

Constants: gc_txt_doc_snt_to  TYPE text20 VALUE 'Documents sent to' ##NO_TEXT.

Bei Neuausführung der erweiterten Syntaxprüfung wird die Warnung bei Zeichenketten nicht mehr angezeigt.

Möchte man mehrere Psydokommentare zu einer Anweisung anwenden, so muss die Anweisung auf mehrere Zeilen verteilt werden. Hier kann man z. B. einfach den abschließen Punkt oder Komma in die nächste Zeile schreiben.

Data:  gc_origin TYPE text20 VALUE 'Origin:'  "#EC NEEDED
                                            . "#EC NOTEXT

Web-Links

Literatur

ABAP Workbench - 100 Tipps & Tricks, von Christian Assig, S. 314 ff.