"Neue" Befehle im ABAP - wer verwendet diese

Re: "Neue" Befehle im ABAP - wer verwendet diese

ralf.wenzel hat geschrieben:Können wir jetzt wieder über das Thema diskutieren?

Leider nein, denn:

zzcpak hat geschrieben:Thread versaut

Ich finde die neuen Befehle allesamt gleichermaßen interessant wie schwierig.
Insgesamt finde ich gut, dass es sie gibt.

Wo sie "nicht groß auffallen" verwende ich sie. Persönlich finde ich es einigermaßen unschön, wenn man normale Anweisungen mit impliziten Deklarationen mischt. Das sieht einfach "doof" aus.
Viele Befehle werden durch die kürzere Schreibweise in der Zeile länger und dadurch schlechter lesbar. Nicht umsonst ist in Zeitungen der Text in Spalten aufgeteilt. vs. Vielleicht gibt sich das auch mit der Zeit, je öfters ich die neuen Sprachkonstrukte verwende und sehe, aber bisher ist es für mich schwerer zu erkennen, was die neuen Konstrukte machen.

Des Weiteren ist es schön, wenn man implizite Befehle nutzen kann, wie zum Beispiel CONV, um eine implizite Umwandlung zur Parameterübergabe zu machen, es kann Code aber auch wieder unnötig schwer lesbar machen.

Re: "Neue" Befehle im ABAP - wer verwendet diese

Bis auf die erste Antwort in diesem Thread von lausek hört es sich so an, als ob die Meisten, die die neuen Möglichkeiten verwenden, sich auf die einfacheren/kürzeren Neuerungen beschränken. Aber wie sieht das denn mit den etwas komplexeren Neuerungen aus wie z.B. FOR, REDUCE, FILTER, MESH?

Re: "Neue" Befehle im ABAP - wer verwendet diese

Du hast recht, dass implizite Deklarationen zunächst ungewohnt sind. Ich beobachte aber gerade bei umfangreichen User-Exits, dass Entwickler die Variablen blockweise dort deklarieren, wo man sie braucht. So wird ein User-Exit dann in Codingblöcke unterteilt (quasi wie eine Sammlung von Includes in einem Strang), weil sie das übersichtlicher finden.

Ich zum Beispiel verstehe eines nicht: Warum muss ich eine Variable, die ich nur sehr begrenzt verwende, oben im Coding deklarieren? Nehmen wir einen LOOP AT mara ASSIGNING <mara>. Dann muss ich <mara> oben deklarieren und wenn ich den LOOP nicht in eine eigene Methode schreibe, ist gar nicht klar, dass das nur sehr begrenzt verwendet wird. Ein LOOP AT mara ASSIGNING FIELD-SYMBOL(<mara>) zeigt mir: Ah, <mara> wird nur in diesem LOOP verwendet. Und wenn man sich die Hinweise zum Befehl ansieht, sieht man, dass Horst sehr deutlich schreibt, dass die impliziten Deklarationen genau dafür gedacht sind und nicht inflationär verwendet werden sollen.

Außerdem erspart man sich die Typisiererei, <mara> ist immer automatisch vom Zeilentyp von mara.

Sobald ich eine Variable mehrfach verwende, deklariere ich sie nicht implizit (das zeigt dem Leser dann auch gleich: Mehrfach verwendet, keine Einmalvariable). Aber Methoden sind bei mir meistens sehr kurz (das sollen sie ja auch sein), so dass es zumeist gar nicht dazu kommt.

Man muss halt wissen, was man tut. Es erspart große Deklarationsblöcke, die MICH erstmal abschrecken, wenn ich ein Coding lese. Die Umgewöhnung ist natürlich da, war sie auch bei mir. Aber ich halte das nicht für dumm, Einmalvariablen als solche zu kennzeichnen.


Ralf

Re: "Neue" Befehle im ABAP - wer verwendet diese

Also, zunächst einmal gehört komplexes Coding grundsätzlich per Kommentar erklärt. Damit man es versteht, ohne dass es einem wer erklären muss (weil das oft gar nicht geht).

Auf der anderen Seite können gerade REGEX sehr komplexe Dinge in einem einfachen Ausdruck machen (der oft nicht schwerer zu verstehen ist als ein langes Coding, das im Grunde genommen dasselbe macht, aber auch nicht kommentiert ist ).

Ich sage immer wieder Neu-Entwicklern: "Kommentieren, kommentieren, kommentieren. Und wenn du in einem Fremdprogramm etwas findest, was du nicht verstehst und du hast das irgendwann rausgefunden: KOMMENTAR REIN! - sonst stehst du in sechs Wochen wieder davor und suchst nach demselben Kram". Weil man sich das eben nicht merkt, was man vor 6 Wochen mal rausgefunden hat.


Ralf

Re: "Neue" Befehle im ABAP - wer verwendet diese

gut, meine Programme sind meist nicht so furchtbar komplex.

Ich versuche allerdings immer, mit möglichst wenig Kommentaren auszukommen. Vielmehr soll das Coding so strukturiert sein, dass sich schon aus den Methodennamen (auch Namen für Parameter, Variablen) der Sinn erschließt. Also kleine Klassen mit genau umrissenem Aufgabengebiet, kleine Methoden mit einer genauen Aufgabe. Führt auch schon mal dazu, dass meine Methodennamen zu lang werden

Sehe ich mich genötigt, eine Coding-Passage zu kommentieren, versuche ich daher zunächst, diese einfacher zu gestalten, um Kommentare zu vermeiden.

Das Leidige an Kommentaren ist, dass deren Qualität häufig mit der Qualität des Codings Hand in Hand geht. Mieses Coding wird dann oft von ebensolchen Kommentaren begleitet, die mich auch nicht weiter erhellen. Umgekehrt stören Kommentare in gut strukturiertem Coding imho wiederum den Lesefluss.

Re: "Neue" Befehle im ABAP - wer verwendet diese

zzcpak hat geschrieben:Was gewinnt man dadurch?

Enno mag keine Inline-Deklarationen und langen Zeilen und DeathAndPain mag Deklarationen am Anfang.

Re: "Neue" Befehle im ABAP - wer verwendet diese

ralf hat geschrieben:Ich zum Beispiel verstehe eines nicht: Warum muss ich eine Variable, die ich nur sehr begrenzt verwende, oben im Coding deklarieren? Nehmen wir einen LOOP AT mara ASSIGNING <mara>. Dann muss ich <mara> oben deklarieren und wenn ich den LOOP nicht in eine eigene Methode schreibe, ist gar nicht klar, dass das nur sehr begrenzt verwendet wird. Ein LOOP AT mara ASSIGNING FIELD-SYMBOL(<mara>) zeigt mir: Ah, <mara> wird nur in diesem LOOP verwendet. Und wenn man sich die Hinweise zum Befehl ansieht, sieht man, dass Horst sehr deutlich schreibt, dass die impliziten Deklarationen genau dafür gedacht sind und nicht inflationär verwendet werden sollen.

Kann ich nachvollziehen, doch die programmiersprachenseitige Umsetzung gefällt mir trotzdem nicht. Da, wo ich Inline-Deklarationen bisher angewandt gesehen habe, war es einfach dort, wo die Variable zum ersten Mal verwendet wurde. Die Beschränkung auf den Codeblock wird technisch nicht durchgesetzt, wie das etwa bei lokalen Variablen in FORMs und Methoden der Fall ist, und was passiert, wenn man hofft, dass Programmierer von sich aus ordentlich arbeiten, wissen wir alle.

Um bei Deinem Beispiel zu bleiben, müsste ABAP sich dann so verhalten, dass das Feldsymbol <mara> nur innerhalb des LOOPs gültig ist und eine Verwendung außerhalb des LOOPs statisch zu einem Syntax Error führt. Dann würde ich sagen, so macht das Sinn und ist in der Tat eine Hilfe im Sinne Deiner Argumentation.

Wobei ich das ASSIGNING mit dem LOOP sogar noch optisch ansprechend finde (wenngleich ich trotz der Performancevorteile kein Freund davon bin, interne Tabellen implizit ohne MODIFY zu ändern und grundsätzlich den Standpunkt vertrete, dass Zeiger auf Speicherbereiche aus C64-Maschinensprache-Zeiten stammen und in modernen, abstrahierenden Hochsprachen nichts verloren haben, weswegen ich Konstrukte wie TYPE REF TO DATA als Rückschritt empfinde. Aber das ist ein anderes Thema).

Aber spätestens beim inline verwendeten DATA-Befehl ist Deine Argumentation nicht zu halten. Mit dem macht Horst Keller sich IMHO unglaubwürdig, wenn er ernsthaft den von Dir geschilderten Standpunkt vertritt. Wenn man Sachen wie: verwendet, dann gibt es keinen lokalen Befehlsblock, auf den sich das beziehen könnte. Das ist einfach nur Faulheit, um die Variable nicht ordentlich im Top Include (bzw. am Anfang der Form/Methode) definieren zu müssen. Hier wird ja sogar eine ganze interne Tabelle so definiert. Und das finde ich auch absolut schlecht lesbar. Und obiges Beispiel stammt aus der F1-Online-Hilfe zur Inline-Deklaration mit DATA!

zzcpak hat geschrieben:Das ist ähnlich wie bei REGEX. Ein mächtiges Werkzeug, dass ich hie und da für einfache Fälle auch schon mal angewendet habe, um z.B. bestimmte Sachen aus Log-Dateien rauszufiltern. Allerdings sind diese Sachen alles andere als selbsterklärend.

Tatsächlich habe ich bis heute keine vernünftige Doku dazu gefunden, wie man REGEX für den Hausgebrauch und insbesondere in ABAP anwendet. Anscheinend gibt es ja unterschiedliche Umfänge, in denen reguläre Ausdrücke je nach Programmiersprache unterstützt sein können. Die Doku, was in ABAP geht, finde ich aber mehr als dürftig. Mir fehlt auch eine Beschreibung, die mit aussagekräftigen, nicht zu komplexen Beispielen hinterlegt wäre, sowie ein Kompendium, was alles möglich ist (ich denke da an etwas im Stil von SelfHTML). Im Prinzip sagt ABAP nur, ja, reguläre Ausdrücke unterstützen wir in Grenzen auch, und zwar dort und dort, und wie man das dann macht, soll man bei Wikipedia oder in irgendwelchen dicken Büchern nachlesen, die bei der Wissenschaft regulärer Ausdrücke aus dem Vollen schöpfen. IMHO nicht praktikabel. So dringend habe ich reguläre Ausdrücke in meiner ganzen Karriere noch nie gebraucht, dass solch Einarbeitungsaufwand auf der Basis mieser oder viel zu umfangreicher Dokumentation gerechtfertigt gewesen wäre.

zzcpak hat geschrieben:Mag sein, dass es einfacher wird, wenn man komplexere Befehle häufig anwendet. Aber trotzdem müsste man bei jeder Betrachtung solch eines Codings wohl erst mal intensiv nachdenken oder nachlesen, was dort eigentlich passiert. Das halte ich nicht für zielführend.

Genau so sehe ich das auch. In Gedanken ist man bei dem, was man machen möchte (bzw. versucht bei fremdem Code nachzuvollziehen, was dessen Autor da tun möchte). Wenn man dann verwirrende Syntaxen nachvollziehen muss - auch wenn man das kann - dann ist das wie ein 3D-Film, bei dem mit 3D-Effekten herumgespielt wird und der Zuschauer dadurch aus dem Geschehen gerissen wird, statt sie unauffällig und stimmig einzubetten. Das war ja ein verbreiteter Fehler in der Frühphase des 3D-Kinos.

ralf.wenzel hat geschrieben:Ich sage immer wieder Neu-Entwicklern: "Kommentieren, kommentieren, kommentieren. Und wenn du in einem Fremdprogramm etwas findest, was du nicht verstehst und du hast das irgendwann rausgefunden: KOMMENTAR REIN! - sonst stehst du in sechs Wochen wieder davor und suchst nach demselben Kram". Weil man sich das eben nicht merkt, was man vor 6 Wochen mal rausgefunden hat.

Auch hier bin ich komplett Deiner Meinung. Tatsächlich machen es aber die wenigsten. Ich glaube, das liegt nicht nur an Faulheit, sondern auch daran, dass viele nicht in der Lage sind, ihre Gedanken schlüssig in Worte zu fassen und damit dann auch noch vollständige, korrekte deutsche Sätze zu bilden. Ich kenne Programmierer, die echt pfiffig und definitiv nicht faul sind, aber die - durchaus vorhandenen - Kommentare in ihrem Code lesen sich zum Teil echt legasthenisch. Gut Text schreiben ist eine Fähigkeit für sich, die man hat oder auch nicht (obwohl man sie in gewissem Rahmen sicherlich auch trainieren kann). Und da darf unsereins halt nicht arrogant sein und ein textuelles Niveau fordern, zum dem nicht jeder in der Lage ist.

Dennoch sollte jeder in der Lage sein, seine Intentionen zumindest so weit zu formulieren, dass man eine Vorstellung hat, was er da tut.

zzcpak hat geschrieben:Ich versuche allerdings immer, mit möglichst wenig Kommentaren auszukommen. Vielmehr soll das Coding so strukturiert sein, dass sich schon aus den Methodennamen (auch Namen für Parameter, Variablen) der Sinn erschließt. Also kleine Klassen mit genau umrissenem Aufgabengebiet, kleine Methoden mit einer genauen Aufgabe. Führt auch schon mal dazu, dass meine Methodennamen zu lang werden

Sehe ich mich genötigt, eine Coding-Passage zu kommentieren, versuche ich daher zunächst, diese einfacher zu gestalten, um Kommentare zu vermeiden.

Ich halte diesen Ansatz für einen Denkfehler. Klar sollte man nach Möglichkeit nachvollziehbar coden und dafür auch gut modularisieren (egal ob mit oder ohne OO). Aber ich halte es für sehr günstig, wenn schon am Anfang einer Modularisierungseinheit (egal ob FORM, Methode oder einer Schleife) in klaren Worten steht, wozu das folgende Konstrukt da ist. Zum einen kann man daraus schnell das Sollverhalten des Programms erkennen, ohne den Codeblock erst lesen und sich die dahinterstehende Absicht gewissermaßen reverse engineeren zu müssen (auch wenn das bei gutem Code nicht allzu schwer möglich sein mag). Zum anderen sieht man auch sofort, ob das überhaupt der Block ist, den man im Rahmen seiner aktuellen Fragestellung (etwa auf der Suche nach einem Bug) überhaupt sucht oder ob es in dem Block um etwas geht, was für das, was man gerade machen möchte, irrelevant ist.

Erschwerend kommt hinzu, dass Code Fehler enthalten kann. Ist der Fehler nicht allzu offensichtlich, dann ist es gerade bei fremdem Code nicht leicht zu beurteilen, ob man einen Bug gefunden hat oder ob der Urheber des Codes sich etwas dabei gedacht hat und man möglicherweise ein Detail der Sollfunktionalität übersieht. Wenn aber klar oben drüber steht: "Diese Methode soll zu der übergebenen Materialnummer die Lagerbestände in allen VKORGs einlesen und in der Tabelle LAGERBESTAENDE zurückliefern.", dann weiß man ganz klar, was da passieren soll und kann mit bedeutend sichererer Hand auf den Code zeigen und sagen: "Diese Stelle ist so nicht richtig!"

Ich stelle auch fest, dass ich von meinen eigenen Kommentaren sehr profitiere. Wenn ich mal ein halbes Jahr oder gar noch länger an einem Code nicht mehr dran war, dann bin ich mir selber häufig unendlich dankbar, dass ich mit einem Blick nachlesen kann, welche Gedankengänge zu einem Code geführt haben und worauf in dem Zusammenhang möglicherweise noch zu achten ist.