Transaktion SLIN (erweiterte Syntaxprüfung)

Aus SAP-Wiki
Wechseln zu: Navigation, Suche

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

Die erweiterte Syntaxprüfung sollte vor allem durchgeführt werden, bevor man ein Programm transportiert und es zum Test übergibt.

Nutzen Erweiterte Syntaxprüfung

  • Die Bereinigung von Warnungen macht das Programm übersichtlicher und häufig findet man auch Programmierfehler 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.
  • 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 geforderte Funktionalität. Der Entwickler 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 Entwicklertransaktionen ist es sehr ähnlich.

ErweiterteSyntaxpruefung1.jpg

Auswahl zu prüfende Objekte

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

ErweiterteSyntaxpruefung2.jpg

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

ErweiterteSyntaxpruefung4.jpg

Fundstellenliste

Im Optimalfall werden nach der Optimierung keine Warnungen oder Fehler mehr angezeigt.

ErweiterteSyntaxpruefung5.jpg

Oft ist jedoch einige Arbeit zu investieren, um die Warnungen/Fehler zu bereinigen.

ErwSyntaxpruefung7.jpg

Mögliche Fehler/Warnungen

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

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

Berechtigungen

  • Prüfung der Existenz der Berechtigungsobjekte und Berechtigungsfelder

MESSAGE

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

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

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 .."

Überflüssige Anweisungen

  • Anweisungen, die im Programmcoding nicht erreichbar sind

Veraltete Anweisungen

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

Datenbankselektionen

  • Abfrage einer Datenbanktabelle mit nicht voll qualifiziertem Schlüssel
  • Select-Single bei einem Inner-Join-Select
  • Verwendung von "Select *" ohne "Into-Klausel" (itab mit Kopfbereich)

Coding

  • Break-Point im Coding
  • Nicht erreichbare Programmteile
  • Überflüsse (doppelte) Punkte am Ende einer Zeile
  • Verwendung vom Befehl CHECK statt RETURN, wenn Befehl dem Verlassen der Routine dient
  • identische Bedingungen bei CASE oder IF-ELSEIF-Bedingungen

Pragmas und Psydokommentare

  • Oftmals weist einen die erweiterte Syntaxprüfung auf Punkte hin, wo man als Entwickler nach sorgfältiger Prüfung und 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".

ErwSyntaxpruefung1.jpg


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

ErwSyntaxpruefung2.jpg


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.

ErwSyntaxpruefung5.jpg


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