Interne Tabelle

Re: Interne Tabelle

me 2

Re: Interne Tabelle

Und was das "ganz fauler Programmierer" angeht, so bin ich für alles, was Programmierern das Leben erleichtert, ohne den Code schlechter lesbar zu machen.

Sehe ich genauso. Kann aber auch eine Performancefalle sein und zwar dann, wenn der Resourcenverbrauch eines Befehls dem Entwickler nicht bewusst ist. Beispiele sind u.a. SORT, FIND, maskierte Vergleiche (CP), suchen mit Bezug auf Range-Tabellen. So ein SORT ist easy und lässt sich schnell schreiben; sogar in einem Loop - sicher ist sicher und manche Entwickler haben ein großes Sicherheitsbedürfnis.

In den allermeisten Fällen ist kürzerer Code auch besser lesbar.

Das sehe ich ganz anders bzw. es kommt darauf an, wie der Entwickler sein Coding strukturiert. Man kann mittlerweile ziemlich viel in einer Zeile ABAP-Coding unterbringen. Da sind mir ein paar mehr (kommentierte) Zeilen meistens lieber, weil man dann beser nachvollziehen kann, was da gemacht wird.

Deswegen rege ich mich auch darüber auf, dass Kopfzeilen deprecated sind. Ich finde Code, der mit Kopfzeilen arbeitet, wunderbar lesbar und verständlich. Arbeitet man mit separaten "Arbeitszeilen", dann wird der Code wesentlich länger und damit unübersichtlicher, ohne tatsächlich Mehrwert an Information zu bieten (z.B. LOOP AT mytable INTO ls_mytable statt einfach LOOP AT mytable).

Also ich finde nicht, dass es mit Workareas unleserlicher wird. Außerdem gibt es durchaus einen vernünftigen Grund Tabellenkörper und Kopfzeile zu trennen. Denn bei Tabellen mit Kopfzeilen hat der Name der Tabelle zwei Bedeutungen, nämlich Kopfzeile oder Tabellenkörper und es hängt vom Befehl ab, was genau angesprochen wird. Bei CLEAR, FREE wird die Kopfzeile angesprochen. Bei LOOP, REFRESH wird der Tabellenkörper angesprochen. Aber in ABAP wird es aus Gründen der Abwärtskompatibilität wohl für immer Tabellen mit Kopfzeilen geben.
Was mich ein bisschen stört, ist, dass bei Tabellen ohne Kopfzeile der Befehl CLEAR die gleiche Wirkung hat wie REFRESH. Man kann dann nicht gleich erkennen, ob es eine interne Tabelle ist.

Genauso bin ich auch ein Fan des CHECK-Befehls, der leider auch weitgehend deprecated ist, wenngleich die SAP ihn bislang meines Wissens noch nirgends verboten hat,

Check in LOOP wird wahrscheinlich nie "verboten" werden. Zu check in "Processing Blocks" stimme ich a-dead-trousers zu.

und ich mag auch die neuen Konstrukte NMIN( ) und LINES( ) sowie den gleichfalls relativ neuen &&-Operator (Das umständliche CONCATENATE war mir schon immer ein Dorn im Auge).

Ich finde die meisten neuen Funktionen und Expressions auch sehr gut. Insbesondere wenn man dabei die Deklaration von Hilfsvariablen sparen kann (siehe CONV). Doch CONCATENATE ist für mich auch OK; einfach deshalb, weil ich es mag, wenn der Name eines Befehls schon aussagt, was er tut.

Andererseits verstehe ich nicht, wie man sich über Sachen wie die Inline-Deklaration von Variablen freuen kann, denn die macht den Code wirklich schlechter verständlich, und viel gewinnen tut man damit ja auch nicht

Dem kann ich bezüglich Lesbarkeit durchaus zustimmen. Doch es kommt auch darauf an, wie man es einsetzt. Und es ist wahrscheinlich auch eine Frage der Gewöhnung. Ich bevorzuge die Datendeklaration am Anfang einer Verarbeitungseinheit. Doch ich muss zugeben, dass es auch manchmal sehr mühsam ist, wenn man erst mal durch mehrere Seiten Datendeklaration scrollen muss, bis man das Coding findet.

(da kann man sich auch die Gliederung mit TOP-Include sparen, wenn man die Hälfte der Variablen am Ende doch im Hauptcode per Inline-Deklaration definiert).

Unter dem Aspekt globale Datendeklaration so weit als möglich zu vermeiden, passt die Anmerkung glaube ich nicht ganz. Es sei denn du meinst mit Hauptcode Modules oder Report-Events. Das ist übrigens etwas, was mich schon lange stört; nämlich, dass Datendeklarationen in Modules und Report-Events immer global sind.

Auch LOOP in ein Feldsymbol mit nachfolgendem Tabellenändern ohne MODIFY mag zwar ein bisschen Performance bringen, macht den Code aber ganz sicher nicht verständlicher.

Das ist meiner Meinung nach eindeutig eine Frage der Gewöhnung. Und der Performancegewinn ist, gerade bei Änderungen von Tabellen mit vielen Einträgen und mit "breiten" Tabellenzeilen, durchaus beachtlich.
Was mich ganz allgemein bei Inline-Deklarationen ein wenig stört, ist dass man sie beim zweiten mal - sagen wir mal - nicht mehr verwenden kann. Gerade beim LOOP oder READ TABLE mit assigning field-symbol(<l_wa>). In einer Verarbeitungseinheit geht es beim ersten mal mit assigning field-symbol(<l_wa>), und beim zweiten mal darf man dann nur noch assigning <l_wa> schreiben. Wenn man dann einzelne Blöcke verschiebt, kommt es zu einem Syntaxfehler.

Re: Interne Tabelle

Kann aber auch eine Performancefalle sein und zwar dann, wenn der Resourcenverbrauch eines Befehls dem Entwickler nicht bewusst ist. Beispiele sind u.a. SORT, FIND, maskierte Vergleiche (CP), suchen mit Bezug auf Range-Tabellen. So ein SORT ist easy und lässt sich schnell schreiben; sogar in einem Loop - sicher ist sicher und manche Entwickler haben ein großes Sicherheitsbedürfnis.

Auf Performance-Auswirkungen nicht zu achten ist für mich eine Form von Dilettantismus. Gerade wenn es um Befehle wie SORT geht, bei dem jeder Programmierer aus seiner (wie auch immer gearteten) Grundausbildung wissen sollte, dass das ein Klassiker für Performancethemen ist.

Ich sehe auch in Codes, die nicht von mir stammen, niemals etwas anderes als STANDARD TABLEs. Dabei hat die SAP so schöne andere Tabellentypen eingeführt! Klar, wenn man ohne Not alles zum SORTED TABLE erklärt, handelt man sich auch wieder versteckte Performancefresser ein, zumal ich kürzlich einen Blog gelesen habe, laut dem selbst triviale Befehle, die die Sortierung eigentlich gar nicht betreffen, auf SORTED TABLEs weniger performant ausgeführt wurden (scheint mir eine Kernelschwäche zu sein). Viele behelfen sich mit SORT und suchen dann per BINARY SEARCH, was ich auch oft mache und was schon mal nicht schlecht ist.

Aber sobald man in einer internen Tabelle öfter etwas per größer/kleiner suchen muss, was ja mit READ TABLE leider nicht möglich ist, macht sich eine (durchdacht beschlüsselte) SORTED TABLE bezahlt, weil dabei der LOOP WHERE automatisch die Sortierung der Tabelle nutzt, um den Tabellenteil zu finden, der der größer/kleiner-Bedingung entspricht. Man kann halt bei LOOP kein BINARY SEARCH angeben, aber wenn die Tabelle SORTED ist und der Schlüssel zur WHERE-Bedingung passt, dann macht der LOOP-Befehl das von sich aus.

Die Vorteile von HASHED TABLEs sollten so offensichtlich sein, dass ich sie hier wohl nicht weiter erläutern muss. Dennoch habe ich überhaupt noch niemals in einem fremden Code einen HASHED TABLE gesehen.

Was maskierte Vergleiche angeht, so ist es eine Abwägung zwischen Performance und Übersichtlichkeit. Viele Unterroutinen und Befehle werden absehbar nur wenige Male im Programm durchlaufen, oft sogar nur einmal. Und da liest sich ein

IF 'irgendeines;dieser;Wörter;muss;passen' CS teststring.
...
ENDIF.

wesentlich besser als

CASE teststring.
WHEN 'irgendeines' OR 'dieser' OR 'Wörter' OR 'muss' OR 'passen'.
...
ENDCASE.

oder gar noch schlimmer die Variante, die man meistens in fremden Code sieht, wo die Wörter einzeln im IF-Befehl mit Vergleich auf Gleichheit aufgezählt werden.

Im übrigen ist die Performance meist von den Datenbankzugriffen dominiert. Wenn Du in meinen obigen Beispiel eine der unteren Syntaxen wählst, dann hast Du als Gewinn für die schlechtere Lesbarkeit von den 10%, die von der Laufzeit Deines Programms auf die ABAP-Performance entfallen, vielleicht nochmal 1% eingespart. Macht bezogen auf das Gesamtprogramm einen Performancegewinn von einem Promille.

Das sehe ich ganz anders bzw. es kommt darauf an, wie der Entwickler sein Coding strukturiert. Man kann mittlerweile ziemlich viel in einer Zeile ABAP-Coding unterbringen. Da sind mir ein paar mehr (kommentierte) Zeilen meistens lieber, weil man dann beser nachvollziehen kann, was da gemacht wird.

Das sind zwei verschiedene Paar Schuhe. Ich bin ein ganz großer Fan von Codekommentaren, und wenn alle so viel Kommentare in ihren Code schreiben würden wie ich, dann wäre die Welt ein besserer Ort.

Aber kürzerer Code ist meistens (nicht immer) auch besser lesbar. Vielleicht muss ich dabei aber eine Einschränkung machen, nämlich "außerhalb des OO-Kontextes". Dass man mit geschachtelten Methodenaufrufen unter Nutzung obskurer Variablenreferenzen die grässlichsten Dinge auf kleinstem Coderaum vollbringen kann, da gebe ich Dir vollkommen recht.

Außerdem gibt es durchaus einen vernünftigen Grund Tabellenkörper und Kopfzeile zu trennen. Denn bei Tabellen mit Kopfzeilen hat der Name der Tabelle zwei Bedeutungen, nämlich Kopfzeile oder Tabellenkörper und es hängt vom Befehl ab, was genau angesprochen wird.

Das stimmt, aber wenn man ein bisschen Übung hat, dann sieht man auf einen Blick, welche Bedeutung an einer bestimmten Stelle die richtige ist. Wenn ich mir überlege, was im OO-Kontext von Programmierern für abstraktes Denken gefordert wird, wenn mit irgendwelchen Variablen hantiert wird, die überhaupt keinen Namen mehr haben, sondern im luftleeren Raum hängen und nur über Referenzzeiger angesprochen werden können (wobei jene Referenzzeiger jederzeit woandershin umgebogen werden können und dann plötzlich für eine ganz andere Variable stehen), dann finde ich es relativ trivial, sich zu merken, dass diese drei Befehle sich auf die Kopfzeile und jene drei sich auf den Rumpf beziehen.

Ich finde es sowieso antiquiert, dass im ABAP so viel mit Zeigern gearbeitet wird. Zeiger auf Speicherbereiche kenne ich noch aus C64-Zeiten, und selbst da nur in Assembler, nicht im BASIC. Es ist doch eigentlich gerade eine wesentliche Errungenschaft moderner Programmiersprachen, von Speicherbereichen zu abstrahieren und den Programmierer damit nicht mehr zu behelligen. In meinen Augen stellen schon Feldsymble an dieser Stelle einen Rückschritt dar, der durch die ganzen Referenzvariablen, die im OO-Kontext ins Spiel gekommen sind, noch deutlich verschärft wird und wesentlich dazu beigetragen hat, dass fremde OO-Programme oft schwer bis unmöglich zu verstehen sind. Ich verstehe zwar durchaus die Gedankengänge bzw. Ziele, die zur Einführung dieser Elemente geführt haben, glaube jedoch, dass sich diese Ziele mit wesentlich weniger speicherreferenzbezogenen Mitteln hätten erreichen lassen und man die Programmiersprache hier unnötig mit Abstraktionen aufgeblasen hat.

Was mich ein bisschen stört, ist, dass bei Tabellen ohne Kopfzeile der Befehl CLEAR die gleiche Wirkung hat wie REFRESH. Man kann dann nicht gleich erkennen, ob es eine interne Tabelle ist.

Da bin ich auch nicht begeistert von, aber dahinter steht die Idee, den Befehl REFRESH zu deprecaten und komplett durch CLEAR zu ersetzen, ein Ziel, dass mit Blick auf die Abwärtskompatibilität halt nur zur Hälfte umgesetzt werden konnte. Aus meiner Sicht wäre in China kein OO-Sack umgefallen, wenn sie zum Löschen von internen Tabellen auch im OO-Kontext einfach REFRESH beibehalten hätten (was meines Wissens ja auch funktioniert).

Alternativ hätte man auch REFRESH abschaffen und fordern können, dass bei Tabellen mit Kopfzeile halt CLEAR tablename[] geschrieben wird. Hätte ich gut mit leben können, aber wäre halt zu altem Code nicht kompatibel gewesen (wobei die Syntax des REFRESH-Befehls so trivial ist, dass man das sogar im Rahmen des Releasewechsels vollautomatisiert in allen Codes auf dem System hätte austauschen können. Hat sich die SAP aber wohl nicht getraut und daher diese halbgare Lösung implementiert).

Check in LOOP wird wahrscheinlich nie "verboten" werden. Zu check in "Processing Blocks" stimme ich a-dead-trousers zu.

Ich schreibe oft Formroutinen, die irgendeinen Wert ermitteln sollen. Nehmen wir beispielsweise an, ich brauche zu der Personalnummer PERNR den Text des Personalbereichs und will eine Formroutine

PERFORM GET_PERBR_TEXT USING PERNR CHANGING PTEXT

die mir diesen beschafft.

Dann muss ich in der Formroutine mit der PERNR das Feld WERKS aus der PA0001 lesen und damit dann das Feld NAME1 aus der T500P. Wenn ich in der Formroutine aus irgendeinem Grund schon bei der Ermittlung von WERKS scheitere (etwa, weil es die übergebene Personalnummer gar nicht gibt), dann brauche ich mit der Textermittlung nicht weiterzumachen, sondern kann direkt rausspringen. Und da gibt es (abgesehen von einer Lösung mit JOIN, die ich hier mal außen vor lasse) in meinen Augen nichts Übersichtlicheres, als wenn ich das folgendermaßen code:
Da kann mir keiner erzählen, dass nicht mühelos erkennbar ist, was dieser CHECK da macht und dass ein IF-Block diese Formroutine leichter lesbar machen würde.

Doch CONCATENATE ist für mich auch OK; einfach deshalb, weil ich es mag, wenn der Name eines Befehls schon aussagt, was er tut.

Der Name des Befehls ist nett (auch wenn er recht lang ist), aber seine Nutzung - und Lesbarkeit - ist a pain in the ass, insbesondere wenn man viele Elemente aneinanderfügen möchte. Endgültig furchtbar wird CONCATENATE aber, wenn man zwischen manchen dieser Elemente ein Leerzeichen haben möchte und zwischen anderen nicht. Dann muss man womöglich sogar mehrere CONCATENATEs hintereinander schalten, die jeweils einen Teil des Ganzen zusammensetzen (mal mit, mal ohne den elendiglich langen Zusatz SEPARATED BY SPACE). Da finde ich den &&-Operator, kombiniert mit diesem neuen Hochkommatyp (` ` statt ' ') um Größenordnungen kürzer und besser lesbar.

(da kann man sich auch die Gliederung mit TOP-Include sparen, wenn man die Hälfte der Variablen am Ende doch im Hauptcode per Inline-Deklaration definiert).

Unter dem Aspekt globale Datendeklaration so weit als möglich zu vermeiden, passt die Anmerkung glaube ich nicht ganz.

Der Einwand ist berechtigt, aber bei einem Unterprogramm (egal ob Form oder Methode) sollte sich die Zahl benötigter lokaler Variablen ohnehin in Grenzen halten. Andernfalls ist das ein so großes Gebilde, dass möglicherweise sogar dafür ein eigenes Variablen-Include gerechtfertigt ist.

Aber selbst einen langen Deklarationsblock am Anfang, den man rasch überblättert und hinter dem dann der Code kommt, finde ich allemal angenehmer, als wenn der Code selbst von Variablendeklarationen durchsetzt ist, bei deren Inline-DATAs man erst man grübeln muss, welcher Datentyp denn da effektiv am Ende bei rauskommt.

Was mich ganz allgemein bei Inline-Deklarationen ein wenig stört, ist dass man sie beim zweiten mal - sagen wir mal - nicht mehr verwenden kann. Gerade beim LOOP oder READ TABLE mit assigning field-symbol(<l_wa>). In einer Verarbeitungseinheit geht es beim ersten mal mit assigning field-symbol(<l_wa>), und beim zweiten mal darf man dann nur noch assigning <l_wa> schreiben. Wenn man dann einzelne Blöcke verschiebt, kommt es zu einem Syntaxfehler.

Sowas ist doch ein Krampf! Und ganz ehrlich: den Vorteil sehe ich nicht. Dabei kann ich mich erinnern, wie in gewissen SAP-Foren gerade dieses Feature als große neue Errungenschaft gefeiert worden ist.