Bonn � Boston
Horst Keller, Wolf Hagen Thümmel
ABAP™-Programmierrichtlinien
1286.book Seite 3 Donnerstag, 30. April 2009 12:06 12
Auf einen Blick
1 Einleitung ............................................................................ 19
2 Allgemeine Grundregeln ..................................................... 25
3 ABAP-spezifische Grundregeln ........................................... 43
4 Aufbau und Stil ................................................................... 81
5 Architektur .......................................................................... 159
6 Sicheres und robustes ABAP ............................................... 223
A Obsolete Sprachkonstrukte ................................................ 353
B Automatisierte Überprüfung von Namenskonventionen ... 375
C Alle Regeln im Überblick .................................................... 383
D Literaturverzeichnis ............................................................ 387
E Die Autoren ......................................................................... 388
1286.book Seite 5 Donnerstag, 30. April 2009 12:06 12
7
Inhalt
Vorwort ..................................................................................................... 13Danksagung der Autoren ........................................................................... 17
1 Einleitung ............................................................................. 19
1.1 Was sind Programmierrichtlinien? ............................................ 191.2 Warum Programmierrichtlinien? .............................................. 201.3 Um welche Richtlinien handelt es sich hier? ............................. 201.4 An wen richtet sich dieses Buch? ............................................. 211.5 Zur Verwendung dieses Buches ............................................... 22
2 Allgemeine Grundregeln ....................................................... 25
2.1 Trennung der Belange .............................................................. 252.2 KISS-Prinzip ............................................................................. 342.3 Korrektheit und Qualität .......................................................... 37
3 ABAP-spezifische Grundregeln ............................................ 43
3.1 ABAP Objects als Programmiermodell ..................................... 433.2 Programmtyp und Programmeigenschaften .............................. 52
3.2.1 Programmtyp .............................................................. 533.2.2 Programmattribute ...................................................... 583.2.3 Originalsprache ........................................................... 62
3.3 Modernes ABAP ...................................................................... 643.4 Prüfungen auf Korrektheit ....................................................... 68
3.4.1 Syntaxprüfung ............................................................. 683.4.2 Erweiterte Programmprüfung ...................................... 713.4.3 Code Inspector ........................................................... 753.4.4 ABAP-Testcockpit ....................................................... 78
4 Aufbau und Stil ..................................................................... 81
4.1 Formatierung des Quelltextes .................................................. 824.1.1 Groß-/Kleinschreibung ................................................ 824.1.2 Anweisungen pro Programmzeile ................................ 854.1.3 Verwendung des Pretty Printers .................................. 884.1.4 Zeilenbreite ................................................................ 91
4.2 Namensgebung ....................................................................... 934.2.1 Wahl der Sprache ........................................................ 95
1286.book Seite 7 Donnerstag, 30. April 2009 12:06 12
Inhalt
8
4.2.2 Sprechende Namen ..................................................... 964.2.3 Namen von Repository-Objekten ................................ 1044.2.4 Programminterne Namen ............................................ 108
4.3 Kommentare ........................................................................... 1184.3.1 Wahl der Sprache ........................................................ 1184.3.2 Inhalt .......................................................................... 1204.3.3 Anordnung im Quelltext ............................................. 123
4.4 Programm- und Prozeduraufbau .............................................. 1274.4.1 Globale Deklarationen eines Programms ..................... 1274.4.2 Lokale Deklarationen .................................................. 131
4.5 Quelltextorganisation .............................................................. 1334.5.1 Quelltextmodularisierung ............................................ 1344.5.2 Mehrfachverwendung von Include-Programmen ......... 136
4.6 Alternative Schreibweisen ........................................................ 1384.6.1 Alternative Sprachkonstrukte in Anweisungen ............. 1384.6.2 Kettensätze ................................................................. 1414.6.3 Methodenaufrufe ........................................................ 1454.6.4 Zuweisungen und Berechnungen ................................. 1474.6.5 Rechenausdrücke ........................................................ 148
4.7 Komplexität ............................................................................. 1504.7.1 Ausdrücke ................................................................... 1514.7.2 Schachtelungstiefe ...................................................... 1534.7.3 Prozedurvolumen ........................................................ 1544.7.4 Klassengröße ............................................................... 1554.7.5 Toter Code .................................................................. 157
5 Architektur ........................................................................... 159
5.1 Objektorientierte Programmierung .......................................... 1595.1.1 Kapselung ................................................................... 1605.1.2 Modularisierung .......................................................... 1625.1.3 Statische Klassen und Singletons ................................. 1665.1.4 Vererbung ................................................................... 1705.1.5 Klassenreferenzen und Interface-Referenzen ............... 1715.1.6 Lokale Typen für globale Klassen ................................. 1735.1.7 Instanzkonstruktor ...................................................... 175
5.2 Fehlerbehandlung .................................................................... 1765.2.1 Reaktion auf Fehlersituationen .................................... 1775.2.2 Klassische und klassenbasierte Ausnahmen ................. 1795.2.3 Ausnahmekategorien .................................................. 1835.2.4 Ausnahmetexte ........................................................... 185
1286.book Seite 8 Donnerstag, 30. April 2009 12:06 12
Inhalt
9
5.2.5 Verwendung von Ausnahmeklassen ............................ 1875.2.6 Ausnahmen behandeln und propagieren ..................... 1895.2.7 Aufräumarbeiten nach Ausnahmen ............................. 1915.2.8 Abfangbare Laufzeitfehler ........................................... 1935.2.9 Assertions ................................................................... 1955.2.10 Nachrichten ................................................................ 197
5.3 Benutzeroberflächen ................................................................ 2005.3.1 Auswahl der Oberflächentechnologie .......................... 2005.3.2 Kapselung klassischer Oberflächen .............................. 2045.3.3 Listen .......................................................................... 2095.3.4 Barrierefreiheit ............................................................ 212
5.4 Datenspeicherung .................................................................... 2135.4.1 Persistente Datenspeicherung ..................................... 2145.4.2 Datenbankzugriffe ....................................................... 2165.4.3 Mandantenbehandlung ............................................... 2175.4.4 Verwendung des Shared Memorys .............................. 219
6 Sicheres und robustes ABAP ................................................ 223
6.1 Datentypen und Datenobjekte ................................................ 2236.1.1 Gebundene und eigenständige Datentypen ................. 2246.1.2 Deklaration von Datentypen und Konstanten .............. 2266.1.3 Deklaration von Variablen ........................................... 2306.1.4 Einbindung von Strukturen ......................................... 2336.1.5 Verwendung von Typen .............................................. 2356.1.6 Bezug auf Datentypen oder Datenobjekte ................... 2376.1.7 Tabellenarbeitsbereiche .............................................. 2396.1.8 Literale ....................................................................... 2406.1.9 Strings ........................................................................ 2436.1.10 Startwerte ................................................................... 2456.1.11 Datenobjekte für Wahrheitswerte ............................... 247
6.2 Zuweisungen, Berechnungen und sonstige Zugriffe auf Daten ...................................................................................... 2496.2.1 Zuweisungen zwischen unterschiedlichen Typen ......... 2496.2.2 Vermeidung ungültiger Werte ..................................... 2506.2.3 Verwendung von Konvertierungsregeln ....................... 2536.2.4 Angabe von Zahlen ..................................................... 2556.2.5 Wahl des numerischen Typs ........................................ 2576.2.6 Rundungsfehler ........................................................... 2616.2.7 Division durch null ...................................................... 2626.2.8 Casting ........................................................................ 263
1286.book Seite 9 Donnerstag, 30. April 2009 12:06 12
Inhalt
10
6.2.9 Laufzeitfehler beim Zugriff auf Datenobjekte ............... 2656.2.10 Anonyme Container .................................................... 2676.2.11 Referenzübergabe globaler Daten ............................... 268
6.3 Systemfelder ............................................................................ 2706.3.1 Zugriff ......................................................................... 2706.3.2 Obsolete und interne Systemfelder ............................. 2726.3.3 Auswertung ................................................................ 2736.3.4 Rückgabewert ............................................................. 2756.3.5 Verwendung als Aktualparameter ................................ 2766.3.6 Verwendung auf der Benutzeroberfläche ..................... 2786.3.7 Verwendung an Operandenpositionen ........................ 280
6.4 Interne Tabellen ...................................................................... 2816.4.1 Wahl der Tabellenart ................................................... 2836.4.2 Sekundärschlüssel ....................................................... 2856.4.3 Initialer Speicherbedarf ............................................... 2896.4.4 Sortiertes Befüllen ....................................................... 2916.4.5 Verdichtetes Befüllen .................................................. 2926.4.6 Ausgabeverhalten ....................................................... 2936.4.7 Schleifenverarbeitung .................................................. 296
6.5 Modularisierungseinheiten ...................................................... 2976.5.1 Funktionsbausteine und Unterprogramme ................... 2976.5.2 Art der Formalparameter von Prozeduren ................... 2996.5.3 Art der Übergabe von Formalparametern .................... 3016.5.4 Referenzübergabe von Ausgabeparametern ................. 3036.5.5 Typisierung von Formalparametern ............................. 3056.5.6 Interne und externe Prozeduraufrufe ........................... 3086.5.7 Prozeduren verlassen .................................................. 3126.5.8 Dialogmodule und Ereignisblöcke ............................... 3146.5.9 Makros ....................................................................... 316
6.6 Dynamische Programmiertechniken ......................................... 3196.6.1 Einsatz dynamischer Programmiertechniken ................ 3196.6.2 Laufzeitfehler bei der dynamischen Verarbeitung ........ 3216.6.3 Verwendung dynamischer Datenobjekte ..................... 3236.6.4 Speicherverbrauch dynamischer Speicherobjekte ......... 3256.6.5 Verwaltungskosten dynamischer Speicherobjekte ........ 3296.6.6 Dynamischer Zugriff auf Datenobjekte ........................ 3326.6.7 Generische Programmierung ....................................... 335
6.7 Internationalisierung ................................................................ 3406.7.1 Ablage von Systemtexten ............................................ 3406.7.2 Übersetzungsfreundliche Nachrichtentexte .................. 3426.7.3 Textumgebung ............................................................ 344
1286.book Seite 10 Donnerstag, 30. April 2009 12:06 12
Inhalt
11
6.7.4 Zeichensatz von Quelltexten ....................................... 3466.7.5 Zerschneiden von Texten ............................................ 3476.7.6 Codepages für Dateien ................................................ 348
Anhang ....................................................................................... 351
A Obsolete Sprachkonstrukte ................................................................ 353A.1 Prozeduren .............................................................................. 354A.2 Deklarationen .......................................................................... 355A.3 Objekterzeugung ..................................................................... 358A.4 Aufrufe und Verlassen ............................................................. 359A.5 Programmablaufsteuerung ....................................................... 361A.6 Zuweisungen ........................................................................... 362A.7 Rechenanweisungen ................................................................ 364A.8 Zeichen- und Bytekettenverarbeitung ...................................... 365A.9 Interne Tabellen ...................................................................... 366A.10 Dynpro-Ablauflogik ................................................................. 368A.11 Klassische Listenverarbeitung ................................................... 369A.12 Datenspeicherung .................................................................... 371A.13 Contexte .................................................................................. 373A.14 Externe Schnittstellen .............................................................. 374
B Automatisierte Überprüfung von Namenskonventionen ..................... 375B.1 Namenskonventionen im Code Inspector ................................. 376B.2 Typabhängige Präfixbestandteile .............................................. 376B.3 Präfixe für prozedurlokale Deklarationen ................................. 378B.4 Strukturierte Programmierung ................................................. 379B.5 Objektorientierte Programmierung .......................................... 380B.6 Bewertung der Namenskonventionen ...................................... 382
C Alle Regeln im Überblick .................................................................... 383D Literaturverzeichnis ............................................................................ 387E Die Autoren ....................................................................................... 388
Index ......................................................................................................... 389
1286.book Seite 11 Donnerstag, 30. April 2009 12:06 12
43
»Ach, wenn Du erfahren wolltest, wie ich Dich liebe, so müßtest Du mir eine neue Sprache schenken.«– Friedrich Schiller
3 ABAP-spezifische Grundregeln
Neben den in Kapitel 2, »Allgemeine Grundregeln«, aufgeführten Regeln füh-ren wir in diesem Kapitel zusätzlich einen Satz ABAP-spezifischer Grundregelnein, die sich aus speziellen technischen Gegebenheiten der Sprache ABAP, derABAP-Laufzeitumgebung und ihrer Historie ergeben. Auch diese Grundregelnbestimmen viele der auf dieses Kapitel folgenden spezielleren Regeln.
3.1 ABAP Objects als Programmiermodell
Hintergrund
ABAP ist eine hybride Programmiersprache, die sowohl ein prozedurales alsauch ein objektorientiertes Programmiermodell unterstützt. Das prozeduraleProgrammiermodell beruht auf der Modularisierung von Programmen in dieklassischen Verarbeitungsblöcke, das heißt Ereignisblöcke, Dialogmodule,Funktionsbausteine und Unterprogramme. In ABAP Objects tritt die Klassekonzeptionell an die Stelle des klassischen Programms,1 und die Modularisie-rung erfolgt durch deren Methoden.
Beide Modelle sind in der Weise interoperabel, dass in klassischen Verarbei-tungsblöcken auf Klassen zugegriffen werden kann und innerhalb von Metho-den wiederum klassische Programme und Prozeduren aufgerufen werdenkönnen. Der hybride Charakter der Sprache ist in erster Linie der Abwärtskom-patibilität geschuldet, da ABAP prozedurale Wurzeln hat und sowohl ganzeProgramme als auch wiederverwendbare Prozeduren (in erster Linie Funk-tionsbausteine) mit Einführung des objektorientierten ProgrammiermodellsEnde der 1990er-Jahre weiterhin nutzbar bleiben sollten.
1 Technisch gesehen sind Klassen nach wie vor in Programmen deklariert und implementiert.
1286.book Seite 43 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
44
Regel
Details
Die Forderung nach der Trennung der Belange (siehe Regel 2.1) wird am bestendurch eine weitestgehende Verwendung von ABAP Objects unterstützt. Einedetaillierte Gegenüberstellung von ABAP Objects und dem prozeduralen Pro-grammiermodell ist nicht Gegenstand dieses Buches. Dass die objektorientierteProgrammierung – und hier insbesondere ABAP Objects im Vergleich zumklassischen prozeduralen ABAP – besser geeignet ist, die Anforderungen zeit-gemäßer Programmierung zu erfüllen, wurde unter anderem in einem Beitragim SAP Professional Journal (Not Yet Using ABAP Objects? – Eight Reasons whyevery ABAP Developer Should Give It a Second Look) dargelegt. Die dort genann-ten acht Gründe, ABAP Objects zu verwenden, lauten zusammengefasst wiefolgt:
1. DatenkapselungABAP Objects ermöglicht eine fortgeschrittene Art der Datenkapselung. Beider klassischen prozeduralen Programmierung wird der Zustand einerAnwendung durch den Inhalt von globalen Variablen bestimmt. In derobjektorientierten Programmierung ist der Zustand in Klassen oder Objek-ten als Instanzen von Klassen gekapselt. Die Aufteilung der Daten in die ver-schiedenen Sichtbarkeitsbereiche einer Klasse – öffentlich, geschützt, paket-sichtbar (ab Release 7.2) und privat – sorgt für eine klare Unterscheidungzwischen extern und intern verwendbaren Daten. Selbst ohne eine tiefgehende objektorientierte Modellierung profitieren Anwendungspro-gramme hinsichtlich Robustheit und Wartbarkeit von diesen Eigenschaften.
2. Explizite InstanzierungABAP Objects ermöglicht die mehrfache Instanzierung einer Klasse über ex-plizite Objekterzeugung mittels der Anweisung CREATE OBJECT. Jede Instanzeiner Klasse (Objekt) hat einen eigenen Zustand, der durch die Werte ihrerAttribute festgelegt wird und über die Methoden der Klassen geändert wer-den kann. Eine automatische Garbage Collection sorgt dafür, dass Objekte,die nicht mehr benötigt werden, aus dem Speicher gelöscht werden. Im pro-
Regel 3.1: ABAP Objects verwenden
Verwenden Sie bei der Neu- und Weiterentwicklung so weit wie möglich ABAP Ob-jects. Klassische Verarbeitungsblöcke dürfen nur noch in Ausnahmefällen neu ange-legt werden.
1286.book Seite 44 Donnerstag, 30. April 2009 12:06 12
ABAP Objects als Programmiermodell 3.1
45
zeduralen Modell gibt es keine Mehrfachinstanzierung, weshalb dort mit zu-standslosen Funktionen auf getrennt abgelegten Daten gearbeitet werdenmuss.
3. VererbungABAP Objects ermöglicht die Wiederverwendung von Klassen durch Verer-bung, wobei Klassen mit speziellen Verhaltensweisen von allgemeinerenKlassen abgeleitet werden und nur die Unterschiede neu implementiert wer-den müssen. Im prozeduralen Modell können vorhandene Funktionen nurgenauso verwendet werden, wie sie sind, oder es müssen neue angelegt wer-den.
4. InterfacesIn ABAP Objects können Objekte über eigenständige Interfaces ansprochenwerden. Dies befreit Entwickler davon, sich um Implementierungsdetailsder hinter dem Interface liegenden Klasse kümmern zu müssen. Dadurchkann der Anbieter eines Interface die dahinterliegenden Implementierun-gen ändern, ohne dass die Programme, die das Interface verwenden, modi-fiziert werden müssen. Im prozeduralen Modell gibt es kein solches Konzepteigenständiger Interfaces.
5. EreignisseABAP Objects erleichtert die Implementierung ereignisgetriebener Pro-grammabläufe. Anwendungen können über einen Publish-and-Subscribe-Mechanismus lose gekoppelt werden, wobei der Auslöser eines Ereignissesnichts über eventuelle Behandler wissen muss. Dies erlaubt größere Flexibi-lität im Vergleich zum prozeduralen Ansatz, bei dem Programme stärker ge-koppelt sind und der Programmablauf in der Regel viel starrer vorgegebenist.
6. Explizite orthogonale KonzepteIn ABAP Objects gibt es eine kleine Anzahl genau definierter fundamentalerund zueinander orthogonaler Konzepte, die es zuverlässiger und wenigerfehleranfällig als das klassische ABAP machen. Im klassischen prozeduralenABAP dominieren implizite Verhaltensweisen, in denen Programme durchimplizite Ereignisse der Laufzeitumgebung und über globale Daten gesteuertwerden. Die Konzepte von ABAP Objects werden dagegen in einem Pro-gramm explizit wiedergegeben. ABAP Objects ist damit im Vergleich zumklassischen prozeduralen ABAP einfacher erlern- und anwendbar.
7. Bereinigte SyntaxIn ABAP Objects gelten bereinigte Syntax- und Semantikregeln. Das klassi-sche prozedurale ABAP ist eine evolutionär gewachsene Sprache mit vielenobsoleten und sich überschneidenden Konzepten. Mit Einführung vonABAP Objects bot sich mit Klassen und Methoden ein Feld für bereinigte
1286.book Seite 45 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
46
Syntax- und Semantikregeln, das von Anforderungen an die Abwärtskompa-tibilität völlig unbelastet war. Auf diese Weise konnten in ABAP Objects, dasheißt innerhalb von Klassen und Methoden, die meisten obsoleten und feh-leranfälligen Sprachkonstrukte syntaktisch verboten werden. Zusätzlichwerden fragwürdige und potenziell fehlerhafte Zugriffe auf Daten schärferüberprüft und gegebenenfalls ebenso verboten. Die Syntaxbereinigung er-zwingt in Klassen eine Verwendung der Sprache ABAP, wie sie außerhalbvon Klassen nur durch Richtlinien gefordert werden kann (siehe Abschnitt3.3, »Modernes ABAP«).
8. Zugang zu neuen TechnologienABAP Objects ist oft der einzige Weg, um mit neuen ABAP-Technologienumzugehen. Beispielsweise bieten GUI Controls, Web Dynpro ABAP, RunTime Type Services (RTTS) oder das Internet Connection Framework (ICF)ausschließlich klassenbasierte Schnittstellen an. Wenn Programme, die sol-che Services verwenden, weiterhin rein prozedural implementiert würden,käme es zu einer unnötigen Vermischung der Programmiermodelle mit ent-sprechender Erhöhung der Komplexität.
Die dringende Empfehlung zur Verwendung von ABAP Objects hat somitsowohl inhaltliche als auch formale Aspekte:
� Wie in den Punkten 1 bis 5 aufgeführt, ist das objektorientierte Program-miermodell inhaltlich besser geeignet, die Komplexität von Software durchPrinzipien wie Kapselung und Vererbung beherrschbar zu halten. Zugegebe-nermaßen ist gutes objektorientiertes Design keine leichte Aufgabe, undauch heute noch gibt es Entwickler mit wenig Erfahrung auf diesem Gebiet.Wer vor diesem Hintergrund immer noch mit dem Gedanken spielt, eineNeuentwicklung in klassischer prozeduraler Manier anzugehen, muss sichjedoch vergegenwärtigen, dass auch das prozedurale ereignisgesteuerteABAP-Programmiermodell mit seinen Systemereignissen nicht leicht zudurchschauen ist.
� Die Punkte 6 bis 8 beschreiben eher formale Aspekte. Die dort aufgeführtenGründe sprechen dafür, Prozeduren heute nur noch in Form von Methodenanzulegen, selbst in Abwesenheit eines echten objektorientierten Designs.Funktionsbausteine und Unterprogramme sollen nur noch in den Ausnah-mefällen angelegt werden, in denen ABAP Objects bisher keine Alternativebietet.
Hinweise und Empfehlungen zum erfolgreichen Einsatz von ABAP Objects lie-fert Abschnitt 5.1, »Objektorientierte Programmierung«.
1286.book Seite 46 Donnerstag, 30. April 2009 12:06 12
ABAP Objects als Programmiermodell 3.1
47
Ausnahme
Im derzeitigen Zustand (Releases 7.0 EhP2 und 7.2) fehlen in ABAP Objectsnoch folgende Eigenschaften, um klassische Verarbeitungsblöcke vollständigdurch Methoden zu ersetzen:
� Remote Method Invocation (RMI) als Ersatz für den Remote Function Call(RFC)
� ein Ersatz für den Aufruf von Verbuchungsfunktionsbausteinen (CALLFUNCTION IN UPDATE TASK)
� ein Ersatz für den Aufruf von Unterprogrammen bei COMMIT WORK undROLLBACK WORK (PERFORM ON COMMIT/ROLLBACK)
� objektorientierte Behandlung von klassischen Dynpros inklusive Selektions-bildern als Ersatz für Dialogtransaktionen, CALL SCREEN und CALL
SELECTION-SCREEN
� dynamische Erzeugung von Klassen als Ersatz für die klassische dynamischeProgrammerzeugung (GENERATE SUBROUTINE POOL)
� direkte Unterstützung der Hintergrundverarbeitung als Ersatz für den Auf-ruf ausführbarer Programme (SUBMIT VIA JOB)
Genau für diese Fälle dürfen in neuen Programmen noch folgende klassischeVerarbeitungsblöcke angelegt werden:
� Funktionsbausteine werden noch für RFC und die Verbuchung benötigt undfür den Aufruf von klassischen Dynpros und Selektionsbildern empfohlen(siehe Regel 5.19).
� Unterprogramme werden noch für PERFORM ON COMMIT/ROLLBACK und indynamisch generierten Subroutinen-Pools (GENERATE SUBROUTINE POOL)benötigt.
� Dialogmodule und Ereignisblöcke für Selektionsbildereignisse werden nochin Funktionsgruppen benötigt, die klassische Dynpros und Selektionsbilderverschalen (siehe Regel 3.2).
� Der Ereignisblock START-OF-SELECTION wird noch in ausführbaren Program-men benötigt, die für die Hintergrundverarbeitung vorgesehen sind.
Innerhalb eines solchen Verarbeitungsblocks soll die Ausführung dann jedochsofort an eine geeignete Methode delegiert werden (siehe Regel 6.37, »KeineImplementierungen in Funktionsbausteinen und Unterprogrammen« undRegel 6.44, »Keine Implementierungen in Dialogmodulen und Ereignisblö-cken«). Diese muss keine Methode einer globalen Klasse sein, sondern kanndurchaus im Rahmen einer lokalen Klasse innerhalb des zugehörigen Rahmen-
1286.book Seite 47 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
48
programms angesiedelt sein. Damit auch in solchen Verarbeitungsblöcken diegleiche strengere Prüfung wie in Methoden durchgeführt wird, kann in dererweiterten Programmprüfung (siehe Abschnitt 3.4.2, »Erweiterte Programm-prüfung«) die Prüfung Veraltete Anweisungen (OO-Kontext) eingeschaltetwerden.
Schlechtes Beispiel
Listing 3.1 enthält eine ansatzweise Implementierung der Behandlung von ver-schiedenen Arten von Bankkonten in einer Funktionsgruppe und deren Ver-wendung in einem Programm, wobei nur die Funktion »Abheben einesBetrags« gezeigt wird. Die Funktionsbausteine der Funktionsgruppe arbeitenauf externen Daten, die hier beim Ereignis LOAD-OF-PROGRAM in eine globaleinterne Tabelle geladen werden. Die Steuerung, ob mit einem Giro- oder Spar-konto umgegangen wird, erfolgt über einen Eingabeparameter, und die unter-schiedliche Behandlung wird über eine CASE-WHEN-Kontrollstruktur an unter-schiedliche Unterprogramme delegiert, wobei keine Wiederverwendungstattfindet. Die Unterprogramme greifen auf die globale interne Tabelle zu. Ineinem Anwendungsprogramm wird der Funktionsbaustein zum Abheben fürverschiedene Konten aufgerufen. Die Ausnahmebehandlung erfolgt klassischmit weiteren CASE-WHEN-Kontrollstrukturen für die Abfrage von sy-subrc.
FUNCTION-POOL account.
DATA account_tab TYPE SORTED TABLE OF accountsWITH UNIQUE KEY id.
LOAD-OF-PROGRAM."fetch amount for all accounts into account_tab...
...
FUNCTION withdraw.*"-----------------------------------------------------*" IMPORTING*" REFERENCE(id) TYPE accounts-id*" REFERENCE(kind) TYPE c DEFAULT 'C'*" REFERENCE(amount) TYPE accounts-amount*" EXCEPTIONS*" negative_amount*" unknown_account_type*"------------------------------------------------------
CASE kind.WHEN 'C'.
PERFORM withdraw_from_checking_account
1286.book Seite 48 Donnerstag, 30. April 2009 12:06 12
ABAP Objects als Programmiermodell 3.1
49
USING id amount.WHEN 'S'.PERFORM withdraw_from_savings_account
USING id amount.WHEN OTHERS.RAISE unknown_account_type.
ENDCASE.ENDFUNCTION.
FORM withdraw_from_checking_accountUSING l_id TYPE accounts-id
l_amount TYPE accounts-amount.FIELD-SYMBOLS <account> TYPE accounts.READ TABLE account_tab ASSIGNING <account>
WITH TABLE KEY id = l_id.<account> = <account> - l_amount.IF <account> < 0.
"Handle debit balance...
ENDIF.ENDFORM.
FORM withdraw_from_savings_accountUSING l_id TYPE accounts-id
l_amount TYPE accounts-amount.FIELD-SYMBOLS <account> TYPE accounts.READ TABLE account_tab ASSIGNING <account>
WITH TABLE KEY id = l_id.IF <account>_wa-amount > l_amount.
<account>-amount = <account>-amount - l_amount.ELSE.
RAISE negative_amount.ENDIF.
ENDFORM.
*********************************************************
PROGRAM bank_application.
...
CALL FUNCTION 'WITHDRAW'EXPORTING
id = ...kind = 'C'amount = ...
EXCEPTIONSunknown_account_type = 2negative_amount = 4.
1286.book Seite 49 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
50
CASE sy-subrc.WHEN 2.
...WHEN 4.
...ENDCASE.
...
CALL FUNCTION 'WITHDRAW'EXPORTING
id = ...kind = 'S'amount = ...
EXCEPTIONSunknown_account_type = 2negative_amount = 4.
CASE sy-subrc.WHEN 2.
...WHEN 4.
...ENDCASE.
Listing 3.1 Modellierung von Bankkonten in Funktionsgruppe
Gutes Beispiel
Listing 3.2 enthält eine ansatzweise Implementierung der Behandlung von ver-schiedenen Arten von Bankkonten in Klassen und deren Verwendung in einerKlasse, wobei wieder nur die Funktion »Abheben eines Betrags« gezeigt wird.
Die verschiedenen Kontoarten werden in Unterklassen einer abstrakten Klassefür Konten implementiert. Jede Instanz eines Kontos wird in ihrem Konstruk-tor genau mit den Daten versorgt, die sie benötigt. Die Anwendungsklasseerzeugt je nach Bedarf Instanzen von Konten der gewünschten Art und ver-wendet deren Methoden polymorph über eine Oberklassenreferenzvariable.Die Ausnahmebehandlung erfolgt über klassenbasierte Ausnahmen. Es werdenkeine CASE-WHEN-Kontrollstrukturen benötigt. Wie bereits in der Beschreibungder Beispiele von Abschnitt 2.1, »Trennung der Belange«, angekündigt, ent-steht hier bei der Verwendung von Klassen kein Overhead an Code mehrgegenüber der prozeduralen Programmierung.
CLASS cx_negative_amount DEFINITION PUBLICINHERITING FROM cx_static_check.
ENDCLASS.
1286.book Seite 50 Donnerstag, 30. April 2009 12:06 12
ABAP Objects als Programmiermodell 3.1
51
CLASS cl_account DEFINITION ABSTRACT PUBLIC.PUBLIC SECTION.
METHODS: constructor IMPORTING id TYPE string,withdraw IMPORTING amount TYPE i
RAISING cx_negative_amount.PROTECTED SECTION.
DATA amount TYPE accounts-amount.ENDCLASS.
CLASS cl_account IMPLEMENTATION.METHOD constructor.
"fetch amount for one account into attribute amount...
ENDMETHOD.METHOD withdraw.
me->amount = me->amount - amount.ENDMETHOD.
ENDCLASS.
CLASS cl_checking_account DEFINITION PUBLICINHERITING FROM cl_account.
PUBLIC SECTION.METHODS withdraw REDEFINITION.
ENDCLASS.
CLASS cl_checking_account IMPLEMENTATION.METHOD withdraw.
super->withdraw( amount ).IF me->amount < 0."Handle debit balance...
ENDIF.ENDMETHOD.
ENDCLASS.
CLASS cl_savings_account DEFINITION PUBLICINHERITING FROM cl_account.
PUBLIC SECTION.METHODS withdraw REDEFINITION.
ENDCLASS.
CLASS cl_savings_account IMPLEMENTATION.METHOD withdraw.
IF me->amount > amount.super->withdraw( amount ).
ELSE.RAISE EXCEPTION TYPE cx_negative_amount.
ENDIF.
1286.book Seite 51 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
52
ENDMETHOD.ENDCLASS.
********************************************************
CLASS bank_application DEFINITION PUBLIC.PUBLIC SECTION.
CLASS-METHODS main.ENDCLASS.
CLASS bank_application IMPLEMENTATION.METHOD main.
DATA: account1 TYPE REF TO cl_account,account2 TYPE REF TO cl_account.
...
CREATE OBJECT account1 TYPE cl_checking_accountEXPORTING
id = ...
CREATE OBJECT account2 TYPE cl_savings_accountEXPORTING
id = ...
...
TRY.account1->withdraw( ... ).account2->withdraw( ... ).
CATCH cx_negative_amount....
ENDTRY.ENDMETHOD.
ENDCLASS.
Listing 3.2 Modellierung von Bankkonten in Klassen
3.2 Programmtyp und Programmeigenschaften
Bereits beim Anlegen eines ABAP-Programms erfolgt über die Wahl des Pro-grammtyps und der Programmattribute eine Weichenstellung bezüglich derspäteren Robustheit und Wartbarkeit. Programmtyp und Programmattributebestimmen unter anderem die Prüfschärfe der Syntaxprüfung. Eine weiterewichtige Eigenschaft von Programmen (wie auch von allen anderen Entwick-lungsobjekten) ist deren Originalsprache.
1286.book Seite 52 Donnerstag, 30. April 2009 12:06 12
Programmtyp und Programmeigenschaften 3.2
53
3.2.1 Programmtyp
Hintergrund
Jedes ABAP-Programm hat einen Programmtyp, der festlegt, welche Deklarati-onen und Verarbeitungsblöcke ein Programm enthalten und wie es über dieABAP-Laufzeitumgebung ausgeführt werden kann. Die möglichen Programm-typen in ABAP sind:
� Ausführbares ProgrammEin ausführbares Programm kann alle möglichen deklarativen Anweisungenenthalten. Alle Verarbeitungsblöcke außer Funktionsbausteinen sind mög-lich. Es unterstützt klassische Dynpros sowie Selektionsbilder und kannsowohl über die Anweisung SUBMIT als auch über Transaktionscodes ausge-führt werden. Ein ausführbares Programm wird mit dem ABAP Editor ange-legt.
� Class-PoolEin Class-Pool enthält stets deklarative Anweisungen für eine globale Klasseund kann daneben auch deklarative Anweisungen für lokale Typen, Inter-faces und Klassen beinhalten. Als Verarbeitungsblöcke sind nur Methodenmöglich. Er unterstützt keine klassischen Dynpros oder Selektionsbilder.Die Methoden der globalen Klasse können je nach Sichtbarkeit von außenaufgerufen und die öffentlichen Methoden der globalen Klasse auch überTransaktionscodes ausgeführt werden. Ein Class-Pool wird mit dem ClassBuilder angelegt.
� Interface-PoolEin Interface-Pool kann nur die deklarativen Anweisungen für ein globalesInterface enthalten. Es sind keine Verarbeitungsblöcke und keine klassi-schen Dynpros oder Selektionsbilder möglich. Ein Interface-Pool ist nichtaufruf- oder ausführbar und wird mit dem Class Builder angelegt.
� Funktionsgruppe (Function-Pool)Eine Funktionsgruppe kann alle Arten von deklarativen Anweisungen ent-halten. Alle Verarbeitungsblöcke außer Reporting-Ereignisblöcken werdenunterstützt. Sie unterstützt klassische Dynpros sowie Selektionsbilder. IhreFunktionsbausteine können aufgerufen werden, es ist aber auch über Trans-aktionscodes ein Einstieg in die Dynpro-Verarbeitung der Funktionsgruppemöglich. Eine Funktionsgruppe wird mit dem Function Builder angelegt.
� Modul-PoolEin Modul-Pool kann alle möglichen deklarativen Anweisungen enthalten.Alle Verarbeitungsblöcke außer Reporting-Ereignisblöcken und Funktions-bausteinen werden unterstützt. Er unterstützt klassische Dynpros sowie
1286.book Seite 53 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
54
Selektionsbilder und kann über Transaktionscodes ausgeführt werden. EinModul-Pool wird mit dem ABAP Editor angelegt.
� Subroutinen-PoolEin Subroutinen-Pool kann alle möglichen deklarativen Anweisungen ent-halten. Als Verarbeitungsblöcke sind der Ereignisblock LOAD-OF-PROGRAMsowie Unterprogramme und Methoden möglich. Er unterstützt keine klassi-schen Dynpros oder Selektionsbilder. Die Unterprogramme können aufge-rufen werden, es ist aber auch eine Ausführung von Methoden über Trans-aktionscodes möglich. Ein Subroutinen-Pool wird mit dem ABAP Editorangelegt.
� Typgruppe (Type-Pool)Eine Typgruppe kann die deklarativen Anweisungen TYPES und CONSTANTSenthalten. Es sind keine Verarbeitungsblöcke und keine klassischen Dyn-pros oder Selektionsbilder möglich. Eine Typgruppe ist nicht aufruf- oderausführbar. Eine Typgruppe wird mithilfe des ABAP Dictionarys angelegt.
Neben den genannten Kompilationseinheiten, das heißt Programmen, dieeigenständig kompilierbar sind, gibt es auch Include-Programme, auf die wir inAbschnitt 4.5, »Quelltextorganisation«, gesondert eingehen.
Eine Programmausführung in ABAP bedeutet, dass ein Programm in den Spei-cher geladen wird und einer oder mehrere seiner Verarbeitungsblöcke ausge-führt werden. Man kann hier die eigenständige und die gerufene Programm-ausführung unterscheiden:
� Eigenständige ProgrammausführungBei der eigenständigen Programmausführung wird das Programm entwederüber einen Transaktionscode (Anweisungen CALL TRANSACTION und LEAVE TOTRANSACTION) oder bei einem ausführbaren Programm über die AnweisungSUBMIT gestartet. Die Anweisung SUBMIT gestattet auch die Ausführung ineinem Hintergrundprozess.
� Gerufene ProgrammausführungBei der gerufenen Programmausführung ruft ein laufendes Programm eineProzedur (Methode, Funktionsbaustein oder Unterprogramm) eines ande-ren Programms auf, das bei Bedarf in den internen Modus des Aufrufersgeladen wird (siehe Abschnitt 6.5.6).
Der Programmablauf im Rahmen der eigenständigen Programmausführung istabhängig vom gewählten Programmtyp und der Art des Programmaufrufs:
� Beim Programmaufruf über eine Transaktion muss zwischen objektorientier-ten (OO-Transaktion) und Dialogtransaktionen unterschieden werden. Beiobjektorientierten Transaktionen ist der Transaktionscode mit einer
1286.book Seite 54 Donnerstag, 30. April 2009 12:06 12
Programmtyp und Programmeigenschaften 3.2
55
Methode einer lokalen oder globalen Klasse verbunden. Der Programmab-lauf wird durch diese Methode bestimmt. Dialogtransaktionen sind hinge-gen mit einem klassischen Dynpro des Programms verknüpft. DerProgrammablauf wird hier durch die zugehörige Dynpro-Ablauflogikbestimmt.
� Der Programmablauf eines über SUBMIT gestarteten ausführbaren Programmswird durch den Reporting-Prozess der ABAP-Laufzeitumgebung bestimmt.Hierbei werden die verschiedenen Reporting-Ereignisblöcke START-OF-SELECTION, GET und END-OF-SELECTION des Programms von der Laufzeitum-gebung aufgerufen.
Der Programmtyp muss unter Beachtung der hier aufgezählten technischenEigenschaften eines Programms und der Anforderungen an die Programmaus-führung geeignet gewählt werden. Nicht mehr alle der genannten Programm-typen lassen sich sinnvoll für Neuentwicklungen einsetzen.2
Regel
Details
Die in Regel 3.2 aufgeführte Hierarchie zur Wahl des Programmtyps ergibt sichaus der grundlegenden Regel in Abschnitt 3.1, die die Verwendung von ABAPObjects vorschreibt. Die folgende Liste führt die Teilaspekte noch weiter aus:
2 Ab Release 7.2 kann die Verwendbarkeit globaler Klassen durch das operationale Paketkon-zept auf ein Paket eingeschränkt werden, sodass diese Rolle von Subroutinen-Pools anBedeutung verliert.
Regel 3.2: Geeigneten Programmtyp wählen
Wählen Sie den Programmtyp wie folgt:
� Für globale Klassen und Interfaces ergibt sich automatisch der ProgrammtypClass-Pool bzw. Interface-Pool.
� Für die Implementierung abgeschlossener Funktionalität, die nicht in der Klassen-bibliothek erscheinen soll, kann der Programmtyp Subroutinen-Pool für lokaleKlassen verwendet werden.2
� Bei Bedarf für Funktionsbausteine ergibt sich automatisch der Programmtyp Funk-tionsgruppe. Außerdem sind Funktionsgruppen zur Verschalung klassischer Dyn-pros oder von Selektionsbildern zu verwenden.
� Bei Bedarf für eine Ausführung im Rahmen der Hintergrundverarbeitung ergibtsich automatisch der Programmtyp ausführbares Programm.
� Es sollen keine neuen Modul-Pools und Typgruppen mehr angelegt werden.
1286.book Seite 55 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
56
� Soll im Rahmen von ABAP Objects Funktionalität paket- oder systemweitzur Verfügung gestellt werden, erfolgt dies über globale Klassen oder Inter-faces, die implizit den Programmtyp Class-Pool oder Interface-Pool haben.Der Aufruf erfolgt entweder über einen Methodenaufruf oder über eine OO-Transaktion, wenn eine eigenständige Programmausführung gewünscht ist.
� Zur Implementierung abgeschlossener Funktionalität, die nicht über einenMethodenaufruf, sondern über einen Transaktionscode aufgerufen werdensoll und die darüber hinaus weder eine Parameterübergabe benötigt nocheine Benutzeroberfläche aufweist, kann der Programmtyp Subroutinen-Poolverwendet werden. Die Implementierung soll ausschließlich über lokaleKlassen und der Programmaufruf über eine OO-Transaktion erfolgen. Sub-routinen-Pools waren, wie die Bezeichnung nahelegt, ursprünglich einmalfür Unterprogramme vorgesehen, die aus anderen Programmen aufgerufenwerden. Da Unterprogramme und insbesondere deren externer Aufruf imRahmen der vorliegenden Programmierrichtlinien für obsolet erklärt wer-den, entfällt dieser Verwendungszweck für Subroutinen-Pools. Stattdessenwerden Subroutinen-Pools hier als unabhängige Container für lokale Klas-sen vorgeschlagen, da sie ansonsten kaum von impliziten Prozessen derABAP-Laufzeitumgebung beeinflusst werden.
� Remotefähige Funktionsbausteine (Remote-enabled Function Module,RFM), die Funktionalität über die RFC-Schnittstelle entweder server- odersystemübergreifend zur Verfügung stellen oder der Parallelisierung dienen,können nur in einer Funktionsgruppe angelegt werden. Die Implementie-rung der eigentlichen Funktionalität soll aber in einer Klasse erfolgen, bei-spielsweise in einer lokalen Klasse innerhalb der Funktionsgruppe (sieheRegel 6.37).
� Für Verbuchungsfunktionsbausteine, die im Rahmen der Verbuchung mitCALL FUNCTION IN UPDATE TASK aufgerufen werden, gilt das Gleiche wie fürremotefähige Funktionsbausteine.
� Programme mit einer klassischen Dynpro-Oberfläche oder Selektionsbil-dern (soweit diese noch erforderlich sein sollten; siehe Regel 5.18, »WebDynpro ABAP verwenden«) sollen ebenfalls in Form einer Funktionsgruppeangelegt werden, die lediglich die Benutzeroberfläche implementiert,jedoch keine eigene Anwendungslogik enthält (siehe Regel 2.1, »SoC-Prinzipbefolgen« und Regel 5.19, »Klassische Dynpros und Selektionsbilder kap-seln«). Dieser Programmtyp ist deshalb geeignet, weil er sowohl klassischeDynpros als auch eine externe funktionale Schnittstelle in Form von Funk-tionsbausteinen enthalten kann. Die von der Dynpro-Ablauflogik aufgerufe-
1286.book Seite 56 Donnerstag, 30. April 2009 12:06 12
Programmtyp und Programmeigenschaften 3.2
57
nen Dialogmodule der Funktionsgruppe sollten im Wesentlichen nurMethodenaufrufe enthalten, beispielsweise für Methoden lokaler Klassen.
� Ein ausführbares Programm besteht aus einer Reihe von Ereignisblöcken,die beim Eintreten der verschiedenen Reporting-Ereignisse ausgeführt wer-den. Diese Form der Ereignissteuerung ist im Wesentlichen obsolet und sollnicht mehr verwendet werden. Ausführbare Programme sollen nur nochdort zum Einsatz kommen, wo dies technisch notwendig ist, im Wesentli-chen demnach für die Hintergrundverarbeitung. Auch in diesem Fall soll dieeigentliche Implementierung in Methoden erfolgen, beispielsweise überMethoden einer lokalen Klasse innerhalb des ausführbaren Programms. DerEreignisblock des Einstiegsereignisses START-OF-SELECTION soll lediglich auseinem Methodenaufruf bestehen (siehe Regel 6.44), und andere Ereignisblö-cke sollten nicht mehr vorkommen.
� Der Modul-Pool war der Programmtyp, der traditionsgemäß bei der klassi-schen Dialogprogrammierung mit Dynpros zum Einsatz kam. Wie inAbschnitt 2.1 aufgezeigt, wird durch Modul-Pools das Konzept der Tren-nung der Belange nicht ausreichend unterstützt. Aus diesem Grund sollenkeine neuen Modul-Pools mehr angelegt werden. Stattdessen sollen klassi-sche Dynpros, soweit diese noch verwendet werden müssen, in Funktions-gruppen verschalt werden.
� Der Programmtyp Typgruppe wurde anfangs als Notlösung dafür einge-führt, dass im ABAP Dictionary zeitweise noch keine Typen für interneTabellen definiert werden konnten. Ebenso verhielt es sich mit der globalenAblage von Konstanten. Beide Lücken sind inzwischen geschlossen. ImABAP Dictionary können beliebige Typen definiert werden, und in globalenKlassen und Interfaces ist es möglich, sowohl Typen als auch Konstanten zurpaket- oder systemweiten Verwendung anzulegen. Aus diesem Grund ist derProgrammtyp Typgruppe obsolet, und es sollen keine neuen Typgruppenmehr angelegt werden (siehe Abschnitt 6.1.2, »Deklaration von Datentypenund Konstanten«).
Anmerkung
In den Fällen, in denen noch mit anderen Programmtypen als Class- und Inter-face-Pools gearbeitet wird, sollte in der erweiterten Programmprüfung (sieheAbschnitt 3.4.2) die Prüfung Veraltete Anweisungen (OO-Kontext) einge-schaltet werden, um auch für die Programmteile, die nicht in lokalen Klassenimplementiert sind, die gleiche strengere Syntaxprüfung wie innerhalb vonKlassen durchzuführen.
1286.book Seite 57 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
58
3.2.2 Programmattribute
Hintergrund
Jedes ABAP-Programm hat neben weiteren, weniger wichtigen Eigenschafteneinen Satz von Programmattributen, die bestimmte Aspekte des Programmver-haltens und der Syntaxprüfschärfe steuern. Diese sind:
� Unicode-Prüfungen aktivzur Erstellung eines Unicode-Programms
� Festpunktarithmetikfür die Berücksichtigung des Dezimaltrennzeichens in Operationen mitgepackten Zahlen
� Logische Datenbankzur Verknüpfung eines ausführbaren Programms mit einer logischen Daten-bank
Die Programmeigenschaften werden beim Anlegen eines Programms im ent-sprechenden Werkzeug (Class Builder, Function Builder, ABAP Editor) festge-legt und können auch nachträglich noch geändert werden.
Regel
Details
Verschiedene Verhaltensweisen oder Prüfschärfen werden nur noch aus Kom-patibilitätsgründen angeboten, um bestehende Programme weiterhin kompi-lier- und ausführbar zu halten. Neue Programme sollen in keinem Fall von ver-alteten Einstellungen Gebrauch machen.
� Beim Anlegen eines neuen Programms ist das Attribut Unicode-Prüfungen
aktiv bereits als Standardeinstellung gesetzt. Dieses Attribut darf niemalszurückgesetzt werden. Nur mit eingeschalteten Unicode-Prüfungen kann
Regel 3.3: Standardeinstellungen für Programmattribute übernehmen
Setzen Sie die Programmattribute für neue Programme wie folgt:
� Unicode-Prüfungen aktiv eingeschaltet
� Festpunktarithmetik eingeschaltet
� keine Zuordnung zu einer logischen Datenbank
Diese Einstellungen entsprechen den Vorschlagswerten beim Anlegen eines neuenProgramms, die daher ohne Änderungen übernommen werden sollen. Einmal ge-setzte Programmattribute sollten nachträglich nicht mehr abgeändert werden.
1286.book Seite 58 Donnerstag, 30. April 2009 12:06 12
Programmtyp und Programmeigenschaften 3.2
59
sichergestellt werden, dass das Programm sowohl in Unicode-Systemen alsauch in Nicht-Unicode-Systemen lauffähig ist und jeweils die gleichenErgebnisse liefert.3 Bei der Vorbereitung eines Nicht-Unicode-Systems zurUmstellung auf Unicode müssen alle noch vorhandenen Nicht-Unicode-Pro-gramme in Unicode-Programme umgesetzt werden. Die Aktivierung derUnicode-Prüfungen bringt dem Entwickler ausschließlich Vorteile, bei-spielsweise in Form einer strengeren statischen Typprüfung und einer strik-ten Trennung von Byte- und Zeichenkettenverarbeitung.
� Beim Anlegen eines neuen Programms ist das Attribut Festpunktarithmetik
bereits als Standardeinstellung gesetzt. Auch dieses Attribut darf niemalszurückgesetzt werden. Bei ausgeschalteter Festpunktarithmetik wird dieStellung des Dezimaltrennzeichens von gepackten Zahlen (Typ p) nur bei derAusgabe auf dem klassischen Dynpro oder bei der Formatierung mittelsWRITE TO berücksichtigt, nicht jedoch bei Berechnungen. Ein solches Verhal-ten wird heute nur in den seltensten Fällen den Erwartungen des Entwick-lers entsprechen. Soll mit gepackten Zahlen ohne Nachkommastellengerechnet werden, ist dies über den Zusatz DECIMALS 0 bei der Deklarationanzugeben.
� Beim Anlegen eines neuen ausführbaren Programms ist das Attribut Logi-
sche Datenbank leer. Durch dieses Attribut werden ausführbare Pro-gramme einer logischen Datenbank4 zugeordnet, wodurch das Selektions-bild und der Programmablauf des Programms mit dem Selektionsbild unddem Ablauf der logischen Datenbank kombiniert werden. Logische Daten-banken sollen nicht mehr verwendet werden, da sie auf der programmüber-greifenden Nutzung globaler Daten, einem impliziten Unterprogrammauf-ruf und der Reporting-Ereignissteuerung beruhen und damit modernenKonzepten zuwiderlaufen. Der Zugriff auf bestehende logische Datenban-ken kann bei Bedarf über den Funktionsbaustein LDB_PROCESS erfolgen, derbeispielsweise aus einer Methode heraus aufgerufen werden kann. Neue
3 Ein Programm mit eingeschalteten Unicode-Prüfungen wird als Unicode-Programm bezeich-net. Als Unicode-System bezeichnet man ein SAP-System, in dem die Zeichendarstellung imUnicode-Format (ISO/IEC 10646) erfolgt (derzeit UTF-16 mit plattformabhängiger Byterei-henfolge). Auf einem Unicode-System können nur Unicode-Programme, Unicode-Pro-gramme können aber auch auf Nicht-Unicode-Systemen ausgeführt werden. Die von SAPausgelieferten Programme sind in der Regel Unicode-Programme.
4 Eine logische Datenbank ist ein spezielles Entwicklungsobjekt, das im Logical Database Buil-der bearbeitet wird und anderen ABAP-Programmen Daten aus den Knoten einer hierarchi-schen Baumstruktur zur Verfügung stellt. Eine logische Datenbank verfügt über eine hierar-chische Struktur, ein in ABAP geschriebenes Datenbankprogramm und ein eigenesStandardselektionsbild.
1286.book Seite 59 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
60
logische Datenbanken sollen nicht mehr angelegt werden. Stattdessen sollein entsprechender Service über eine globale Klasse angeboten werden.
Da eine nachträgliche Änderung von Programmeigenschaften potenziell mitUmstellungsaufwand verbunden ist, sollten die richtigen Eigenschaften vonAnfang an eingestellt und nicht mehr geändert werden. Insbesondere bei Attri-buten, die die Syntaxprüfung beeinflussen (derzeit die Unicode-Prüfung) sollteman sich immer gleich für die größtmögliche Prüfschärfe entscheiden, um beispäteren eventuell angeordneten Umstellungen bestens vorbereitet zu sein.
Im Folgenden gehen wir davon aus, dass nur noch mit eingeschalteter Uni-code-Prüfung und Festpunktarithmetik und ohne logische Datenbanken gear-beitet wird. Für veraltete oder problematische Sprachkonstrukte, die nur nochbei ausgeschalteten Unicode-Prüfungen verfügbar sind, wird in diesen Richtli-nien daher keine spezielle Regel mehr erstellt. Wir erwähnen sie nur kurz imRahmen der Liste der obsoleten Sprachelemente (siehe Anhang A).
Schlechtes Beispiel
Abbildung 3.1 zeigt ein ABAP-Programm, bei dem in den Programmeigen-schaften das Attribut Unicode-Prüfungen aktiv entgegen der Empfehlungvon Regel 3.3 nicht ausgewählt ist.
In dem Nicht-Unicode-Programm aus Abbildung 3.1 ist es straflos möglich,einen schreibenden Teilfeldzugriff über zwei numerische Komponenten einer
Abbildung 3.1 Erlaubter Teilfeldzugriff auf eine Struktur in einem Nicht-Unicode-Programm
1286.book Seite 60 Donnerstag, 30. April 2009 12:06 12
Programmtyp und Programmeigenschaften 3.2
61
Struktur hinweg auszuführen, wobei – horribile dictu – ein implizites Casting(siehe Abschnitt 6.2.8) des Teilbereichs auf den Typ c stattfindet. Das Ergebnisin den Komponenten ist abhängig von Ausrichtungslücken, der internen Dar-stellung numerischer Werte (Bytereihenfolge) sowie der verwendeten Code-page und damit extrem plattformabhängig. Ein produktives Programm darfkeinesfalls solchen Code enthalten. Es führt in der Regel zu fehlerhaften Datenoder zu schwer nachvollziehbaren Laufzeitfehlern.
Gutes Beispiel
Abbildung 3.2 zeigt ein ABAP-Programm, bei dem in den Programmeigen-schaften nach Regel 3.3 das Attribut Unicode-Prüfungen aktiv ausgewählt ist.
Im Unicode-Programm aus Abbildung 3.2 führt der Code aus Abbildung 3.1 zueinem Syntaxfehler. Unerwünschte Teilfeldzugriffe sind wie andere uner-wünschte Zugriffe auf Strukturen oder andere Teile des Arbeitsspeichers ver-boten. Falls statisch erkennbar, führen diese wie im hier gezeigten Beispiel zueinem Syntaxfehler. Anderenfalls kommt es während der Programmausfüh-rung zu einem Laufzeitfehler mit einem aussagekräftigen Kurzdump.
Abbildung 3.2 Syntaxfehler bei Teilfeldzugriff auf eine Struktur in einem Unicode-Programm
1286.book Seite 61 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
62
3.2.3 Originalsprache
Hintergrund
Beim Anlegen eines neuen Repository-Objektes (beispielsweise eines Pro-gramms, einer Klasse oder einer Datenbanktabelle im ABAP Dictionary) mussseine Originalsprache festgelegt werden. Dies passiert implizit durch die aktu-elle Anmeldesprache. Alle während der Entwicklung angelegten übersetzungs-fähigen Texte des Entwicklungsobjektes, wie zum Beispiel beschreibende Kurz-und Langtexte, die Textelemente eines Programms und auch die Dokumenta-tion von Datentypen oder Schnittstellen, werden der angegebenen Original-sprache zugeordnet. Die Erstellung der Texte in anderen Sprachen erfolgtdurch einen von der Entwicklung losgelösten Übersetzungsvorgang aus derOriginalsprache in die Zielsprachen.
Derzeit gibt es keine technische Unterstützung für die projektweite Ersetzungeiner einmal gewählten Originalsprache durch eine andere Sprache.
Regel
Details
Bei der Festlegung der Originalsprache soll wie folgt vorgegangen werden:
� Bei einsprachiger Besetzung aller an einem Projekt beteiligten Entwicklungs-gruppen ist die Originalsprache aller Entwicklungsobjekte die Mutterspra-che aller beteiligten Entwickler (einsprachige Entwicklung).
� Bei mehrsprachiger Besetzung der Entwicklungsgruppen
� ist die Originalsprache aller Entwicklungsobjekte entweder eine vonallen Beteiligten verstandene Sprache – in der Regel Englisch – (einspra-chige Entwicklung)
� oder richtet sich die Originalsprache von Entwicklungsobjekten in Tei-len des Projektes nach der Muttersprache der hauptsächlich daran arbei-tenden Entwickler (mehrsprachige Entwicklung).
Regel 3.4: Originalsprache auf Projektebene festlegen
Legen Sie vor Beginn der Implementierung eine sorgfältig ausgewählte Originalspra-che auf Projektebene für die Repository-Objekte fest. Entwickler dürfen ihre Entwick-lungsobjekte nur in der für das jeweilige Projekt (oder in Ausnahmefällen für ein Teil-projekt) festgelegten Originalsprache anlegen.
1286.book Seite 62 Donnerstag, 30. April 2009 12:06 12
Programmtyp und Programmeigenschaften 3.2
63
Einsprachige Entwicklungsgruppen stellen sozusagen den Idealfall dar, sindheutzutage aber nicht immer zu realisieren. Die beiden möglichen Einstellun-gen für mehrsprachige Entwicklergruppen – einsprachige und mehrsprachigeEntwicklung – erfüllen zwei unterschiedliche Anforderungen, die sich aberwidersprechen:
� Bei der Anmeldung an einem System in einer anderen Sprache als der Ori-ginalsprache lässt sich im Allgemeinen nicht sinnvoll mit einem in der Ent-wicklung befindlichen oder neu entwickelten Produkt arbeiten, bis eineÜbersetzung der relevanten Texte in die jeweilige Zielsprache vorliegt. DieÜbersetzung erfolgt in der Regel in einem nachgelagerten Übersetzungssys-tem und muss in das Entwicklungssystem zurücktransportiert werden. Ausdiesem Grund ist eine effiziente Entwicklung, insbesondere in internationalbesetzten Entwicklungsgruppen (die eventuell auch noch über mehrereStandorte verteilt sind), nur dann möglich, wenn zu Beginn projektweit eineeinheitliche Originalsprache festgelegt wird, die es allen am Entwicklungs-und Validierungsprozess beteiligten Personen erlaubt, das Produkt zumin-dest testweise zu verwenden. Bei einsprachiger Entwicklung in mehrspra-chigen Entwicklungsgruppen müssen daher einige, wenn nicht gar alle Ent-wickler eines Projektes Texte in einer Sprache anlegen, die nicht ihre Mut-tersprache ist.
� Für die sprachliche und stilistische Überprüfung von Oberflächentexten undDokumentationen, die von Entwicklern in anderen Sprachen als ihrer Mut-tersprache angelegt werden, gibt es in der Regel keine Unterstützung inForm von Werkzeugen oder definierten Abläufen. Daher wäre es wün-schenswert, dass die an der Entwicklung von Benutzerdialogen und Doku-mentationen beteiligten Entwickler idealerweise in ihrer Muttersprachearbeiten und diese Texte dann von geschulten Übersetzern anhand von vor-gegebener Terminologie in deren Muttersprache übersetzt werden.
Der zweite Punkt ist der Grund, warum nicht Englisch als allumfassende ein-heitliche Originalsprache für alle Entwicklungsprojekte gefordert wird, son-dern dass einsprachige Entwicklungsgruppen durchaus in ihrer Muttersprachemit eventueller nachgelagerter Übersetzung arbeiten sollten.
Bei mehrsprachigen Entwicklungsgruppen kommt es letztendlich auf den kon-kreten Fall an, welche Originalsprache für jedes Entwicklungsobjekt festgelegtwird. In der Regel wiegt der erste Punkt schwerer, sodass bei internationalerEntwicklung eine einsprachige Entwicklung durchgeführt werden muss, umdie Entwicklungsressourcen für ein Projekt möglichst effektiv zu nutzen. InEinzelfällen kann es bei Teilprojekten, in denen besonders viel Text angelegt
1286.book Seite 63 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
64
werden muss, durchaus auch sinnvoll sein, die Originalsprache gemäß derMuttersprache der Entwickler festzulegen.5
Bei mehrsprachigen Projekten sollten betriebswirtschaftlich zusammengehö-rige Funktionen sprachenrein entwickelt werden, zumindest auf Paketebene.Auch Tabelleninhalte sollten in einer einheitlichen Sprache angelegt werden.
Hinweis
Da die Originalsprache beim Anlegen eines Repository-Objekts durch dieAnmeldesprache festgelegt wird, muss für das Anlegen und Bearbeiten vonRepository-Objekten ganz bewusst die Entscheidung für eine Anmeldesprachegetroffen werden.
Anmerkung
Unabhängig davon, ob eine ein- oder mehrsprachige Entwicklung innerhalbeines Projektes durchgeführt wird, muss vor Entwicklungsbeginn immer eineeinheitliche Terminologie für alle im Projekt angelegten Texte erstellt und diesedurchgängig befolgt werden. Bei einer mehrsprachigen Entwicklung sollte dieÜbersetzung der Terminologiebegriffe in die verwendeten Sprachen möglichstvor Beginn der Entwicklung vorgenommen werden, damit sie von den Ent-wicklern verwendet werden können. Zudem müssen immer die existierendenStandards für Oberflächentexte und Dokumentation befolgt werden (sieheAbschnitt 2.3, »Korrektheit und Qualität«).
3.3 Modernes ABAP
Hintergrund
ABAP ist eine lebendige Programmiersprache, die kontinuierlich weiterentwi-ckelt wird. Seit der Einführung von ABAP vor etwa 30 Jahren entstehen lau-fend neue ABAP-Programme, während parallel dazu an der Sprache ABAPselbst gearbeitet wird. Weiterentwicklungen an der Sprache ABAP sind entwe-der Erweiterungen der vorhandenen Spracheigenschaften, um neue Funktio-nalität einzuführen, oder der Ersatz vorhandener Funktionalität durch fortge-schrittenere Konzepte. Der Ersatz vorhandener durch neue Sprachelementemacht die vorhandenen in der Regel überflüssig bzw. obsolet. Das prominen-
5 Dies betrifft insbesondere die SAP-eigene Entwicklung, bei der nach wie vor größereAnteile von deutschsprachigen Entwicklern ausgeführt werden.
1286.book Seite 64 Donnerstag, 30. April 2009 12:06 12
Modernes ABAP 3.3
65
teste Beispiel einer Weiterentwicklung der Sprache ABAP ist nach wie vor dieEinführung von ABAP Objects zu Release 4.6.
SAP hat sich bezüglich der Sprache ABAP einer Politik der strikten Abwärts-kompatibilität verschrieben. Das bedeutet zum einen, dass ein beispielsweisezu R/3-Release 3.0 geschriebenes ABAP-Programm auf einem AS ABAP inRelease 7.2 unverändert ausgeführt werden kann, zumindest solange es sichum ein Nicht-Unicode-System handelt. Auf der anderen Seite bedeutet es aberauch:
� Ein erfahrener Entwickler wurde bisher durch fast nichts gezwungen, alteGewohnheiten abzulegen und sich mit neuen Konzepten zu beschäftigen.Die einzige Ausnahme stellt die Umstellung auf Unicode-Systeme dar, fürdie ABAP-Programme in Unicode-Programme mit leicht veränderten Syn-taxregeln umgewandelt werden müssen.
� ABAP-Einsteiger werden durch die Vielfalt der Möglichkeiten verwirrt, diees gibt, um ein und dasselbe zu tun. Wenn dann im Zweifelsfall ältere Pro-gramme als Vorlagen dienen, kommen oft statt der neuen weiterhin dieobsoleten Konzepte zum Einsatz.
Um diesen Problemen abzuhelfen, gibt es folgende einfache Regel.
Regel
Details
Neuere Sprachelemente sind immer die besseren Sprachelemente. ObsoleteSprachmittel werden nur aus Gründen der Abwärtskompatibilität weiterhinangeboten. Eine Anweisung oder ein Anweisungszusatz wird erst dann fürobsolet erklärt, wenn eine leistungsfähigere Alternative existiert oder dasSprachelement als fehlerträchtig (in dem Sinne, dass es zu unsicherer und nichtrobuster Programmierung einlädt) erkannt wurde. Aus diesem Grund ist einesichere und robuste Programmierung nicht mit dem Einsatz obsoleter Sprach-elemente zu vereinbaren. Damit verbietet sich die Verwendung solcher obso-leter Sprachmittel im Rahmen der Neuentwicklung.
Regel 3.5: Keine obsoleten Sprachmittel verwenden
Verwenden Sie für Neuentwicklungen keine obsoleten Sprachmittel. Auch für beste-hende Programme wird eine inkrementelle Umstellung auf neuere Konzepte empfoh-len, wie sie zur Verfügung stehen.
1286.book Seite 65 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
66
Bei der Verwendung von ABAP Objects ist ein Großteil der obsoleten Anwei-sungen und Zusätze bereits syntaktisch verboten. Unter anderem aus diesemGrund wird die Verwendung von ABAP Objects unbedingt empfohlen (sieheRegel 3.1). Außerhalb von ABAP Objects, das heißt in den Fällen, die nachAbschnitt 3.1, »ABAP Objects als Programmiermodell«, noch erlaubt sind,muss selbst Sorge dafür getragen werden, dass keine obsoleten Sprachelementezum Einsatz kommen. Hierfür liefert Anhang A, »Obsolete Sprachkonstrukte«,eine Übersicht der obsoleten Anweisungen und Anweisungszusätze.
Schlechtes Beispiel
Listing 3.3 zeigt die Lösung einer Aufgabe unter Verwendung obsoleter Sprach-mittel. Eine Prozedur soll in einem Text text alle Vorkommen einer Unterfolgesubstring durch eine neue Zeichenfolge new ersetzen, falls die Unterfolge nichtam Ende eines Wortes steht.
FORM bad_example USING substring TYPE csequencenew TYPE csequence
CHANGING text TYPE csequence.DATA: pattern TYPE string,
subrc TYPE sy-subrc.CONCATENATE '*' substring INTO pattern.SEARCH text FOR pattern.IF sy-subrc <> 0.
CLEAR subrc.WHILE subrc = 0.
REPLACE substring WITH new INTO text.subrc = sy-subrc.
ENDWHILE.ENDIF.
ENDFORM.
Listing 3.3 Verwendung obsoleter Sprachmittel
In Listing 3.3 sind, abgesehen von der Modularisierung mit FORM-ENDFORM, dieAnweisung SEARCH und die verwendete Variante von REPLACE ab Release 7.0obsolet. Darüber hinaus steht ab den Releases 7.0 EhP2 und 7.2 ein Zeichen-kettenoperator && als Ersatz für CONCATENATE zur Verfügung.
Gutes Beispiel
Listing 3.4 führt die gleiche Aufgabe wie Listing 3.3 unter Verwendung derneuesten zur Verfügung stehenden Sprachelemente aus.
1286.book Seite 66 Donnerstag, 30. April 2009 12:06 12
Modernes ABAP 3.3
67
METHOD good_example.FIND REGEX substring && `\b` IN text.IF sy-subrc <> 0.
REPLACE ALL OCCURRENCES OF substring IN text WITH new.ENDIF.
ENDMETHOD.
Listing 3.4 Verwendung moderner Sprachmittel
Das Unterprogramm wird durch eine Methode ersetzt. Durch Verwendungvon FIND in Zusammenhang mit einem regulären Ausdruck, der über den Zei-chenkettenoperator && zusammengesetzt wird, ist keine Hilfsvariable mehrnötig. Die WHILE-Schleife wird durch REPLACE ALL OCCURRENCES ersetzt, wobeieine weitere Hilfsvariable entfällt und der Kontrollfluss in die ABAP-Laufzeit-umgebung verschoben wird. Letzteres erhöht die Ausführungsgeschwindigkeitund ist auch zur Erfüllung von Regel 4.22 zur Beschränkung der maximalenSchachtelungstiefe hilfreich.
Anmerkung
Im Zusammenhang mit Regel 3.5, »Keine obsoleten Sprachmittel verwenden«,stellt sich die Frage, wie es mit der Koexistenz alter und neuer Konzepte inner-halb einer Programmeinheit aussieht. Es gibt nur eine Stelle, an der dies syn-taktisch klar geregelt ist, nämlich die Verwendung des klassischen und desklassenbasierten Ausnahmekonzeptes (siehe Abschnitt 5.2.2) in Verarbeitungs-blöcken. Anderenfalls können obsolete Sprachelemente in einem Programm-teil direkt neben neuen Sprachelementen stehen. Unsere Empfehlung hierzuist, die Verwendung innerhalb eines Kontextes möglichst einheitlich zu gestal-ten, das heißt nicht verschiedene Anweisungen, wie zum Beispiel FIND undSEARCH, nebeneinander zum gleichen Zweck einzusetzen.
Dies soll aber nicht bedeuten, dass bei Erweiterungen an bestehenden Proze-duren aus Gründen der Einheitlichkeit weiterhin obsolete Sprachelemente ver-wendet werden sollen, nur weil sie dort bereits vorhanden sind. Vielmehrsollte man die Gelegenheit ergreifen und gleich die gesamte Prozedur auf dieentsprechenden neuen Sprachelemente umstellen. Durch die Abdeckung derzu ändernden Prozeduren mit Modultests kann sichergestellt werden, dass esbei einer solchen Umstellung nicht zu Überraschungen kommt.
1286.book Seite 67 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
68
3.4 Prüfungen auf Korrektheit
In Abschnitt 2.3, »Korrektheit und Qualität«, wurde bereits allgemein auf dieKorrektheit und Qualität von Programmen eingegangen, und die für derenÜberprüfung vorhandenen Werkzeuge wurden kurz vorgestellt. Der vorlie-gende Abschnitt beschäftigt sich nochmals speziell mit der syntaktischen Kor-rektheit von ABAP-Programmen, die mit der Syntaxprüfung und der erweiter-ten Programmprüfung kontrolliert wird, sowie mit der Standardprüfung desCode Inspectors und dem neuen ABAP-Testcockpit.
3.4.1 Syntaxprüfung
Hintergrund
Die Syntaxprüfung liefert Syntaxfehler und Syntaxwarnungen.
� Sobald ein Syntaxfehler auftritt, wird die Prüfung beendet und eine entspre-chende Fehlermeldung angezeigt. In vielen Fällen wird eine Korrektur vor-geschlagen, die übernommen werden kann. Ein Programm mit Syntaxfeh-lern ist zwar aktivierbar, kann aber nicht generiert und damit nicht ausge-führt werden. Syntaxfehler werden von der erweiterten Programmprüfungals fatale Fehler gemeldet. Syntaxfehler müssen unbedingt behoben werden.
� Tritt eine Syntaxwarnung auf, wird die Syntaxprüfung nicht beendet, unddas Programm ist im Prinzip ausführbar. Die Syntaxwarnungen werdennach einer Ausführung der Syntaxprüfung im ABAP Editor und auch von dererweiterten Programmprüfung (siehe Abschnitt 3.4.2) angezeigt.6 Bei derAktivierung eines Programms werden Syntaxwarnungen nur dann ausgege-ben, wenn es gleichzeitig auch Syntaxfehler gibt.
Die von der Syntaxprüfung gemeldeten Warnungen sind in drei Prioritätenunterteilt, die aber nur von der erweiterten Programmprüfung angezeigtwerden:
� Priorität 1Fehler, die erkennbar zu einem Programmabbruch bei der Ausführungdes ABAP-Programms führen werden. Zudem alle Konstrukte, die kei-nesfalls verwendet werden sollen, da sie auf Programmierfehler hindeu-ten und höchstwahrscheinlich zu falschem Verhalten führen.
6 Natürlich zeigen Testwerkzeuge, die die Prüfungen der erweiterten Programmprüfungumfassen, wie der Code Inspector und das SAP-interne ABAP-Testcockpit (seit den Releases7.0 EhP2 und 7.2), die Syntaxwarnungen ebenfalls an.
1286.book Seite 68 Donnerstag, 30. April 2009 12:06 12
Prüfungen auf Korrektheit 3.4
69
� Priorität 2Alle Konstrukte, die nicht unbedingt zu Fehlverhalten führen, aber zumBeispiel obsolet sind und durch aktuelle Konstrukte ersetzt werden sol-len. Fehler der Priorität 2 können in zukünftigen Releases zu Fehlernder Priorität 1 oder zu Syntaxfehlern werden.
� Priorität 3Fasst alle Fehler zusammen, deren Behebung zwar wünschenswert, abernicht unbedingt für das aktuelle Release notwendig ist. Eine Verschär-fung der Priorität in kommenden Releases ist jedoch nicht ausgeschlos-sen.
Die Prüfschärfe der ABAP-Syntaxprüfung wird durch die beim Anlegen einesProgramms getroffenen Entscheidungen bestimmt (siehe Abschnitt 3.2, »Pro-grammtyp und Programmeigenschaften«). So können Programmkonstrukte,die außerhalb von Klassen oder in Nicht-Unicode-Programmen nur zu Syntax-warnungen führen, in Klassen oder in Unicode-Programmen echte Syntaxfeh-ler darstellen. Seit den Releases 7.0 EhP2 und 7.2 können ausgesuchte Syntax-warnungen durch sogenannte Pragmas7 unterdrückt werden.
Mit der Einführung des operationalen Paketkonzeptes ab Release 7.2 überprüftdie Syntaxprüfung auch Paketverletzungen. Dabei hängt es von der beimbetreffenden Paket eingestellten Kapselungsstärke ab, ob es zu einem Syntax-fehler oder lediglich zu einer Syntaxwarnung kommt.
Regel
Details
Die Ursachen von Syntaxwarnungen müssen immer korrigiert werden, da sieim Allgemeinen zu unvorhersagbaren Fehlern führen. Solche Warnungen wer-den von SAP häufig in einem späteren Release des AS ABAP zu Fehlern herauf-gestuft. In diesem Fall ist dann ein zunächst nur mit Syntaxwarnungen behaf-tetes Programm nach einem Upgrade syntaktisch falsch und nicht mehrbenutzbar. Genauso verhält es sich bei der Umstellung von Nicht-Unicode-Pro-
7 Ein Pragma ist eine Programmdirektive, die den Programmablauf nicht beeinflusst, sondernAuswirkung auf bestimmte Überprüfungen hat.
Regel 3.6: Syntaxwarnungen beachten
Nehmen Sie alle Warnungen der ABAP-Syntaxprüfung ernst. In einem fertiggestelltenProgramm dürfen keine Syntaxwarnungen mehr auftreten.
1286.book Seite 69 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
70
grammen auf Unicode-Programme oder bei der Migration älterer Programm-teile nach ABAP Objects.
Bezüglich der Paketprüfung stellt die konsequente Verwendung des bereits vorRelease 7.2 zur Verfügung stehenden Paketkonzeptes (Auswahl von Paketprü-
fung als Server im Package Builder) bzw. die Einstellung einer schwachenKapselung ab Release 7.2 einen ersten Schritt auf dem Weg zur echten Kapse-lung dar. Sie ermöglicht den Verwendern von Entwicklungsobjekten eineAnpassung ihrer Verwendungsstellen, noch bevor es zu harten Syntaxfehlernkommt. Aus diesem Grund müssen sowohl vor als auch nach Release 7.2 ins-besondere alle Warnungen der Paketprüfung ernst genommen und behobenwerden, damit das Programm auch nach einer verschärften Kapselung der ver-wendeten Pakete syntaktisch korrekt bleibt.
Schlechtes Beispiel
Abbildung 3.3 zeigt einen Ausschnitt eines Nicht-Unicode-Programms ineinem Nicht-Unicode-System, in dem eine VALUE-Angabe zu einer Syntaxwar-nung führt, weil ein nicht typgerechter Startwert für eine Struktur gesetzt wird.
Abbildung 3.3 Programm mit Syntaxwarnung
1286.book Seite 70 Donnerstag, 30. April 2009 12:06 12
Prüfungen auf Korrektheit 3.4
71
Anmerkung
In einem Unicode-Programm – das heißt einem Programm, für das die Pro-grammeigenschaft Unicode-Prüfungen aktiv gesetzt ist – führt die Anwei-sung, die in Abbildung 3.3 nur zu einer Warnung führt, zu einem Syntaxfehler.
Gutes Beispiel
Abbildung 3.4 zeigt das korrigierte Programm aus Abbildung 3.3. Die Kompo-nenten der Struktur werden im Instanzkonstruktor typgerecht mit Startwertenversorgt. Das Programm ist frei von Syntaxwarnungen und auch als Unicode-Programm korrekt.
3.4.2 Erweiterte Programmprüfung
Hintergrund
Die erweiterte Programmprüfung kann für aktivierte Programme entweder ausder ABAP Workbench heraus oder über die Transaktion SLIN aufgerufen wer-den. Sie führt statische Prüfungen durch, die für die normale Syntaxprüfung zuaufwendig sind. Es können entweder einzelne oder mehrere Teiltests oder eineStandardprüfung durchgeführt werden, die die wichtigsten Teiltests umfasst.
Abbildung 3.4 Korrektes Programm ohne Syntaxwarnung
1286.book Seite 71 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
72
Die erweiterte Programmprüfung gibt Fehler, Warnungen und Meldungenaus. Von der Standardprüfung werden die Fehler und Warnungen gemeldet,die besonders kritisch sind.8 Darüber hinaus werden immer auch die Fehlerund Warnungen der Syntaxprüfung angezeigt.
Seit den Releases 7.0 EhP2 und 7.2 kann im Einstiegsbild der erweiterten Pro-grammprüfung auch eine Prüfung von Programmierrichtlinien ausgewähltwerden, die die Einhaltung einiger der in diesem Buch vorgestellten Regeln,die statisch verifiziert werden können, überprüft.
Die Meldungen der erweiterten Programmprüfung, die in speziellen Sonder-fällen unzutreffend sind, können über Pseudokommentare und seit denReleases 7.0 EhP2 und 7.2 über Pragmas ausgeblendet werden. Meldungen, diedirekt von der normalen Syntaxprüfung kommen, ließen sich vor den Releases7.0 EhP2 und 7.2 nicht ausblenden.
Regel
Details
Die von der erweiterten Programmprüfung ausgegebenen Fehler, Warnungenund Meldungen sind genauso wichtig wie die Syntaxfehler und Syntaxwarnun-gen der Syntaxprüfung (siehe Abschnitt 3.4.1). Ein von der erweiterten Pro-grammprüfung gemeldeter Fehler kann zum Beispiel darauf hinweisen, dassein Programm bei der Ausführung sicher zu einem Laufzeitfehler führt. War-nungen und Meldungen weisen in der Regel auf die fragwürdige Verwendungvon Sprachelementen hin, die aller Voraussicht nach zu unerwartetem Pro-grammverhalten führt.
In den seltenen Fällen, in denen ein von der erweiterten Programmprüfunggemeldetes Prüfergebnis unberechtigt ist, muss dies durch einen geeignetenPseudokommentar oder ein Pragma (seit den Releases 7.0 EhP2 und 7.2) doku-mentiert werden (der geeignete Pseudokommentar bzw. das Pragma wird in
8 Die Einstufung eines einzelnen Ergebnisses als Fehler, Warnung oder Meldung kann variie-ren, je nachdem, ob eine Standardprüfung oder aber explizit ausgewählte Einzelprüfungendurchgeführt werden.
Regel 3.7: Erweiterte Programmprüfung verwenden
Verwenden Sie die erweiterte Programmprüfung, und nehmen Sie ihre Ergebnisseernst. Für ein fertiggestelltes Programm dürfen keine Meldungen der Standardprü-fung mehr auftreten.
1286.book Seite 72 Donnerstag, 30. April 2009 12:06 12
Prüfungen auf Korrektheit 3.4
73
der Meldung jeweils genannt). Dadurch wird diese Meldung der erweitertenProgrammprüfung unterdrückt. Idealerweise sollte in weniger offensichtlichenSituationen ein zusätzlicher Kommentar erläutern, warum an dieser Stelle dieMeldung nicht zutreffend ist.
Hinweis
Die erweiterte Programmprüfung ist eine wertvolle Hilfe beim Schreiben kor-rekter ABAP-Programme. Dieser Vorteil darf nicht durch Verwendung unspe-zifischer Pseudokommentare oder Pragmas zunichte gemacht werden. Insbe-sondere sollte die Anweisung
SET EXTENDED CHECK OFF.
niemals verwendet werden, die alle Meldungen der erweiterten Programmprü-fung für einen gesamten Quelltextabschnitt unterdrückt.
Wird ein ABAP-Programm einem Code-Review unterzogen, sollten die Ergeb-nisse der erweiterten Programmprüfung zur Beurteilung der Qualität mit her-angezogen werden.
Schlechtes Beispiel
Abbildung 3.5 zeigt das Ergebnis einer Teilprüfung der erweiterten Programm-prüfung, die seit den Releases 7.0 EhP2 und 7.2 ausgeführt wird. Sie macht aufeine äußerst fragwürdige Abfrage des Inhalts von sy-subrc aufmerksam (sieheAbschnitt 6.3.4, »Rückgabewert«).
Abbildung 3.5 Warnung der erweiterten Programmprüfung
1286.book Seite 73 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
74
Der Programmabschnitt zeigt einen typischen Fehler in einem syntaktisch kor-rekten Programm. Der Entwickler nimmt fälschlicherweise an, dass die stati-sche Form der Anweisung ASSIGN das Systemfeld sy-subrc setzt, was aber nichtder Fall ist. Dies hat zur Folge, dass er sich zum einen in der falschen Sicherheitwiegt, sein Programm abgesichert zu haben, und zum anderen ein falsches Pro-grammverhalten auftritt, wenn sy-subrc von vorhergehenden Anweisungenher einen Wert ungleich null hat. Der große Vorteil der erweiterten Programm-prüfung ist daher, dass nicht nur einzelne Anweisungen auf syntaktische Kor-rektheit, sondern ganze Programmabschnitte auf semantische Fehler hin unter-sucht werden.
Gutes Beispiel
Abbildung 3.6 zeigt die korrigierte Fassung des Programms aus Abbildung 3.5.Statt der falschen Abfrage von sy-subrc wird der in der Dokumentation emp-fohlene logische Ausdruck IS ASSIGNED verwendet. Die Meldung der erweiter-ten Programmprüfung wäre zwar auch durch einen Pseudokommentar "#ECRC_READ oder ein Pragma ##SUBRC_READ (seit den Releases 7.0 EhP2 und 7.2)ausblendbar, aber das wird in einem solchen Fall wie hier gerade nicht emp-fohlen, da die erweiterte Programmprüfung auf ein echtes Problem hinweist.
Abbildung 3.6 Erweitere Programmprüfung ohne Meldung
1286.book Seite 74 Donnerstag, 30. April 2009 12:06 12
Prüfungen auf Korrektheit 3.4
75
3.4.3 Code Inspector
Hintergrund
Der Code Inspector ist ein Werkzeug zur statischen Überprüfung von Reposi-tory-Objekten bezüglich Performance, Sicherheit, Syntax und der Einhaltungvon Namenskonventionen. Der volle Funktionsumfang des Code Inspectorskann über die Transaktion SCI verwendet werden, um komplexe statische Prü-fungen sowie regelmäßige Massentests für große Mengen von Entwicklungs-objekten auszuführen.
Der Code Inspector kann auch aus der ABAP Workbench heraus aufgerufenwerden, um eine Standardmenge an Prüfungen für ihr aktuelles Objekt durch-zuführen, wie zum Beispiel über den Menüpfad Programm � Prüfen � Code
Inspector des ABAP Editors. Die hierbei verwendete Standardprüfvarianteenthält die meisten Prüfungen der erweiterten Programmprüfung (sieheAbschnitt 3.4.2) sowie einige weitere Sicherheits- und Performanceprüfungen.Weiterhin kann der Code Inspector in die Freigabe von Transporten eingebun-den werden.
Wie bei der erweiterten Programmprüfung sind auch die Ergebnisse des CodeInspectors in die drei Kategorien Fehler, Warnungen und einfache Meldungenunterteilt und können mit speziellen Pseudokommentaren ausgeblendet wer-den.
Regel
Details
Wird Regel 3.7, »Erweiterte Programmprüfung verwenden«, beachtet, meldetdie Standardprüfvariante des Code Inspectors nur noch Meldungen von Prü-fungen, die über die erweiterte Programmprüfung hinausgehen. Dies sind imWesentlichen Meldungen über eventuelle Performance- oder Sicherheitsrisi-ken in Programmen. Beispiele sind Meldungen über ungünstige WHERE-Bedin-gungen beim SELECT, die Wertübergabe statt der Referenzübergabe von Para-metern oder unsichere Programmaufrufe.
Diese Probleme sind, verglichen mit den Meldungen der erweiterten Pro-grammprüfung, nicht immer so einfach an der Ursache zu korrigieren, bei-
Regel 3.8: Standardprüfvariante des Code Inspectors verwenden
Führen Sie die Standardprüfvariante des Code Inspectors vor der Freigabe eines Pro-gramms aus, und beseitigen Sie sämtliche Fehlermeldungen.
1286.book Seite 75 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
76
spielsweise weil es keine andere Möglichkeit für eine Selektion gibt oder dieÜbersichtlichkeit oder Robustheit eines Konstruktes als wichtiger als ein even-tueller kleiner Performanceverlust angesehen wird.
In solchen Fällen können die Meldungen mit den passenden Pseudokommen-taren unterdrückt werden. Ein solcher Pseudokommentar drückt für den Leserdes Programms klar aus, dass der Programmautor die entsprechenden Über-prüfungen durchgeführt hat und er die Meldung bewusst und aus guten Grün-den unterdrückt. Letzteres kann, wo notwendig, durch zusätzliche normaleKommentare erhärtet werden (siehe Abschnitt 4.3).
Schlechtes Beispiel
Abbildung 3.7 zeigt das Ergebnis eines Code-Inspector-Laufs für eine Beispiel-klasse. Es werden Warnungen ausgegeben, weil eine interne Tabelle per Wert-übergabe zurückgegeben und in der SELECT-Anweisung ein Inner Join fürDatenbanktabellen mit eingeschalteter SAP-Pufferung verwendet wird.
Abbildung 3.7 Warnungen des Code Inspectors
1286.book Seite 76 Donnerstag, 30. April 2009 12:06 12
Prüfungen auf Korrektheit 3.4
77
Gutes Beispiel
Abbildung 3.8 zeigt die korrigierte Fassung des Programms aus Abbildung 3.7,für die der Code Inspector keine Meldungen mehr ausgibt.
Die Wertübergabe der internen Tabelle wurde durch eine Referenzübergabeersetzt. Bei der Übergabe des elementaren Parameters langu wurde die Wert-übergabe aus Gründen der Robustheit belassen. In der verwendeten Standard-prüfung hatte sie auch keine Warnung erzeugt. Wenn der Code Inspector ineinem solchen Fall eine Warnung anzeigt, kann sie mit dem Pseudokommentar"#EC CI_VALPAR ausgeblendet werden.
Der Inner Join der SELECT-Anweisung umgeht die SAP-Pufferung, was beieinem häufigen Aufruf der Methode zu Performanceproblemen führen würde.Wenn wir für das gezeigte Beispiel aber annehmen, dass die Methode Teileiner größeren Anwendung ist, in der selbst für eine Pufferung der ausgewähl-ten Daten über Shared Objects gesorgt wird, ist die Verwendung des InnerJoins anderen weniger performanten Konstrukten, wie zum Beispiel einer
Abbildung 3.8 Code-Inspektion ohne Meldungen
1286.book Seite 77 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
78
geschachtelten SELECT-Schleife, vorzuziehen. Deshalb wird die Warnung desCode Inspectors über den Pseudokommentar "#EC CI_BUFFJOIN ausgeblendetund die Gründe hierfür über einen normalen Kommentar erläutert.
3.4.4 ABAP-Testcockpit
Hintergrund
Seit den Releases 7.0 EhP2 und 7.2 ist mit dem ABAP-Testcockpit (ATC) zurSAP-internen Verwendung ein Framework in die ABAP Workbench integriert,das den entwicklungsnahen Umgang mit den notwendigen Tests erheblicherleichtert. Das ATC erlaubt die Ausführung und Ergebnisanzeige verschiede-ner Tests für Entwicklungsobjekte, wie beispielsweise:
� erweiterte Programmprüfungen
� statische Performanctests
� Modultests mit ABAP Unit
� statische Bedienbarkeitstests
� Paketprüfungen
Während der Code Inspector nur über die in Abschnitt 3.4.3 aufgeführte Stan-dardprüfung in die Entwicklungsumgebung integriert ist und ansonsten nurüber eine eigene Transaktion bedienbar ist, ist das ATC vollständig in denObject Navigator und den Transport Organizer integriert und steht dort fürentwicklungsbegleitende Tests zur Verfügung. Qualitätsmanagern erlaubt dasATC die Durchführung von Massentests. Das ABAP-Testcockpit steht vorerstaber nur bei SAP selbst und eventuell bei SAP-Partnern für die Entwicklungvon SAP-Programmen zur Verfügung.
Regel
Details
Mit dem ATC steht erstmals ein Werkzeug zur Verfügung, das von SAP-Ent-wicklern und im Rahmen einer zentralen Qualitätssicherung gleichermaßen
Regel 3.9: ABAP-Testcockpit richtig konfigurieren und verwenden
Ist das ABAP-Testcockpit in Ihrem System verfügbar, stellen Sie vor einer Transport-freigabe sicher, dass ein ATC-Lauf über alle beteiligten Entwicklungsobjekte hinwegkeine Meldungen mehr anzeigt. Hierzu sollte die ATC-Prüfung direkt in die Trans-portfreigabe eingebunden werden.
1286.book Seite 78 Donnerstag, 30. April 2009 12:06 12
Prüfungen auf Korrektheit 3.4
79
verwendet werden kann. Überprüft ein Entwickler beispielsweise alle Entwick-lungsobjekte eines Paketes im Entwicklungssystem mit der gleichen ATC-Kon-figuration, wie ein Qualitätsmanager es im Rahmen eines Massenlaufs in einemKonsolidierungssystem tut, kann er alle Meldungen im Vorfeld verhindern,ohne auf Rückmeldungen vom Qualitätsmanager warten zu müssen.
Ist das ATC vorhanden und richtig konfiguriert, schließt Regel 3.9 die vorher-gehenden Regeln 3.6, 3.7 und 3.8 mit ein.
Ausnahme
Das ATC steht derzeit noch nicht für Entwicklungen in Kundensystemen zurVerfügung.
Schlechtes Beispiel
Abbildung 3.9 zeigt das Ergebnis der Ausführung eines ATC-Laufs im TransportOrganizer. Der geprüfte Transportauftrag enthält noch fehlerhafte Objekte.
Abbildung 3.9 Warnung des ABAP-Testcockpits
1286.book Seite 79 Donnerstag, 30. April 2009 12:06 12
ABAP-spezifische Grundregeln3
80
Gutes Beispiel
Abbildung 3.10 zeigt das Ergebnis eines ATC-Laufs im Transport Organizernach Behebung des Fehlers aus Abbildung 3.9. Jetzt kann der Transport freige-geben werden.
Abbildung 3.10 ABAP-Testcockpit ohne Meldungen
1286.book Seite 80 Donnerstag, 30. April 2009 12:06 12
389
Index
& � Literaloperator&& � Verkettungsoperator<, Schreibweise 139<=, Schreibweise 139=, Schreibweise 139, 147=<, obsolet 361=> � Klassenkomponentenselektor=>, obsolet 361-> � Instanzkomponentenselektor>, Schreibweise 139><, obsolet 361>=, Schreibweise 139?=, Schreibweise 147?TO, Schreibweise 1474GL-Sprache, Hintergrund 162
A
ABAP-AnweisungAnordnung 85Beispiel 87Schreibweise 138
abap_boolHintergrund 247Verwendung 247
ABAP Database Connectivity � ADBCABAP Dictionary
Hintergrund 226Verwendung 228
abap_falseHintergrund 247Verwendung 247
ABAP ObjectsBeispiel 50Hintergrund 43Regel 44
ABAP-Programmierungklassisch 27objektorientiert 159
ABAP-SprachmittelBeispiel 165Hintergrund 64Koexistenz 67Regel 65Verwendung 163
ABAP-Testcockpit � ATCabap_true
Hintergrund 247Verwendung 247
abap_undefinedVerwendung 248
ABAP UnitModultest 40
ABAP-WortNamensgebung 110
AbbruchmeldungVerwendung 199
abfangbarer LaufzeitfehlerHintergrund 193obsolet 360Regel 194
AbwärtskompatibilitätHintergrund 65
ADBCHintergrund 216Verwendung 217
ADDVerwendung 147
ADD FROMobsolet 364
ADD THENobsolet 364
ADD-CORRESPONDINGobsolet 364
aktivierbare AssertionVerwendung 196
ALVHintergrund 209
ALV-ListeBeispiel 211
anonymer ContainerHintergrund 267Regel 267
anonymes DatenobjektBeispiel 339dynamisches Speicherobjekt 325Hintergrund 223
AnwendungslogikTrennung der Belange 31
1286.book Seite 389 Donnerstag, 30. April 2009 12:06 12
390
Index
AnwendungspufferBeispiel 221Hintergrund 219Verwendung 220
arithmetischer AusdruckBeispiel 152Schreibweise 148
ASCII-ZeichensatzVerwendung 346
ASSERTHintergrund 195Verwendung 196
AssertionBeispiel 196Hintergrund 177, 195Regel 195Verwendung 178, 199
ASSIGNdynamischer Zugriff 332Verwendung 333
ASSIGN DECIMALSobsolet 363
ASSIGN LOCAL COPY OFobsolet 358
ASSIGN TABLE FIELDobsolet 364
ASSIGN TYPEobsolet 363
ASSIGNINGBeispiel 295dynamischer Zugriff 332Verwendung 294
AT LINE-SELECTIONHintergrund 314
AT PFnnobsolet 370
AT SELECTION-SCREENHintergrund 314Verwendung 315
AT USER-COMMANDHintergrund 314
ATCBeispiel 79, 80Hintergrund 78Regel 78Verwendung 78
AtomisierungBeispiel 164
AusdruckKomplexität 151Regel 151
ausführbares ProgrammProgrammtyp 53Regel 55Trennung der Belange 26Verwendung 57
AusgabeparameterHintergrund 299
AusnahmeHintergrund 177Namensgebung 100Verwendung 178
AusnahmebehandlungHintergrund 179Regel 180Remote Function Call 181
AusnahmekategorieHintergrund 183Regel 184
AusnahmeklasseBeispiel 188, 189Hintergrund 187Regel 188Verwendung 188
AusnahmetextBeispiel 187Hintergrund 185Regel 185
B
BAdINamenskonvention 105
BarrierefreiheitProduktstandard 37, 212Regel 212
benanntes DatenobjektHintergrund 223
BenutzerfreundlichkeitProduktstandard 38
BerechnungHintergrund 249Regel 147Schreibweise 147
BETWEENSchreibweise 139
1286.book Seite 390 Donnerstag, 30. April 2009 12:06 12
391
Index
BezeichnerBeispiel 102, 103, 107Hintergrund 96Regel 97
BezeichnerspracheBeispiel 96Hintergrund 95Regel 95
binäre GleitpunktzahlBeispiel 260Hintergrund 257Verwendung 259
Bit-AusdruckSchreibweise 148
BOMOPEN DATASET 348Textdatei 348
Boolescher DatentypHintergrund 247
Boxed ComponentHintergrund 234Verwendung 328
Browser ControlVerwendung 213
BSPVerwendung 202
Business Add-In � BAdIBusiness Server Pages � BSPByte-Order Mark � BOMBytestring
Hintergrund 243
C
CALL CUSTOMER SUBSCREENobsolet 369
CALL CUSTOMER-FUNCTIONobsolet 359
CALL DIALOGobsolet 359
CALL FUNCTION IN UPDATE TASKVerwendung 47
CALL METHODRegel 145
CALL SCREENHintergrund 200Verwendung 47
CALL SELECTION-SCREENHintergrund 200
CALL SELECTION-SCREEN (Forts.)Verwendung 47
CALL TRANSACTIONProgrammausführung 54
CALL TRANSFORMATIONVerwendung 268
Camel Case StyleBeispiel 84Verwendung 83
CASEKomplexität 153obsolet 361
CASTINGASSIGN 263Beispiel 265Hintergrund 263implizites 264Regel 264Verwendung 333
CATCHHintergrund 190
CATCH SYSTEM-EXCEPTIONSBeispiel 194Hintergrund 193obsolet 360Verwendung 194
CHANGINGBeispiel 301Hintergrund 299Namenskonvention 109Verwendung 300
CHECKBeispiel 313Hintergrund 312Verwendung 312
Checkpoint-GruppeAssertion 195, 196
CL_JAVA_SCRIPTobsolet 374
Class-Poollokale Deklaration 173Programmtyp 53Regel 55Verwendung 56
CLEANUPBeispiel 193Hintergrund 191Regel 192
1286.book Seite 391 Donnerstag, 30. April 2009 12:06 12
392
Index
CLEANUP (Forts.)Verwendung 192
CLEARVerwendung 327
CLEAR WITH NULLobsolet 363
CLIENT SPECIFIEDVerwendung 218
Code InspectorBeispiel 76, 77Fehler 75Hintergrund 75Meldung 75Namenskonvention 375Pseudokommentar 75Regel 75Verwendung 75Warnung 75
CodepageTextdatei 348
COLLECTHintergrund 292Regel 293Verwendung 293
COMMON PARTobsolet 355
COMMUNICATIONobsolet 374
COMPUTEBeispiel 149, 150Regel 149
COMPUTE EXACTVerwendung 149
CONSTANTSHintergrund 226
constructorMETHODS 175
CONTEXTSobsolet 373
CONTROLSVerwendung 232
CONVERT DATEobsolet 365Verwendung 252
CONVERT TIME STAMPVerwendung 252
Coverage AnalyzerTestabdeckung 40
CREATE AREA HANDLEVerwendung 220
CREATE DATAdynamischer Zugriff 332Regel 336
CREATE-ZusatzCLASS DEFINITION 175
CX_DYNAMIC_CHECKHintergrund 183Regel 191
CX_NO_CHECKHintergrund 183Regel 191
CX_ROOTRegel 191
CX_STATIC_CHECKHintergrund 183Regel 191
D
DATAVerwendung 232
DATA COMMON PARTSchnittstellen-Arbeitsbereich 310
DateiHintergrund 214Verwendung 215
DatenbanktabelleHintergrund 214Verwendung 214
DatenbankzugriffHintergrund 216Regel 216
Daten-ClusterVerwendung 215
DatenkapselungABAP Objects 44
DatenobjektBezug auf 237Hintergrund 223
DatenreferenzBeispiel 334dynamischer Zugriff 332Regel 333Verwendung 333
DatentypBeispiel 236, 280Bezug auf 237
1286.book Seite 392 Donnerstag, 30. April 2009 12:06 12
393
Index
Datentyp (Forts.)Hintergrund 223, 226, 235Namensgebung 98Namenskonvention 114Regel 225, 227, 235
DatumsfeldHintergrund 251Verwendung 251
DeklarationKettensatz 141
DELETE dbtabobsolet 373
DEMANDobsolet 373
DereferenzierungVerwendung 333
DESCRIBE FIELDVerwendung 336
DETAILobsolet 369
dezimale GleitpunktzahlBeispiel 261Hintergrund 257Verwendung 259
DialogmodulHintergrund 297, 314Regel 315Verwendung 47, 206
DialognachrichtVerwendung 198
DialogprogrammBeispiel 207Trennung der Belange 26
DialogtransaktionProgrammausführung 54Verwendung 47
DIVIDEVerwendung 147
DIVIDE-CORRESPONDINGobsolet 364
DOKomplexität 153
DO VARYINGobsolet 362
DokumentationMittel 40Produktstandard 37
Doppelpunkt-Komma-Logik � Kettensatz
DrucklisteHintergrund 209
Druckparameterobsolet 370
dynamische ProgrammierungBeispiel 322, 323Hintergrund 319Regel 320Verwendung 320
dynamische Token-AngabeBeispiel 339Hintergrund 335Verwendung 322, 336
dynamischer AufrufHintergrund 319, 335Verwendung 322
dynamischer ZugriffHintergrund 319, 332, 335Regel 333Verwendung 322, 333
dynamisches DatenobjektHintergrund 323Regel 324Verwendung 322
dynamisches SpeicherobjektBeispiel 328Besetzung 331Hintergrund 319Regel 326, 330Speicherverbrauch 325Verwaltung 329
DynproBeispiel 203, 207Hintergrund 200Regel 205Verwendung 202, 310
E
eCATTSzenarientest 40
EDITOR-CALLobsolet 366
eigenständiger DatentypBeispiel 226Hintergrund 224
EingabeparameterHintergrund 299
1286.book Seite 393 Donnerstag, 30. April 2009 12:06 12
394
Index
EinrückungKommentar 124Verwendung 89
einsprachige EntwicklungRegel 62
ENCODINGOPEN DATASET 348
END-OF-SELECTIONHintergrund 314Programmausführung 55
EnglischBezeichnersprache 95Entwicklungssprache 63Kommentarsprache 119Verwendung 95
EntwicklungsspracheHintergrund 62
EQSchreibweise 139
EreignisABAP Objects 45Namensgebung 99
EreignisbehandlerNamensgebung 99
EreignisblockHintergrund 297, 314Regel 315Verwendung 47
error_messageVerwendung 198
erweiterte ProgrammprüfungBeispiel 73, 74Fehler 72Hintergrund 71Meldung 72Regel 72Verwendung 72Warnung 72
EXACTCOMPUTE 149MOVE 254
Exclusive BufferVerwendung 220
EXITHintergrund 312Verwendung 312
Exit-MeldungVerwendung 199
EXPORTSchreibweise 139
EXPORT TO DATA BUFFERVerwendung 268, 324
EXPORT TO INTERNAL TABLEVerwendung 325
EXPORTINGBeispiel 300, 305Hintergrund 299Namenskonvention 109Referenzübergabe 303Regel 304Verwendung 300, 304
externer ProzeduraufrufHintergrund 308
F
FehlerCode Inspector 75erweiterte Programmprüfung 72
FehlermeldungVerwendung 198
FehlersituationBehandlung 177Regel 177
FeldsymbolBeispiel 334dynamischer Zugriff 332Regel 333Typisierung 307Verwendung 333
FestpunktarithmetikProgrammattribut 58Regel 58Verwendung 59
FIELD (Dynpro)obsolet 368
FIELDSobsolet 358
FIELD-SYMBOLSDeklaration 231obsolet 356
finale KlasseVerwendung 171
FINDSchreibweise 140
FORMobsolet 354
1286.book Seite 394 Donnerstag, 30. April 2009 12:06 12
395
Index
FormalparameterArt 299Regel 299, 302Typisierung 305Übergabe 301
FORMATHintergrund 201
FREEVerwendung 327
Function-PoolProgrammtyp 53
funktionale KorrektheitProduktstandard 37
funktionale MethodeNamensgebung 99, 113
FunktionsbausteinHintergrund 297Regel 298Verwendung 47, 309
FunktionsgruppeBeispiel 48, 232globaler Deklarationsteil 130Komplexität 156Programmtyp 53Regel 55Verwendung 56, 205
G
Garbage CollectorVerwendung 327
GESchreibweise 139
gebundener DatentypBeispiel 226Hintergrund 224
GENERATE SUBROUTINE POOLHintergrund 335Verwendung 47
generische ProgrammierungHintergrund 320, 335Regel 336Verwendung 322
generische TypisierungBeispiel 307Hintergrund 306
generischer DatentypHintergrund 306
gepackte ZahlHintergrund 257Verwendung 258
GETHintergrund 314Programmausführung 55
GET REFERENCEdynamischer Zugriff 332
GleitpunktzahlHintergrund 258
globale AusnahmeklasseNamenskonvention 105
globale DeklarationAnordnung 128Beispiel 129, 130Top-Include 128
globale Klasselokale Deklaration 173Namenskonvention 105Verwendung 227
globale VariableVerwendung 231
globaler DeklarationsteilHintergrund 127Regel 127
globales DatenobjektHintergrund 268Namensgebung 113Namenskonvention 109
globales InterfaceNamenskonvention 105
GlobalisierungProduktstandard 37, 340
Groß-/KleinschreibungBeispiel 84Hintergrund 82Regel 83Verwendung 83, 90
GTSchreibweise 139
GUI-StatusVerwendung 310
GUI-TitelÜbersetzbarkeit 343
gültiger WertBeispiel 252Hintergrund 250Regel 251
1286.book Seite 395 Donnerstag, 30. April 2009 12:06 12
396
Index
GültigkeitsbereichNamenskonvention 114
H
Hash-SchlüsselHintergrund 285Verwendung 287
Hash-TabelleHintergrund 282Tabellenart 283Verwendung 285
HauptprogrammHintergrund 309
HauptprogrammgruppeHintergrund 309
Headerdynamisches Speicherobjekt 329
HEADER LINEobsolet 357
HilfsvariableBeispiel 152, 238Deklaration 237Verwendung 151
HintergrundverarbeitungVerwendung 47
I
IFKomplexität 153
IMPORTSchreibweise 139
IMPORTINGHintergrund 299Namenskonvention 109Verwendung 300
INSchreibweise 139
INCLUDE STRUCTUREHintergrund 233Verwendung 233
INCLUDE TYPEBeispiel 234Hintergrund 233Verwendung 233
Include-ProgrammBeispiel 137Hintergrund 134, 136
Include-Programm (Forts.)Mehrfachverwendung 136Regel 134, 136Verwendung 134, 229
IndextabelleTabellenart 283Verwendung 285
INDXVerwendung 215
InformationsnachrichtVerwendung 198
INITIAL SIZEBeispiel 290Hintergrund 289Regel 289Verwendung 289
INITIALIZATIONHintergrund 314Verwendung 315
INPUTobsolet 369
INSERT REPORTHintergrund 335
InstanzierungABAP Objects 44
InstanzkomponenteHintergrund 166
InstanzkomponentenselektorNamensgebung 112, 113
InstanzkonstruktorHintergrund 175Regel 176Verwendung 167
IntegerzahlHintergrund 257Verwendung 258
intenationale EntwicklungEntwicklungssprache 63
InterfaceABAP Objects 45Namensgebung 98Verwendung 171
Interfacekomponenten-SelektorBeispiel 172Hintergrund 171Regel 171Verwendung 172
Interface-PoolProgrammtyp 53
1286.book Seite 396 Donnerstag, 30. April 2009 12:06 12
397
Index
Interface-Pool (Forts.)Regel 55Verwendung 56
Interface-ReferenzvariableBeispiel 172Hintergrund 171Regel 171
InternationalisierungHintergrund 340Produktstandard 37
interne TabelleAusgabeverhalten 293befüllen 291, 292dynamisches Datenobjekt 323Hintergrund 281Schleifenverarbeitung 296Sekundärschlüssel 285Speicherbedarf 289Tabellenart 283Verwendung 324
interner ProzeduraufrufHintergrund 308
INTOREAD TABLE, LOOP AT 294
IS ASSIGNEDSchreibweise 139
IS BOUNDSchreibweise 139
IS INITIALSchreibweise 139
IS REQUESTEDobsolet 361
IS SUPPLIEDSchreibweise 139
J
Java-KonventionVerwendung 84
K
KapselungHintergrund 160Regel 161
kaufmännische NotationHintergrund 255
KettensatzHintergrund 141
Kettensatz (Forts.)Regel 141Verwendung 141
KISS-PrinzipBeispiel 35Hintergrund 34Regel 34
KlasseKomplexität 155Namensgebung 98
klassenbasierte AusnahmeBehandlung 189Beispiel 182Hintergrund 179Regel 190Verwendung 180Weiterleitung 189
KlassengrößeHintergrund 155Regel 156
KlassenkomponenteNamensgebung 112
KlassenkomponentenselektorNamensgebung 112
KlassenreferenzvariableHintergrund 171Verwendung 172
klassische AusnahmeBeispiel 181Hintergrund 179Verwendung 180
klassische ListeBeispiel 211Hintergrund 209Verwendung 210
KleinschreibungBeispiel 90
kombinierende ZeichenHintergrund 347
KommentarAnordnung 123Beispiel 122, 125, 126Hintergrund 118Pseudokommentar 124Regel 121Übersetzbarkeit 340Verwendung 120, 152
KommentarspracheBeispiel 119, 120
1286.book Seite 397 Donnerstag, 30. April 2009 12:06 12
398
Index
Kommentarsprache (Forts.)Hintergrund 118Regel 118
KommentarzeileHintergrund 118
KompilationseinheitHintergrund 134
KomplexitätFunktionsgruppe 156Hintergrund 150Klasse 155Kontrollstruktur 153Prozedur 154toter Code 157
KonstanteBeispiel 229, 243Hintergrund 226Namensgebung 99Regel 227Verwendung 241
KontextNamenskonvention 114
KontrollstrukturKettensatz 143Kommentar 123Komplexität 153
KonvertierungBeispiel 250Hintergrund 249Regel 249
KonvertierungsregelHintergrund 253Regel 253
KopfkommentareVerwendung 122
KundennamensraumBezeichner 104
Kurzform (Daten-Cluster)obsolet 372, 373
Kurzform (interne Tabelle)obsolet 366
Kurzform (Open SQL)obsolet 371
L
LaufzeitanalysePerformancetest 40
LaufzeitfehlerBeispiel 266Hintergrund 265, 321Regel 266, 321
LESchreibweise 139
LEAVEobsolet 360
LEAVE PROGRAMVerwendung 199
LEAVE TO LIST-PROCESSINGHintergrund 201
LEAVE TO TRANSACTIONProgrammausführung 54
LeerzeilenVerwendung 89
LENGTHSchreibweise 139
LIKEHintergrund 237Regel 237Verwendung 237
LIKE LINE OFRegel 237
LIKE-Bezugobsolet 356
ListeHintergrund 200, 209Regel 210Verwendung 202
LiteralHintergrund 240Regel 241
LiteraloperatorBeispiel 93Verwendung 92
LOADobsolet 358
LoaderVerwendung 220
LOAD-OF-PROGRAMHintergrund 314Verwendung 315
LOCALobsolet 363
LocaleTextumgebung 344
logische DatenbankProgrammattribut 58
1286.book Seite 398 Donnerstag, 30. April 2009 12:06 12
399
Index
logische Datenbank (Forts.)Regel 58Verwendung 59
lokale DeklarationAnordnung 131Beispiel 132, 133Gültigkeit 132Hintergrund 131Regel 131, 174Verwendung 173, 227
lokale KlasseDeklaration 129globale Klasse 173Namensgebung 113Verwendung 157, 206, 227, 310
lokaler BezeichnerNamensgebung 112
lokaler Datentypglobale Klasse 173
lokales InterfaceDeklaration 129globale Klasse 173Namensgebung 113
LokalisierungProduktstandard 37
LokatorVerwendung 327
LOOPKomplexität 153
LOOP (Dynpro)obsolet 369
LOOP ATHintergrund 293Regel 294
LOOP AT dbtabobsolet 373
LTSchreibweise 139
M
MAJOR-IDobsolet 372
MakroBeispiel 318Hintergrund 297, 316Regel 316Verwendung 317
MandantenbehandlungBeispiel 218, 219Hintergrund 217Regel 218
mathematische NotationHintergrund 255Verwendung 256
MAXIMUMobsolet 371
mehrsprachige EntwicklungRegel 62
MeldungCode Inspector 75erweiterte Programmprüfung 72
Memory InspectorSpeichertest 40Verwendung 328
MESSAGEHintergrund 197Verwendung 178
MethodeHintergrund 297Namensgebung 99Verwendung 309
MethodenaufrufBeispiel 145, 146Kurzform 145Langform 145Regel 145Schreibweise 145
MINIMUMobsolet 371
MINOR-IDobsolet 372
Mixed Case StyleBeispiel 84Verwendung 83
moderne SprachmittelBeispiel 66Hintergrund 64Verwendung 65
MODIFYBeispiel 295Regel 294
MODIFY dbtabobsolet 373
ModularisierungHintergrund 162Regel 162
1286.book Seite 399 Donnerstag, 30. April 2009 12:06 12
400
Index
MODULEHintergrund 314
Modul-PoolProgrammtyp 53Regel 55Trennung der Belange 26Verwendung 57
MOVEBeispiel 148Verwendung 147
MOVE PERCENTAGEobsolet 362
MULTIPLYVerwendung 147
MULTIPLY-CORRESPONDINGobsolet 364
N
NachrichtAusnahmetext 198Hintergrund 177, 197Regel 198Übersetzbarkeit 342Verwendung 178
NachrichtentextAusnahmetext 186
NachrichtentypHintergrund 197
NamensgebungAbkürzung 100Beispiel 107, 116Hintergrund 93, 96Namensraum 110Präfix 114Programmobjekt 108Regel 97Repository-Objekt 104Suffix 114Verschattung 111Ziffer 101
NamenskonventionHintergrund 94Repository-Objekt 105Überprüfung 375
NamensraumpräfixVerwendung 107
Native SQLHintergrund 216
Native SQL (Forts.)Verwendung 217
NEW-SECTIONobsolet 370
nmax (Eingebaute Funktion)Verwendung 154
nmin (Eingebaute Funktion)Verwendung 154
NODESHintergrund 239Schnittstellen-Arbeitsbereich 310Verwendung 240
NOTSchreibweise 139
NulldivisionBeispiel 263Hintergrund 262Regel 263
numerischer TextHintergrund 251
numerischer TypHintergrund 257Regel 258
O
OberflächentechnologieHintergrund 200Kapselung 204Regel 201
OberklasseHintergrund 170
ObjektRegel 166
ObjekterzeugungVerwendung 167
Objektheaderdynamisches Speicherobjekt 329
ObjektorientierungDesign 159, 166Verwendung 161
obsolete SprachmittelBeispiel 66Hintergrund 64, 353Verwendung 65
OCCURSobsolet 357
ON CHANGE OFobsolet 361
1286.book Seite 400 Donnerstag, 30. April 2009 12:06 12
401
Index
Online Text Repository � OTROO-Transaktion
Programmausführung 54Verwendung 56
OPEN DATASETRegel 348
Open SQLHintergrund 216Kettensatz 144Verwendung 216
operationale AnweisungKettensatz 142
OperatorenschreibweiseVerwendung 147
OriginalspracheHintergrund 62Regel 62
orthogonales KonzeptABAP Objects 45
OTRAusnahmetext 186
P
PACKobsolet 362
PACKAGE SECTIONRegel 161
PACKAGE SIZEVerwendung 327
PAI-ModulVerwendung 206
PaketHintergrund 104Namensgebung 98Namenskonvention 106
PaketkonzeptVerwendung 31, 106, 171, 215
PaketprüfungSyntaxprüfung 70
PaketschnittstelleNamensgebung 98
PARAMETERSHintergrund 200Verwendung 232
ParameterschnittstelleHintergrund 299
PBO-ModulVerwendung 206
PERFORMobsolet 359
PERFORM IN PROGRAMHintergrund 308
PERFORM ON COMMITVerwendung 47
PERFORM ON ROLLBACKVerwendung 47
PerformanceProduktstandard 38
PerformancetestCode Inspector 75
PERFORMINGobsolet 371
PersistenzHintergrund 214Regel 214Trennung der Belange 31
PolymorphieVerwendung 171
PrädikatSchreibweise 139
PräfixnamensraumBezeichner 104
Pragmaerweiterte Programmprüfung 72Syntaxprüfung 70Verwendung 72
Pretty PrinterBeispiel 85, 87Groß-/Kleinschreibung 83Hintergrund 88Regel 88Verwendung 89
PrimärschlüsselBeispiel 288Hintergrund 282
PRIVATE SECTIONglobale Klasse 173
ProduktstandardBeispiel 41Hintergrund 37Regel 39
Programmausführbares 26
ProgrammattributHintergrund 58Regel 58
1286.book Seite 401 Donnerstag, 30. April 2009 12:06 12
402
Index
ProgrammaufbauHintergrund 81
ProgrammgenerierungBeispiel 338Hintergrund 335Verwendung 337
ProgrammgruppeHintergrund 309
ProgrammierstilHintergrund 81
ProgrammobjektNamensgebung 108Namensregel 109
ProgrammtypHintergrund 53Regel 55
PROVIDEobsolet 368
Proxy ServiceTrennung der Belange 31
ProzedurHintergrund 297Komplexität 154Namensgebung 99Regel 298verlassen 312Verwendung 309
ProzeduraufrufHintergrund 308Programmausführung 54Regel 309
ProzedurvolumenBeispiel 155Hintergrund 154Regel 154
PseudokommentarBeispiel 77Code Inspector 75erweiterte Programmprüfung 72Verwendung 72, 76
PUBLIC SECTIONRegel 161
R
RahmenprogrammHintergrund 134Quelltextmodularisierung 135
RAISEVerwendung 180
RAISE EXCEPTIONVerwendung 181
RAISINGMESSAGE 197, 199
RANGESobsolet 358
READobsolet 367
READ DATASETSchreibweise 140
READ TABLEHintergrund 293Regel 294
READ TABLE dbtabobsolet 373
RechenausdruckSchreibweise 148
RechentypHintergrund 249
RedefinitionHintergrund 170Verwendung 167
REFERENCE INTOdynamischer Zugriff 332Verwendung 294
Referenzsemantikdynamischer Zugriff 332Verwendung 333
ReferenzübergabeBeispiel 269Hintergrund 268, 302Regel 268Verwendung 302
REFRESHobsolet 367
REFRESH FROM dbtabobsolet 373
REJECTVerwendung 313
remotefähiger Funktionsbaustein � RFMREPLACE
obsolet 365Schreibweise 140
REPLACE ... ALL OCCURENCESVerwendung 153
REPORT 26Beispiel 27
1286.book Seite 402 Donnerstag, 30. April 2009 12:06 12
403
Index
REPORT (Forts.)klassisch 28Trennung der Belange 31
Repository-ObjektNamensgebung 104Namenskonvention 105
RESUMABLEVerwendung 185
RESUMEVerwendung 180
RETURNBeispiel 313Hintergrund 312Regel 312
RETURNINGHintergrund 299Namenskonvention 109Verwendung 300
RFCVerwendung 47
RFMBeispiel 27Verwendung 56
ROLLBACK WORKVerwendung 199
RTTCVerwendung 336
RTTIVerwendung 336
RTTSVerwendung 336
RückgabewertHintergrund 299
Run Time Type Creation � RTTCRun Time Type Information � RTTIRun Time Type Services � RTTSRundungsfehler
Beispiel 262Hintergrund 261Regel 261
S
SAP GUIHintergrund 200
SAP List Viewer � ALVSAP-Namensraum
Bezeichner 104
SAP-PufferungHintergrund 219
SchachtelungstiefeBeispiel 154Hintergrund 153Regel 153
Schnittstellen-ArbeitsbereichBeispiel 311Verwendung 310
SchnittstellenparameterNamensgebung 98Namenskonvention 115
SchreibweiseBeispiel 140Regel 139
SCI � Code InspectorSEARCH
obsolet 365Sekundärschlüssel
Beispiel 288Regel 286Verwendung 286
SELECT (Dynpro)obsolet 368
SELECTION-SCREENHintergrund 200
SELECT-OPTIONSHintergrund 200Verwendung 232
SelektionsbildBeispiel 207Hintergrund 200Regel 205Verwendung 202
SelektionsbildereignisVerwendung 47, 206
Separation of Concerns � Trennung der Belange
serviceorientierte Architektur � SOASET EXTENDED CHECK OFF
Regel 73SET LOCALE
Beispiel 345Regel 344Textumgebung 344
SHARED BUFFERVerwendung 220
SHARED MEMORYHintergrund 219
1286.book Seite 403 Donnerstag, 30. April 2009 12:06 12
404
Index
SHARED MEMORY (Forts.)Regel 219Verwendung 220
Shared ObjectsBeispiel 221Hintergrund 219Verwendung 220
SharingDetails 302Hintergrund 243
SicherheitCode Inspector 75Produktstandard 38
SingletonBeispiel 168Hintergrund 166Verwendung 166
SLINerweiterte Programmprüfung 71
SOATrennung der Belange 26
SoC � Trennung der BelangeSORT
Verwendung 291SORTED BY
Hintergrund 291Regel 291Verwendung 291
sortierte TabelleHintergrund 282Tabellenart 283Verwendung 284
sortierter SchlüsselHintergrund 285Verwendung 287
SPLITVerwendung 347
SpracheTextumgebung 344
StandardkommentarVerwendung 89
StandardprüfvarianteCode Inspector 75
Standard-SelektionsbildVerwendung 207
StandardtabelleHintergrund 282Tabellenart 283Verwendung 284
START-OF-SELECTIONHintergrund 314Programmausführung 55Verwendung 47, 57, 315
StartwertBeispiel 246Hintergrund 245Regel 246
statische KlasseBeispiel 168Hintergrund 166Polymorphie 167Regel 166Verwendung 167
statische KomponenteHintergrund 166
statischer KonstruktorVerwendung 167
StatusmeldungVerwendung 198
STOPVerwendung 313
StreamingVerwendung 327
Stringdynamisches Datenobjekt 323dynamisches Speicherobjekt 325Hintergrund 243Regel 244Verwendung 324
Stringheaderdynamisches Speicherobjekt 329
StringliteralHintergrund 241
STRUCTURE-Typisierungobsolet 355, 357
strukturierte ProgrammierungHintergrund 162Verwendung 163
SUBMITProgrammausführung 54Verwendung 315
SUBMIT VIA JOBVerwendung 47
Subroutinen-PoolProgrammtyp 54Regel 55Verwendung 56
1286.book Seite 404 Donnerstag, 30. April 2009 12:06 12
405
Index
SUBTRACTVerwendung 147
SUBTRACT-CORRESPONDINGobsolet 364
SUMMARYobsolet 369
SUMMINGobsolet 371
SUPPLYobsolet 373
Surrogat-BereichHintergrund 347
syHintergrund 270
sy-indexVerwendung 274
sy-mandtVerwendung 218
SyntaxbereinigungABAP Objects 45
SyntaxfehlerHintergrund 68
SyntaxprüfungBeispiel 71Hintergrund 68Prüfschärfe 69Verwendung 69
SyntaxwarnungBeispiel 70Hintergrund 68Priorität 68Regel 69
SYSTHintergrund 270
System-CodepageTextumgebung 344
SystemfeldAktualparameter 276Auswertung 273Beispiel 271, 272, 274, 277, 278, 279,
281Benutzeroberfläche 278Hintergrund 270, 272Operandenposition 280Regel 270, 272, 273, 277, 278, 280Verwendung 271, 272, 273, 277, 279,
280Zugriff 270
SystemtextHintergrund 340
sy-subrcBeispiel 276Hintergrund 275Regel 275Verwendung 274, 275
sy-tabixVerwendung 274, 288
T
TabellenarbeitsbereichHintergrund 239Regel 239
TabellenartHintergrund 282Regel 284
Tabellenheaderdynamisches Speicherobjekt 329
TabellenindexHintergrund 282
Tabellenkörperdynamisches Speicherobjekt 325Hintergrund 296Regel 296Verwendung 296
TABLESHintergrund 239obsolet 354, 356Schnittstellen-Arbeitsbereich 310Verwendung 232, 240, 300
technisch-wissenschaftliche NotationHintergrund 255
TechnologiezugangABAP Objects 46
TeilfeldzugriffHintergrund 266Verwendung 347
TerminologieRegel 64
TextdateiBeispiel 349Regel 348
TextfeldBeispiel 244Verwendung 244
TextfeldliteralHintergrund 241
1286.book Seite 405 Donnerstag, 30. April 2009 12:06 12
406
Index
TextstringBeispiel 245Hintergrund 243Verwendung 244
TextsymbolVerwendung 341
TextumgebungHintergrund 344Regel 344
Top-IncludeBeispiel 232globaler Deklarationsteil 128
toter CodeHintergrund 157Komplexität 157Regel 157
TransaktionProgrammausführung 54
TRANSLATEobsolet 366
Transport OrganizerATC 79
Trennung der BelangeBeispiel 30Regel 26
TRYBeispiel 195Hintergrund 190
TYPEHintergrund 237Regel 237
Type-PoolProgrammtyp 54
TYPE-POOLSobsolet 355
TYPESHintergrund 226
TypgruppeBeispiel 229Hintergrund 226Programmtyp 54Regel 55Verwendung 57, 228
TypisierungHintergrund 305Regel 306
U
ÜbersetzbarkeitBeispiel 342, 343, 344Hintergrund 341Regel 341, 343
UI-ServiceTrennung der Belange 31
ungültiger WertBeispiel 252Hintergrund 250
Unicode-ProgrammBeispiel 61Hintergrund 58Verwendung 58, 354
Unicode-PrüfungBeispiel 60Programmattribut 58Regel 58Verwendung 58
UnterklasseHintergrund 170Verwendung 170
UnterprogrammHintergrund 297Regel 298Verwendung 47, 310
UnterstrichBeispiel 84
UnterstrukturBeispiel 234Hintergrund 233Regel 233
USINGHintergrund 299Verwendung 300
V
VALUEDATA 245
VariableHintergrund 230Namensgebung 98Regel 231
VerarbeitungsblockHintergrund 297
VerbuchungsfunktionsbausteinVerwendung 56
1286.book Seite 406 Donnerstag, 30. April 2009 12:06 12
407
Index
VererbungABAP Objects 45Hintergrund 170Regel 170Wiederverwendung 170
Verkettungsoperator &&Verwendung 92
vollständige TypisierungBeispiel 308Hintergrund 305
W
WahrheitswertBeispiel 248Hintergrund 247Regel 247
WarnungCode Inspector 75erweiterte Programmprüfung 72Verwendung 198
Web Dynpro ABAPBeispiel 203Hintergrund 201Verwendung 201, 213
WertebereichHintergrund 266
Wertesemantikdynamischer Zugriff 332Verwendung 333
WertübergabeBeispiel 270Hintergrund 302Verwendung 269, 302
WHILEKomplexität 153
WHILE VARYobsolet 362
WITH BYTE-ORDER MARKOPEN DATASET 348
WRITEHintergrund 201
WRITE TOobsolet 367Verwendung 262
Z
ZahlenangabeBeispiel 256, 257Hintergrund 255Regel 256
ZahlenliteralBeispiel 242Hintergrund 241Verwendung 241
ZeichenkettenausdruckSchreibweise 148
Zeichenketten-TemplateVerwendung 262, 341
ZeichenliteralHintergrund 241Übersetzbarkeit 340Verwendung 242, 341
ZeichensatzHintergrund 346Regel 346
ZeigerVerwendung 333
ZeilenbreiteBeispiel 92, 93Hintergrund 91Regel 91Verwendung 92
ZeilenendekommentarHintergrund 118Verwendung 124
ZeilentypHintergrund 282
ZeitfeldHintergrund 251
ZeitstempelVerwendung 252
ZusatzprogrammgruppeHintergrund 309
ZusicherungHintergrund 177
ZuweisungHintergrund 249Konvertierungsregel 253Regel 147Schreibweise 147verlustfrei 254
1286.book Seite 407 Donnerstag, 30. April 2009 12:06 12