"Neue" Befehle im ABAP - wer verwendet diese
Leider ein wirklich auch in meinen Augen ein Problem bei vielen.DeathAndPain hat geschrieben: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.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.
Der Klassiker:
Code: Alles auswählen.
IF sy-subrc <> 0. "Fehlerhandling
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Prinzipiell ja. In der Praxis ist die Definition, was rein kommen darf und was raus gehen muss nicht einfach!DeathAndPain hat geschrieben: 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!"
Paul Hardy spricht in seinem ziemlich genialen Buch ABAP To The Future von "Preconditions" und "Postconditions", die er auf Seite 277 wie folgt programmiert:
Code: Alles auswählen.
zcl_dbc=>require( that = 'The Monster has at least one eye'
which_is_true_if = boolc(
co_monster->md_no_of_eyes GE 1 ) ).Die Idee finde ich super, die Umsetzung ist extrem aufwändig sobald man mehrere Parameter und Parameterkombinationen hat. Auch die Definition, was wirklich zulässig ist bzw. erwartet wird, kann ziemlich kompliziert sein.
Nichts desto Trotz: Eine kurze Beschreibung, was die Methode macht und in welchem Kontext sie verwendet wird, ist sinnvoll. GET_SPECIAL_DATA oder CHECK_STATUS ist doch ziemlich nichtssagend...
Beitrag
von ralf.wenzel (Top Expert / 3955 / 202 /
281
)
»
Irgendwo in seinem Blog, das finde ich jetzt nicht mehr wirklich wieder - aber hieraus kann man das ableiten.black_adept hat geschrieben:Ich dachte immer das sei nur deine eigene Methodik, wann/wie du Inline-Deklarationen verwendest. Aber wenn das offiziell ist, magst du mal einen Link posten, wo H. Keller das genau schreibt? Denn ich habe das so nicht in der Doku gefunden.ralf.wenzel 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.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Neuer Artikel über BRF+ in der neuen iX 05/25!
Beitrag
von ralf.wenzel (Top Expert / 3955 / 202 /
281
)
»
Bei sowas hilft nur eins: Pranger aus dem Keller holen, Entwickler darin befestigen, fertig. Da hilft es, wenn man das passende "Hobby" zum Beruf hat.ewx hat geschrieben:Der Klassiker:Kein "Warum?", kein "Was habe ich erwartet?", keine Info, in welchen Fällen der Fehler durchaus vorkommen kann.Code: Alles auswählen.
IF sy-subrc <> 0. "Fehlerhandling
Und wenn er dann sagt "Ich hatte keine Zeit für den Kommentar", darf er noch ne Stunde länger drin schmoren, um darüber nachzudenken, wie man Zeit sinnvoll verwendet.Zu dieser CONV-Geschichte: Mit gescheiter Code-Formatierung kann man eine Menge Lesbarkeit herausholen - und ein Kommentar hilft dann auch. Klar kann man CONV und Kommentar auch weglassen, aber das zerreißt einem dann den ganzen verketteten Aufruf, was dann schon ärgerlich ist.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Neuer Artikel über BRF+ in der neuen iX 05/25!
Beitrag
von DeathAndPain (Top Expert / 1977 / 264 /
418
)
»
Leute, seid doch bitte so lieb und macht für eine Antwort nicht drei Antworten auf. Man kann unten auf "Ansicht erweitern" klicken und dann sehr wohl bei mehreren vorausgegangenen Texten auf "Zitieren". Die werden dann alle schön der Reihe nach ins Eingabefenster eingefügt, so dass man nur noch nicht benötigte Teile weglöschen muss.
Das erinnert mich dann an meine Informix 4/GL-Zeiten, in denen manche Programmierer am Anfang ihres Programms routinemäßig den Befehl
WHENEVER ERROR CONTINUE.
geschrieben haben, damit ihr Programm niemals abbricht, und damit war das dann gut. (Gedacht war dieser Befehl für eine Fehlerbehandlung Marke TRY/ENDTRY, hat aber eben auch ohne CATCH funktioniert. Er sollte eigentlich nur um Befehlsteile geschrieben werden, bei denen man mit gelegentlichen Fehlern rechnet und auf diese dann programmgesteuert reagieren möchte. Ohne CATCH bedeutet dass, das das Programm einfach weitermacht, wenn etwas schiefgelaufen ist. Dass Programmzustand und damit das Ergebnis in solch Fall völlig undefiniert sind, dürfte klar sein.)
Hm, jetzt wollte ich eigentlich ein Beispiel vortragen, in dem ein Kommentar mehr sagt als tausend kunstvoll verschachtelte Methoden, aber bei Licht betrachtet ist mein obiger IF-Block selbst ohne den Kommentar so sprechend, dass Paul Hardys OO-Code im Vergleich nur als schwer verständlicher Mist eingeschätzt werden kann. Er hat vielleicht gut modularisiert, aber von der Verständlichkeit her finde ich sein Beispiel alles andere als gut. Zumal man grübelt, was die Methode "require" überhaupt tun soll bzw. wie sie reagieren soll, wenn die Voraussetzung nun mal nicht erfüllt ist.
Und dann ist das Ergebnis zwar toll als logische Spielerei, aber aus Sicht produktiver Arbeit schlecht verständlich!
Ich möchte das bestreiten. CONV kann man ja ohnehin nur dort brauchen, wo eine dynamische Konvertierung möglich ist, wo man also auch eine Hilfsvariable definieren und den Inhalt dann einfach per Gleichheitszeichen zuweisen könnte. Insofern schlägt der CONV doch nur technische Brücken, ist inhaltlich aber weitgehend aussagelos, so dass man ihn problemlos überlesen kann. Da, wo CONV steht, will ich den Wert in den Klammern an, sagen wir, die Methode übergeben, ohne Ärger mit deren Parameterdefinition zu haben. Inhaltlich ist das völlig verständlich, vorausgesetzt, der Inhalt der CONV-Klammer passt von der Sache her zur Definition der Methode. Wenn nicht, dann wird CONV auch nicht funktionieren. Von daher würde ich sagen, überall dort, wo man CONV vorfindet, sollte er keine Verständnisprobleme verursachen, auch nicht mit Gartenzaun.Ja, da gebe ich dir Recht. Wenn man es _mal_ benutzt. Gerade in verketteten Aufrufen verkomplizieren die CONV-Konstrukte, da es nicht nur der Befehl CONV ist, sondern noch mindestens ein # plus Klammern.
Also ich bin durchaus schon öfter über das von mir schon zuvor geschilderte Problem gestolpert, dass mir eine Schnittstelle weggedumpt ist, weil die Domäne des übergebenen Parameters nicht identisch mit der Domäne der empfangenden Unterroutine war - und das obwohl beide Domänen technisch als Typ N mit Känge 8 definiert waren. ABAP kann da sehr kleinlich sein, und da hilft CONV wunderbar darüber hinweg.Am Häufigsten wird -wage ich einfach mal zu behaupten - CONV gebraucht, um "Text" zu übergeben (denn in den meisten anderen Fällen arbeitet man bereits mit dem richtigen Datentyp).
Sowas nervt, aber noch besser finde ich (in 5 Jahre altem Code):ewx hat geschrieben:Leider ein wirklich auch in meinen Augen ein Problem bei vielen.DeathAndPain hat geschrieben: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.
Der Klassiker:Code: Alles auswählen.
IF sy-subrc <> 0. "Fehlerhandling
Code: Alles auswählen.
IF sy-subrc <> 0.
" Ausprogrammieren!
ENDIF.WHENEVER ERROR CONTINUE.
geschrieben haben, damit ihr Programm niemals abbricht, und damit war das dann gut. (Gedacht war dieser Befehl für eine Fehlerbehandlung Marke TRY/ENDTRY, hat aber eben auch ohne CATCH funktioniert. Er sollte eigentlich nur um Befehlsteile geschrieben werden, bei denen man mit gelegentlichen Fehlern rechnet und auf diese dann programmgesteuert reagieren möchte. Ohne CATCH bedeutet dass, das das Programm einfach weitermacht, wenn etwas schiefgelaufen ist. Dass Programmzustand und damit das Ergebnis in solch Fall völlig undefiniert sind, dürfte klar sein.)
Doch, das muss sie sein! Wenn dem Schöpfer einer Routine nicht klar ist, was sie tun soll, dann hat er nicht genug darüber nachgedacht und sollte die Tastatur zur Seite schieben und sich überlegen, wo er mit seinem Code überhaupt hin will. Und wenn er das weiß, dann sollte er auch in der Lage sein, es zumindest in halbwegs brauchbarem Deutsch (oder von mir aus englisch) auch niederzuschreiben.ewx hat geschrieben:Prinzipiell ja. In der Praxis ist die Definition, was rein kommen darf und was raus gehen muss nicht einfach!
Ich nicht. Akademisch ist es spannend, aber was die Brauchbarkeit in der produktiven Praxis angeht, finde ich folgendes nicht nur wesentlich schneller implementierbar, sondern auch wesentlich besser verständlich (lesbar):ewx hat geschrieben:Paul Hardy spricht in seinem ziemlich genialen Buch ABAP To The Future von "Preconditions" und "Postconditions", die er auf Seite 277 wie folgt programmiert:Und die Postconditions mit ZCL_DBC=>ENSURE( THAT ...Code: Alles auswählen.
zcl_dbc=>require( that = 'The Monster has at least one eye' which_is_true_if = boolc( co_monster->md_no_of_eyes GE 1 ) ).
Die Idee finde ich super
Code: Alles auswählen.
* Wenn das Monster mindestens ein Auge hat, soll x = 1 sein, andernfalls 0.
IF co_monster->md_no_of_eyes GE 1.
x = 1.
ELSE.
x = 0.
ENDIF.ewx hat geschrieben:die Umsetzung ist extrem aufwändig sobald man mehrere Parameter und Parameterkombinationen hat. Auch die Definition, was wirklich zulässig ist bzw. erwartet wird, kann ziemlich kompliziert sein.
Und dann ist das Ergebnis zwar toll als logische Spielerei, aber aus Sicht produktiver Arbeit schlecht verständlich!
Ich bin auch ein Fan sprechender Namen und laufe dabei oft genug in die in meinen Augen prähistorische 30-Zeichen-Grenze (ganz zu schweigen von dem idiotischen 8-Zeichen-Limit bei Parametern auf Report-Selektionsbildschirmen). Dennoch packe ich fast immer auch einen ergänzenden Kommentar an den Anfang der Subroutine, und wenn es nur ein trivial scheinender Satz ist. Wenn man mal geistig nicht mehr so tief in dem Code drinsteckt, ist man für solche Orientierungshilfen immer dankbar - und wenn sie einem nur bestätigen, dass man richtig verstanden hat, was da passieren soll.ewx hat geschrieben:Nichts desto Trotz: Eine kurze Beschreibung, was die Methode macht und in welchem Kontext sie verwendet wird, ist sinnvoll. GET_SPECIAL_DATA oder CHECK_STATUS ist doch ziemlich nichtssagend...
Ich verstehe halt nicht, weshalb sie die Bindung der Variablen an die Schleife nicht statisch vom Compiler durchsetzen lassen - und weshalb sie überhaupt ein Derivat ohne Schleife (mit DATA) anbieten. In meinen Augen macht das die gute Idee kaputt. Anzunehmen, dass die Mehrheit der Programmierer sich an diese Empfehlung halten wird, halte ich für geradezu naiv.ralf hat geschrieben:Irgendwo in seinem Blog, das finde ich jetzt nicht mehr wirklich wieder - aber hieraus kann man das ableiten.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel
Ich mag es nicht, wenn man mir widerspricht!! ;DDeathAndPain hat geschrieben:Doch, das muss sie sein! Wenn dem Schöpfer einer Routine nicht klar ist, was sie tun soll, dann hat er nicht genug darüber nachgedacht und sollte die Tastatur zur Seite schieben und sich überlegen, wo er mit seinem Code überhaupt hin will. Und wenn er das weiß, dann sollte er auch in der Lage sein, es zumindest in halbwegs brauchbarem Deutsch (oder von mir aus englisch) auch niederzuschreiben.ewx hat geschrieben:Prinzipiell ja. In der Praxis ist die Definition, was rein kommen darf und was raus gehen muss nicht einfach!
Prinzipiell gebe ich dir ja Recht. In der Praxis ist das aber häufig nicht so einfach. In SAP schreibt man häufig Funktionen, die "alles" verarbeiten können müssen, da zu verarbeitenden Werte häufig aus dem Customizing kommen oder Stammdaten sind, die du nicht vollständig kennst. Hinzu kommt noch, dass auch der Fachbereich häufig nicht weiß, wie etwas Datentechnisch im System abgelegt ist. Vorgabe ist dann häufig: Verarbeitet werden dürfen nur "Maschinen". Natürlich kümmert man sich als guter Programmierer darum, wie denn "Maschine" im Materialstamm definiert ist. Und trotzdem gibt es (a) Ausnahmen die aus Gründen, die man oft nicht genau definiert bekommt, trotzdem verarbeitet werden müssen und (b) unterschiedliche Definitionen, je nachdem, wen man fragt. Schon klar, das sollte alles nicht sein und es ist in jedem Fall hilfreich, wenn man als erklärenden Satz dazu schreibt: "Hier dürfen nur Maschinen verarbeitet werden", aber es ist eben häufig nicht so eindeutig.
Die Bedingung sieht dann vielleicht so aus: "Wert A ist gültig, alle anderen nicht" oder "Werte B,C,D sind nicht gültig, alle anderen schon". Wenn nun das Customizing erweitert wird, was häufig vorkommt, ist die Bedingung nicht mehr klar.
Und prinzipiell sind wir uns glaube ich auch einig...
hmm. Ich habe wohl einen wichtigen Teil unterschlagen. Paul Hardy gibt in der Funktion ENSURE ein sehr leserliches Protokoll aus, wenn die Bedingung nicht zutrifft. Er schreibt dann einen Protokolleintrag, in dem er sich mittels FUBA SYSTEM_CALLSTACK den Namen der aufrufenden und der aktuellen Routine ausliest. Das Protokoll ist dann sehr sprechend:DeathAndPain hat geschrieben:ewx hat geschrieben:Paul Hardy spricht in seinem ziemlich genialen Buch ABAP To The Future von "Preconditions" und "Postconditions", die er auf Seite 277 wie folgt programmiert:Und die Postconditions mit ZCL_DBC=>ENSURE( THAT ...Code: Alles auswählen.
zcl_dbc=>require( that = 'The Monster has at least one eye' which_is_true_if = boolc( co_monster->md_no_of_eyes GE 1 ) ).
Die Idee finde ich superDeathAndPain hat geschrieben: Ich nicht. Akademisch ist es spannend, aber was die Brauchbarkeit in der produktiven Praxis angeht, finde ich folgendes nicht nur wesentlich schneller implementierbar, sondern auch wesentlich besser verständlich (lesbar):
Code: Alles auswählen.
* Wenn das Monster mindestens ein Auge hat, soll x = 1 sein, andernfalls 0. IF co_monster->md_no_of_eyes GE 1. x = 1. ELSE. x = 0. ENDIF.
Und dann ist das Ergebnis zwar toll als logische Spielerei, aber aus Sicht produktiver Arbeit schlecht verständlich!
This Diagnosis is intended for IT
Routine { ld_server_routine } of program { ld_server_program } has a contract
with routine { ld_client_routine } of program { ld_client_program }
Routine { ld_server_routine } agrees to carry out a certain task
This requires that { that }
That condition has not been fulfilled by calling routine { ld_client_routine }
and so therefore there is an error (bug) in routine { ld_client_routine } that needs to be corrected.
RAISE EXCEPTION TYPE zcx_violated_precondition
EXPORTING
md_condition = that
mo_error_log = lo_log.
Zuletzt geändert von ewx am 05.09.2017 13:23, insgesamt 1-mal geändert.
Beitrag
von DeathAndPain (Top Expert / 1977 / 264 /
418
)
»
Fehlersuche ist eine Sache, Beurteilung des Sollverhaltens eine andere. Ich bin ein großer Fan guter Protokolle, aber wenn man den Code einfach so durchliest (z.B. weil man den Ursachenpunkt eines Protokollfehlers lokalisieren möchte oder weil man dem bislang fehlerfreien Code eine Funktionalität hinzufügen möchte), dann ist Verständlichkeit des Codes ein hohes Gut.
Wenn man jetzt sagt, ich gehe mit der Modularisierung des Codes einen Schritt weiter als ansonsten notwendig/sinnvoll, weil das meine Möglichkeiten verbessert, ein gutes Fehlerprotokoll zu erhalten, dann kann ich das nachvollziehen. Nur über Lesbarkeit sollte man dann nicht argumentieren, sondern allenfalls festhalten, dass der Code durch diesen Schritt nicht komplett unverständlich wird.
Wenn man jetzt sagt, ich gehe mit der Modularisierung des Codes einen Schritt weiter als ansonsten notwendig/sinnvoll, weil das meine Möglichkeiten verbessert, ein gutes Fehlerprotokoll zu erhalten, dann kann ich das nachvollziehen. Nur über Lesbarkeit sollte man dann nicht argumentieren, sondern allenfalls festhalten, dass der Code durch diesen Schritt nicht komplett unverständlich wird.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel
ABAP ist von seinen Schöpfern (von denen ich einige persönlich kenne
und schätze) ganz bewusst sehr "geschwätzig" angelegt worden. Aus
gutem Grund. Programme in diesem Umfeld werden sehr alt und von
vielen Entwicklern betreut. Die gute Lesbarkeit und Verständlichkeit
ist dafür eine ganz entscheidende Eigenschaft.
Genau das wird mit der "neuen Syntax" ad absurdum geführt. Da war
der Assembler besser lesbar (ich habe das lange genug gemacht um es
beurteilen zu können).
Ein paar Dinge sind ganz praktisch (wenn man Sie nicht verschachtelt).
Den CONV schätze ich z.B. gar nicht. Man braucht Ihn vor allem für den
Aufruf von FuBas deren Parameter dümmlich definiert sind.
Entweder wird genau ein bestimmtes Datenformat benötigt, dann sollte
das im Programm auch vorhanden sein oder das Format ist weitgehend
frei; dann ist die forcierte Typenprüfung einfach nur falsch. Mir dem
CONV wird also eigentlich ein Designfehler versteckt. Sinnvoll ist anders.
und schätze) ganz bewusst sehr "geschwätzig" angelegt worden. Aus
gutem Grund. Programme in diesem Umfeld werden sehr alt und von
vielen Entwicklern betreut. Die gute Lesbarkeit und Verständlichkeit
ist dafür eine ganz entscheidende Eigenschaft.
Genau das wird mit der "neuen Syntax" ad absurdum geführt. Da war
der Assembler besser lesbar (ich habe das lange genug gemacht um es
beurteilen zu können).
Ein paar Dinge sind ganz praktisch (wenn man Sie nicht verschachtelt).
Den CONV schätze ich z.B. gar nicht. Man braucht Ihn vor allem für den
Aufruf von FuBas deren Parameter dümmlich definiert sind.
Entweder wird genau ein bestimmtes Datenformat benötigt, dann sollte
das im Programm auch vorhanden sein oder das Format ist weitgehend
frei; dann ist die forcierte Typenprüfung einfach nur falsch. Mir dem
CONV wird also eigentlich ein Designfehler versteckt. Sinnvoll ist anders.
Beitrag
von ralf.wenzel (Top Expert / 3955 / 202 /
281
)
»
Es gibt zwei gewichtige Punkte, die dazu geführt haben, dass ABAP sich weiterentwickeln musste. Einerseits sind die Anwendungen, die heute in ABAP geschrieben werden, deutlich komplexer als früher (die der SAP übrigens auch) und andererseits arbeiten auf der ganzen Welt zunehmend gelernte Informatiker mit der Sprache. Es gab Zeiten, in denen es wichtig war, dass die Sprache auch von Nicht-Informatikern verstanden wurde -- die Priorität liegt heute weniger stark auf dieser Eigenschaft. Ich habe für mich festgestellt, dass mit jedem neuen Release der informationstechnische Anspruch an Entwickler gestiegen ist. Um zu verstehen, wie ein EWM wirklich funktioniert, braucht man ganz andere Kenntnisse als das im MM oder FI der Fall ist.
Das kommt aber nicht nur von der SAP, sondern auch vom Kunden: Wenn ich vergleiche, was ich Ende der 90er so an Aufgabenstellungen hatte und mir ansehe, was ich heute so mache, kann man das gar nicht vergleichen. Wie viele Firmen haben sich denn früher hingesetzt und ein Entwicklungsteam unterhalten, um sich ein komplettes Modul zu schreiben und es dann selbst als Softwarehersteller zu vermarkten? Ich hatte inzwischen verschiedener solcher Kunden und habe jetzt wieder so einen. Klar kann man über Namensräume meckern, die auch Nachteile haben, aber für solche Unternehmen ist sowas unverzichtbar. Das ist ein gutes Beispiel dafür, wie sehr sich das Arbeitsumfeld von ABAP erweitert hat.
Was also gestern "bewusste Geschwätzigkeit" war, ist heute vllt nicht mehr am Puls der Zeit, weil eben eine andere Art von Entwicklern eine andere Art von Software entwickeln. Eclipse z. B. ist sehr beliebt in Entwicklungsteams, die eine eigene Entwicklungslandschaft betreiben, in die sie ihre SAP-Entwicklung integrieren wollen. Da geht es dann weniger um Fragen, welcher Editor sich wie verhält, sondern dass man die "entwicklungstechnische Insellösung" SAP in einen Verbund integrieren kann, in dem SAP ein Mitglied ist wie viele andere auch. Ein anderer Aspekt ist aber auch der, dass der "Kulturschock" kleiner wird für Entwickler aus anderen Sprachen, weil man sich syntaktisch diesen annähert. Dies war (und das sage nicht ich, das hat Horst Keller auf meine Vermutung hin bestätigt) einer der gewichtigen Gründe für die neue Syntax. Zudem kauft die SAP ständig Firmen auf, deren Lösungen integriert werden müssen, auch da ist so ein Aufeinanderprallen hinderlich.
Man sollte halt über den eigenen Tellerrand schauen, wenn man Entscheidungen nicht nachvollziehen kann -- weil Entscheidungen eben oft komplexe Hintergründe haben und die Kundenbasis der SAP ist eben sehr vielfältig. Klar, wer sein Tagwerk damit verrichtet, Batch-Input-Mappen zu schreiben oder SAPscript-Formulare zum Ausdrucken zu erzeugen (ohne das irgendwie herabzuwürdigen), der weiß mit vielen Dingen nichts anzufangen. Weil er eben nicht weiß, welche komplexen Prozesse anderswo auf Basis eines Formulars abgewickelt werden, weil es inzwischen Interaktive PDFs gibt, die als XML durch die Welt geschickt, in einer (nicht zwingend von SAP stammenden) Software ausgefüllt und digital signiert werden, ehe sie einen Genehmigungsprozess durchlaufen und von einer Software verarbeitet werden. Gedruckt wird sowas dann u. U. gar nicht mehr. Das ist weit entfernt von meinem ersten Formular, das ich 98 gebaut habe: Eine Auszahlungsanordnung für eine Kommune, die dann händisch vervollständigt, unterschrieben und in einem Archiv abgeheftet wurde.
Noch ein Wort zu CONV: Ich sehe das nicht, dass ich jeden Datentyp in einem Programm vorhalten muss, den eine aufgerufene Routine in der Schnittstelle hat. Schon deshalb, weil zum Teil verschiedene Funktionsbausteine einer Funktionsgruppe mal den einen, mal den anderen Typen verlangt, auch wenn mir gerade kein Beispiel dazu einfällt (mich hat sowas schon mehrfach geärgert). Das mag dann manchmal auch Schlamperei seitens der SAP sein, aber dann ist CONV der am wenigsten schmerzende Workaround, finde ich (das kann natürlich jeder sehen, wie er meint), eben WEIL er weniger geschwätzig ist. Denn, um mal wieder ein Bild zu bemühen: Wer zuviel sabbelt, der läuft Gefahr, dass die wirklich wichtige Nachricht im Geschwätz untergeht.
Ralf
Das kommt aber nicht nur von der SAP, sondern auch vom Kunden: Wenn ich vergleiche, was ich Ende der 90er so an Aufgabenstellungen hatte und mir ansehe, was ich heute so mache, kann man das gar nicht vergleichen. Wie viele Firmen haben sich denn früher hingesetzt und ein Entwicklungsteam unterhalten, um sich ein komplettes Modul zu schreiben und es dann selbst als Softwarehersteller zu vermarkten? Ich hatte inzwischen verschiedener solcher Kunden und habe jetzt wieder so einen. Klar kann man über Namensräume meckern, die auch Nachteile haben, aber für solche Unternehmen ist sowas unverzichtbar. Das ist ein gutes Beispiel dafür, wie sehr sich das Arbeitsumfeld von ABAP erweitert hat.
Was also gestern "bewusste Geschwätzigkeit" war, ist heute vllt nicht mehr am Puls der Zeit, weil eben eine andere Art von Entwicklern eine andere Art von Software entwickeln. Eclipse z. B. ist sehr beliebt in Entwicklungsteams, die eine eigene Entwicklungslandschaft betreiben, in die sie ihre SAP-Entwicklung integrieren wollen. Da geht es dann weniger um Fragen, welcher Editor sich wie verhält, sondern dass man die "entwicklungstechnische Insellösung" SAP in einen Verbund integrieren kann, in dem SAP ein Mitglied ist wie viele andere auch. Ein anderer Aspekt ist aber auch der, dass der "Kulturschock" kleiner wird für Entwickler aus anderen Sprachen, weil man sich syntaktisch diesen annähert. Dies war (und das sage nicht ich, das hat Horst Keller auf meine Vermutung hin bestätigt) einer der gewichtigen Gründe für die neue Syntax. Zudem kauft die SAP ständig Firmen auf, deren Lösungen integriert werden müssen, auch da ist so ein Aufeinanderprallen hinderlich.
Man sollte halt über den eigenen Tellerrand schauen, wenn man Entscheidungen nicht nachvollziehen kann -- weil Entscheidungen eben oft komplexe Hintergründe haben und die Kundenbasis der SAP ist eben sehr vielfältig. Klar, wer sein Tagwerk damit verrichtet, Batch-Input-Mappen zu schreiben oder SAPscript-Formulare zum Ausdrucken zu erzeugen (ohne das irgendwie herabzuwürdigen), der weiß mit vielen Dingen nichts anzufangen. Weil er eben nicht weiß, welche komplexen Prozesse anderswo auf Basis eines Formulars abgewickelt werden, weil es inzwischen Interaktive PDFs gibt, die als XML durch die Welt geschickt, in einer (nicht zwingend von SAP stammenden) Software ausgefüllt und digital signiert werden, ehe sie einen Genehmigungsprozess durchlaufen und von einer Software verarbeitet werden. Gedruckt wird sowas dann u. U. gar nicht mehr. Das ist weit entfernt von meinem ersten Formular, das ich 98 gebaut habe: Eine Auszahlungsanordnung für eine Kommune, die dann händisch vervollständigt, unterschrieben und in einem Archiv abgeheftet wurde.
Noch ein Wort zu CONV: Ich sehe das nicht, dass ich jeden Datentyp in einem Programm vorhalten muss, den eine aufgerufene Routine in der Schnittstelle hat. Schon deshalb, weil zum Teil verschiedene Funktionsbausteine einer Funktionsgruppe mal den einen, mal den anderen Typen verlangt, auch wenn mir gerade kein Beispiel dazu einfällt (mich hat sowas schon mehrfach geärgert). Das mag dann manchmal auch Schlamperei seitens der SAP sein, aber dann ist CONV der am wenigsten schmerzende Workaround, finde ich (das kann natürlich jeder sehen, wie er meint), eben WEIL er weniger geschwätzig ist. Denn, um mal wieder ein Bild zu bemühen: Wer zuviel sabbelt, der läuft Gefahr, dass die wirklich wichtige Nachricht im Geschwätz untergeht.
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
DeathAndPain
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Neuer Artikel über BRF+ in der neuen iX 05/25!
Beitrag
von black_adept (Top Expert / 4135 / 131 /
956
)
»
@DeathAndPain: Ist mir leider zwischendurch entfallen dass ich hier noch was zu fragen wollte: Einerseits plädierst du wie Horst Keller in Ralfs Link für Datendeklarationen am Anfang der Modularisierungseinheit. Andererseits erinnere ich mich, dass du die räumliche Trennung von Klassendefinitionen und Implementierung beklagst. Ist das kein Widerspruch?DeathAndPain hat geschrieben:Womit ich mich allerdings weiterhin nicht anfreunden kann, sind Inline-Deklarationen vom Typ NEW. Ich bin immer noch der Meinung, dass Datendeklarationen an den Anfang des Codes gehören und nicht mittenrein. Man könnte auch mittendrin einen DATA-Befehl bringen und würde sich damit (IMHO zu recht) eine Menge Schelte einfangen, obwohl es syntaktisch korrekt ist. NEW macht den Code spürbar schlechter lesbar für den Gewinn ein klitzekleinen Bisschens weniger Schreibarbeit.
Beitrag
von black_adept (Top Expert / 4135 / 131 /
956
)
»
Mein Lieblingsbeispiel ist die Kombination von CL_GUI_FRONTEND_SERVICES=>FILE_OPEN_DIALOG, dessen Rückgabetabelle Dateiname vom Typ FILENAME = CHAR1024 enthält, wohingegen dann das üblicherweise folgende CL_GUI_FRONTEND_SERVICES=>GUI_UPLOAD als Dateinamen gerne den Typ String hätte.ralf.wenzel hat geschrieben:Noch ein Wort zu CONV: Ich sehe das nicht, dass ich jeden Datentyp in einem Programm vorhalten muss, den eine aufgerufene Routine in der Schnittstelle hat. Schon deshalb, weil zum Teil verschiedene Funktionsbausteine einer Funktionsgruppe mal den einen, mal den anderen Typen verlangt, auch wenn mir gerade kein Beispiel dazu einfällt (mich hat sowas schon mehrfach geärgert).
Beitrag
von DeathAndPain (Top Expert / 1977 / 264 /
418
)
»
Darin kann ich keinen Widerspruch erkennen. Das beste Gegenbeispiel ist die FORM-Routine. Am Anfang stehen die Parameter, dann deklariert man per DATA alles, was man darin so braucht, und dann arbeitet man damit. Stattdessen aus der FORM zwei getrennte Blöcke zu machen, von denen der eine die Parameter und der andere die lokalen Variablen und den Code enthält (wie es bei lokalen Methoden der Fall ist), würde das Gebilde nur aufblähen. Zudem hätte man damit eben nicht mehr alle Deklarationen an einem Ort: Die lokalen Variablen stehen an einer Stelle, die Parameterdefinitionen (und nur um die geht es ja dabei) an einer völlig anderen. Sei ehrlich: Wenn Du mit Funktionsbausteinen arbeitest, schaltest Du dann immer auf den Parameterreiter (von denen es zudem noch mehrere gibt (Import/Export/Tables/Exceptions)) um, um rasch einen Parameter nachzusehen, oder bist Du nicht auch dankbar, dass das System Dir automatisiert die komplette Parameterliste als Kommentar an den Anfang des Quelltextes packt und diese bei Parameteränderungen auch stets aktualisiert? Bei globalen Klassen hat man dafür die Parameterdarstellung oben im Fenster (und das auch nur in der SE24, nicht in Eclipse). Bei lokalen Klassen jedoch stehste da.black_adept hat geschrieben:@DeathAndPain: Ist mir leider zwischendurch entfallen dass ich hier noch was zu fragen wollte: Einerseits plädierst du wie Horst Keller in Ralfs Link für Datendeklarationen am Anfang der Modularisierungseinheit. Andererseits erinnere ich mich, dass du die räumliche Trennung von Klassendefinitionen und Implementierung beklagst. Ist das kein Widerspruch?
Wie oft stecke ich in der Implementation einer Methode und frage mich, Mist, hatte ich den Parameter IS_NO_GOOD mit oder ohne Unterstrichen geschrieben? Dann muss ich ans andere Ende des Codes hüpfen, wo irgendwo zwischen vielen anderen Festlegungen die DEFINITION der Methode steht um nachzusehen. Bis ich wieder zurück bin, bin ich aus meinem Gedankengang herausgerissen: "Ok, jetzt weiß ich, wie der Parameter heißt, was wollte ich noch gleich machen?" Sowas empfinde ich als extrem kontraproduktiv. Erst recht, wenn es sich um fremden Code handelt und man die Bedeutung der Methode noch nicht genau verstanden hat. Man sieht "METHOD bla", dann wird mit irgendwelchen Werten gearbeitet, bei denen man nicht weiß, wo sie herkommen, und dann kommt "ENDMETHOD". Bei "METHOD bla" auch gleich die Information dabei zu haben, was reingeht und was rauskommt, wäre da extrem hilfreich. Als Krücke wird zur ungarischen Notation gegriffen, die das Problem aber nur unvollkommen abfedert, und im übrigen teile ich Ralfs Haltung zur ungarischen Notaton.
Eclipse gibt einem Hilfsmittel an die Hand, um diesen Effekt abzumildern, bekämpft damit aber nur Probleme, die man ohne die IMHO sinnlose Codeaufteilung in DEFINITION und IMPLEMENTATION nicht hätte. Endgültig absurd wird es dann bei DEFINITION DEFERRED. Eine Form interessiert auch nicht, ob sie am Anfang oder am Ende des Codes steht; sie funktioniert in beiden Fällen. Dass DEFINITION DEFERRED unter bestimmten Umständen überhaupt erforderlich ist, empfinde ich als reine Schikane.
Ich ärgere mich jedes Mal über die dynamischen Dokumente, bei denen Texte stets im Format sdydo_text_element (C255) übergeben werden müssen anstelle von CLIKE.
Beitrag
von ralf.wenzel (Top Expert / 3955 / 202 /
281
)
»
Ich habe noch ein weiteres Beispiel: COND/SWITCH. Ich habe wahnsinnig oft Coding wie dieses:
Sowas kriegt man per COND/SWITCH auf eine Programmzeile minimiert.
Ralf
Code: Alles auswählen.
if me->structure is initial.
me->structure = get_structure( ).
endif.Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Neuer Artikel über BRF+ in der neuen iX 05/25!
Vergleichbare Themen
2
Antw.
Antw.
6467
Views
Views
2
Antw.
Antw.
1584
Views
Views
ABAP Tabellen in SQL-Befehle exportieren
von cmalthaner » 15.08.2014 22:16 • Verfasst in ABAP® für Anfänger
von cmalthaner » 15.08.2014 22:16 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
2074
Views
Views
screen befehle in der Ablauflogik
von JohnLocklay » 22.11.2016 10:21 • Verfasst in ABAP® für Anfänger
von JohnLocklay » 22.11.2016 10:21 • Verfasst in ABAP® für Anfänger
5
Antw.
Antw.
3942
Views
Views
Wie kann ich in SAPSCRIPT HTML Befehle eingeben.?
von SAPDIDI2 » 18.07.2007 16:11 • Verfasst in ABAP® Core
von SAPDIDI2 » 18.07.2007 16:11 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.