"Neue" Befehle im ABAP - wer verwendet diese

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

Zunächst zum CHECK:

Es gibt durchaus Monolithen, wo man dreimal überlegen muss "ist der IF von eben schon beendet?" oder "bin ich noch im DO oder bin ich da schon draußen?". Nicht umsonst wird unten im Editor angezeigt, wie "tief" ich im Coding bin. Zudem ist es nicht immer trivial, herauszufinden, wo denn der CHECK hinspringt, weil es keine schließende Anweisung gibt (ENDCHECK). Und sowas tritt sehr gern bei 3.000-Zeilen-Monolithen raus, die ich dann warten darf. Für mich selbst ist das ein geringes Problem, weil ich sehr stark modularisiere (Grundregel: Eine Methode, deren Code länger ist als eine Bildschirmseite, nochmal genau angucken, ob man die nicht aufteilen kann). In so kleinen Methoden verliert man den Überblick eher nicht, ich verliere den in Monolithen....

Das mit der Eindeutigkeit sehe ich nicht verletzt - ein CONTINUE setzt den LOOP mit dem nächsten Satz fort. Mir geht es darum, dass bei UNTERSCHIEDLICHEN Anweisungen der CHECK unterschiedlich reagiert. Man sollte Fehlerquellen minimieren - ausschließen kann man sie nicht.

Daniel hat geschrieben:DOCH! Eine Programmiersprache muss aus sich heraus verständlich sein.
Der AKÜFI führt auf Dauer zwangsläufig zu Fehlinterpretationen.

Ich kann das immer noch nicht sehen. Die Anweisung ist ein READ, der zwangsläufig nur einen Satz trifft. Genauso wie ich beim READ wissen muss, dass er nur einen Satz trifft, muss ich das bei der neuen Anweisung auch. Das merkt man schon daran, dass der Rückgabewert des Ausdrucks ein Zeilentyp ist und nicht eine Mehrzahl von Zeilentypen.


Ralf

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

Dass es bei READ nur um eine Zeile geht, weißt du auch nur, weil du es mal gelernt hast....

Zur Modulsrisierung: Wiederverwendung ist nur ein Argument (INCLUDES z. B. *soll* man gar nicht mehrfach verwenden), Übersicht ist eine andere. Wie beim Aktenschrank: Da packe ich auch nicht alles einfach rein, sondern sortiere es in Heftern, die in Aktenordner geheftet werden, die in Schubladen hängen, die in Aktenschränken sind.

Sowas finde *ich* deutlich übersichtlicher, wenn ich in sich abgeschlossene Einheiten in eine Methode packe, die ich dann auch einzeln testen kann (ich weiß, du schreibst keine Modultests, aber sowas hilft bei der Wartung enorm), dann sehe ich auch sofort, wo diese "Operation" anfängt und endet.


Ralf

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

ralf.wenzel hat geschrieben:Es gibt durchaus Monolithen, wo man dreimal überlegen muss "ist der IF von eben schon beendet?" oder "bin ich noch im DO oder bin ich da schon draußen?". Nicht umsonst wird unten im Editor angezeigt, wie "tief" ich im Coding bin. Zudem ist es nicht immer trivial, herauszufinden, wo denn der CHECK hinspringt, weil es keine schließende Anweisung gibt (ENDCHECK). Und sowas tritt sehr gern bei 3.000-Zeilen-Monolithen raus, die ich dann warten darf.

Dann ist Dein Problem aber nicht der CHECK, sondern der Monolith. Wer einen LOOP über 3000 Zeilen programmiert, ohne Blöcke innerhalb des LOOPs in Subroutinen zu gliedern, der kann nicht programmieren. Sowas ist selbst bei ältestem prozeduralen Programmierstil eine Katastrophe. Den CHECK zu vermeiden wird das auch nicht wieder rausreißen.

Ist der Code jedoch vernünftig gegliedert (und einen 3000-Zeilen-LOOP habe ich persönlich zum Glück noch nicht zu sehen bekommen), dann reicht es aus, die aktuelle Subroutine zu überblicken um zu wissen, was ein CHECK bewirken kann. Die optischen Hilfsmittel von Eclipse und SE38 nutze ich dafür gar nicht. Wem sie gefallen, gerne, aber ich weiß auch so immer, wo ich schleifenmäßig stehe.

Komplexe IF-Blöcke zu überblicken finde ich da schon bedeutend schwieriger. Aber die handelt man sich leichter ein, wenn man ohne Not auf den CHECK verzichtet, und IF-Blöcke haben ja auch keine Auswirkungen auf das Verhalten des CHECK-Befehls, so dass dort eine Übersicht nicht ganz so wichtig ist.

Aber ob man sich in einer Schleife befindet oder nicht, ist doch ganz essenziell für das Verständnis, was da gerade im Code passiert. Wenn man das nicht weiß, dann versteht man den Code so oder so nicht.
Und ich halte unübersichtliche oder unnötige IF-Blöcke für eine mindestens ebenso große Fehlerquelle.

Vielleicht können wir uns aber auch auf das Prinzip GMV (Gesunder Menschenverstand) einigen, das Du im Bereich der Inline-Deklarationen selber (bzw. im Namen der SAP) postuliert hast. Genau wie man eine inline in einer Schleife deklarierte Variable im weiteren Verlauf beliebig weiternutzen kann, dies jedoch aus Gründen der Lesbarkeit nicht tun sollte, muss man den CHECK-Befehl ja nicht unbedingt im tiefsten Codegestrüpp einsetzen. Aber gerade bei kurzen Schleifen, bei denen man LOOP und ENDLOOP gleichzeitig im Blick hat, oder bei kürzeren Subroutinen (egal ob FORM oder Methode) ist gegen CHECK absolut nichts einzuwenden.

Das oben genannte Beispiel des LOOP AT SCREEN ist doch ein exzellentes Beispiel dafür. Wenn gleich nach dem LOOP-Befehl in der nächsten Zeile der CHECK kommt, der alle nicht interessierenden Dynprofelder verwirft, dann ist das doch wunderbar übersichtlich, und da fragt auch keiner, der ABAP kann, was der CHECK da genau macht. Das mit IF und ENDIF auf drei Zeilen aufzupumpen, schadet der Lesbarkeit, anstatt sie zu verbessern.

Daniel hat geschrieben:Nein, dafür verliert man den Überblich über die Methoden.
Für eine neue Modularisierungseinheit muss es schon einen
vernünftigen Grund geben - sonst ist das Quatsch.
Ich sehe da in erster Linie die mehrfache Verwendung.

Bei zu starker Fragmentierung würde ich da mitgehen, ansonsten finde ich eine Gliederung in Subroutinen (als Oberbegriff für Forms und Methoden) aber durchaus gut. Ich bemühe mich immer, mein Hauptprogramm so zu schreiben, dass es nur 10 Zeilen oder so lang ist, und die bestehen dann aus Subroutinen, die die wesentlichen Programmschritte ausführen (und je nach Größe selbst wieder modularisiert sind). Dann brauche ich mich z.B. nicht durch die ganze Datenbeschaffung zu kämpfen, wenn ich einen Bug im Bereich der Ausgabe ins ALV suche.

Wovor ich aber einen Horror habe, und das ist leider bei OO der große Hype, ist die tiefe Schachtelung funktionaler Methoden. Das finde ich ganz miserabel lesbar, obwohl - um nicht zu sagen weil - man damit ganz viel Funktionalität in eine einzige Programmzeile bekommt. Leider habe ich das Gefühl, dass die neuen Befehle SWITCH und COND den Zweck verfolgen, dieses Problem noch zu verschärfen. Dabei mag ich sie eigentlich und habe gerade erst SWITCH in ein produktives Programm von mir eingebaut. Aber bislang würde ich sagen, das ist eine Spielerei, die, wenn man sich dran gewöhnt hat, von der Lesbarkeit her in etwa auf einer Ebene mit einem herkömmlichen CASE oder IF rangiert. Kombiniert man diese Befehle allerdings mit funktionalen Methoden, dann kann man die übelsten Zuweisungsmonster bauen. Das ist für mich Modularisierung am falschen Ende. Dann lieber ein ehrlicher, umfassend ausgeschriebener CALL METHOD mit Parameterliste, der dann als optisch separater Verarbeitungsblock sein Werk tut und sich dabei weiterer Methoden bedient. Nichts gegen funktionale Methoden, die können sehr hübsch sein, aber mit der Schachtelung sollte man vorsichtig umgehen.

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

Ralf hat geschrieben:INCLUDES z. B. *soll* man gar nicht mehrfach verwenden

Das hängt vom INCLUDE ab. Den BDCRECX1 nicht wiederverwenden zu wollen wäre ziemlich unsinnig.

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

Kein vernünftiger Mensch schachtelt um des Schachtelns wegen, ich z. B. schachtele dann, wenn ich es für sinnvoll halte. Aus Gründen der Testbarkeit oder den anderen, die ich schon erwähnt habe.

Ralf

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

Sehe ich genauso. Dann werden die Daten noch durch mindestens 25 verschiedene
Tabellen geschaukelt und am Ende weis niemand mehr genau wo gerade welcher
Wert aktuell ist.

Ich bin ja schon glücklich, wenn es nur Tabellen sind. Der Horror sind tief strukturierte Container (selbstredend undokumentiert, oder die Doku liegt in einer Schublade bei der SAP oder auf der anderen Seite des Erdballs), in denen sich dann Referenzen auf unbenamt im Speicher liegende Datenobjekte (REF TO DATA) befinden, welche wieder auf andere Container verweisen usw. Am Ende tauchen die eigentlich gewünschten Daten dann aus den Tiefen des Nirwana auf, und man blickt gar nicht mehr durch, wo sie eigentlich herkommen - oder im Fehlerfall warum sie nicht gefunden werden und wo und wie sie zu erreichen sind. Vielleicht liegen sie ja auch nur versteckt in einem privaten Attribut ganz am Ende der Schachtelungskette. Tja, hätte man gewusst, dass es dafür eine GET-Methode gibt und in welcher Klasse sie sich befindet...

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

Das hat mich schon vor etlichen Jahren geärgert ("rufe einen Funktionsbaustein, dessen Namen in einer Variable steht" - und der irgendwo im Customizing gepflegt ist, und man darf sich dann auf die Suche begeben).

Gebe ich Dir recht, aber das kriegt man in aller Regel noch raus. Notfalls setzt man sich da einen Breakpoint hin, dann hat man den FB-Namen, oder man verfolgt zurück, wo der Variablenname herkommt. Das ist mit Debuggermitteln in aller Regel noch beherrschbar (jedenfalls wenn der Name nicht per IMPORT FROM MEMORY vom Himmel fällt, weil man nicht weiß, wann und von wem er ins Memory geschoben worden ist).

Funktionsbausteine mag ich sehr gerne, weil sie technisch gut implementiert sind. Übersichtliche Schnittstelle, die bei Pflege direkt einen exzellent lesbaren Kommentar am Anfang des Codes triggert (wodurch sie auch in Eclipse gut lesbar zur Verfügung steht), gute Dokumentationsmöglichkeiten für den Baustein und sogar für jeden einzelnen Parameter. Finde ich angenehmer zu handhaben als globale Klassen. Die haben ihre Berechtigung, sobald es komplexer wird, aber in vielen Fällen ist ein FB ausreichend und von der Handhabung besser verständlich.

Was mich an FBs etwas stört, ist die Einbettung in Funktionsgruppen. Funktionsgruppen sollte es IMHO gar nicht geben. Die nehme ich als Versuch wahr, Funktionsbausteine zu einer Art statischer Pseudoklassen zusammenzufassen, wobei die globalen Variablen der Funktionsgruppe die privaten Attribute sind. Dadurch kann man einen Baustein aufrufen, und dessen Verhalten hängt eben nicht nur von seiner wohldefinierten Schnittstelle ab, sondern auch davon, was ein anderer Baustein derselben Funktionsgruppe vorher gemacht hat. Das verletzt für mich die Idee der strikten Kapselung, die Funktionsbausteine eigentlich so klar und schön macht. Gerade auch der Begriff "Funktionsbaustein" suggeriert für mich, dass ich was reinschiebe und basierend darauf was rausbekomme, ohne dass das Ergebnis auch noch davon abhängt, was der Hund des Nachbarn gestern zu Mittag gegessen hat.

Ich weiß, mit den funktionsgruppenglobalen Variablen, die die Bausteingruppe zu einer Art Eininstanzklasse mit Bausteinen als Methoden machen, kann man eine Menge netter Sachen machen. Ich nutze das gelegentlich auch, dokumentiere dann aber auch penibel (solange es nicht nur um Trivialitäten geht wie das Puffern eines Ergebniswerts, damit ich den im Falle eines zweiten Aufrufs mit derselben Anfrage sofort nochmals zurückliefern kann). Trotzdem wäre es mir lieber, wenn es Funktionsgruppen nicht gäbe und man sich dafür darauf verlassen könnte, dass ein FB für sein Ergebnis nur die Informationen nutzt, die man ihm als Parameter übergibt.

Mal eine ganz andere Frage: Zu Release 7.52 soll es wieder interessante Neuerungen geben. Unter anderem soll es endlich möglich sein, auf Dynproebene zu debuggen (wo einem bisher der Debugger ja schon seit Menschengedenken erzählt, dass ein Debugging im Dynprostack "noch" nicht möglich sei). Aber auch im ABAP selber gibt es Neues. Leider lässt die entsprechende Infoseite der SAP aber sehr zu wünschen übrig: Klickt mal auf den Link "Änderungen in Release 7.52":

https://help.sap.com/viewer/825e9222e7a ... d62b4.html

Weiß jemand mehr? Oder könntest Du, Ralf, Horst Keller mal darauf hinweisen?