"Neue" Befehle im ABAP - wer verwendet diese
Beitrag
von DeathAndPain (Top Expert / 2004 / 271 /
424
)
»
Das mit der einen Zeile ist sowieso interpretationsbedürftig, denn rein syntaktisch darf man - nur unter Berücksichtigung der Grenzen, die der ABAP Editor vorgibt - auch das ganze, große Programm in eine Zeile schreiben.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Naja, es ist schon klar, dass mit "eine Zeile" kein "String" gemeint war.DeathAndPain hat geschrieben:Das mit der einen Zeile ist sowieso interpretationsbedürftig, denn rein syntaktisch darf man - nur unter Berücksichtigung der Grenzen, die der ABAP Editor vorgibt - auch das ganze, große Programm in eine Zeile schreiben.
Beitrag
von ralf.wenzel (Top Expert / 3991 / 208 /
282
)
»
Das ist so ein Klassiker, den ich gern hervorheben möchte. Solcherlei gibt es viele, die dann zu Hilfsvariablen und "Drumherum-Programmieren" nötigen, was dann vom eigentlichen Zweck der Logik ablenkt, selbst wenn man es kapselt. Und gerade beim Lesen von Programmen möchte ich jegliche Ablenkung vermeiden.ewx hat geschrieben: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.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 2004 / 271 /
424
)
»
Gebe ich Dir recht, aber diese Tür schwingt in beide Richtungen. Zu stark geschachtelte Anweisungen, sei es über geschachtelte funktionale Methoden, sei es über mit dem FOR-Befehl bewerkstelligte Schweinereien, können weit mehr ablenken, weil sie den Programmierer zwingen, sich geistig vom Inhalt zu lösen, um erst mal die komplizierte Syntax zu dekodieren.Und gerade beim Lesen von Programmen möchte ich jegliche Ablenkung vermeiden.
Flame Disclaimer: Ich behaupte nicht, dass das in jedem Anwendungsfall dieser Elemente so ist.
Was ich mir als Verbesserung in ABAP wünschen würde, ist die Unterstützung der WHERE-Klausel auch im LOOP AT SCREEN. Der würde dadurch kürzer, besser lesbar und obendrein wohl auch schneller werden, als wenn man über sämtliche Dynprofelder loopt und dann mit CHECK oder gar mit IF prüft, ob man das richtige bzw. eines der richtigen erreicht hat.
Kannst Du das Horst Keller mal vorschlagen? Würde mich mal interessieren, was er dazu sagt.
Beitrag
von DeathAndPain (Top Expert / 2004 / 271 /
424
)
»
And while you are on it, wäre es auch nicht schlecht, wenn SELECT-OPTIONS sich in einem neuen Release genau wie PARAMETERS mit einem Datentypen als Referenz zufriedengeben würde, damit man nicht immer eine nutzlose globale Dummyvariable definieren muss.
Beitrag
von ralf.wenzel (Top Expert / 3991 / 208 /
282
)
»
Uiuiui. Ein LOOP AT...WHERE... würde wohl kaum schneller werden bei einer schlüssellosen Standardtabelle. Von CHECK rät die SAP aus guten Gründen ab.
Ansonsten gebe ich dir recht: Man sollte solche Mittel nicht inflationär einsetzen, Lesbarkeit ist ein wichtiges Kriterium.
Ralf
Ansonsten gebe ich dir recht: Man sollte solche Mittel nicht inflationär einsetzen, Lesbarkeit ist ein wichtiges Kriterium.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 2004 / 271 /
424
)
»
Nicht vergleichbar mit einer Indexsuche (wobei eine Standardtabelle mit so wenigen Einträgen, wie ein Dynpro typischerweise Elemente hat, sequentiell schneller durchsucht wird als eine sortierte Tabelle über Index, siehe mein Testprogramm von neulich). Aber die Suche innerhalb des ABAP-Compilers durchzuführen, also eine Sprachenebene niedriger, halte ich für allemal performanter, als es in ABAP mit diskreten Befehlen zu machen. Überdies wird der Code dadurch kürzer und besser lesbar, da sich der IF/CHECK in der Schleife erübrigt. Obendrein ist die Darstellung mit WHERE beim Code-Lesen besser verständlich.Ein LOOP AT...WHERE... würde wohl kaum schneller werden bei einer schlüssellosen Standardtabelle.
Da hatten wir doch kürzlich hier erst die Diskussion, in der sich alle einig waren, dass zumindest bei Schleifen gegen CHECK nichts einzuwenden sei.Von CHECK rät die SAP aus guten Gründen ab.
Davon abgesehen muss CHECK die Lesbarkeit nicht verschlechtern (ich persönlich bin im Gegenteil der Meinung, dass er das niemals tut, auch wenn ich weiß, dass ich mit der Ansicht ziemlich alleine dastehe.)
Welches der beiden Codings ist schlechter verständlich/lesbar?
Code: Alles auswählen.
LOOP AT SCREEN.
IF SCREEN-NAME = 'HIER_NIX_EINGEBEN'.
SCREEN-INPUT = '0'.
MODIFY SCREEN.
ENDIF.
ENDLOOP.Code: Alles auswählen.
LOOP AT SCREEN.
CHECK SCREEN-NAME = 'HIER_NIX_EINGEBEN'.
SCREEN-INPUT = '0'.
MODIFY SCREEN.
ENDLOOP.Noch schöner wäre:
Code: Alles auswählen.
LOOP AT SCREEN WHERE SCREEN-NAME = 'HIER_NIX_EINGEBEN'.
SCREEN-INPUT = '0'.
MODIFY SCREEN.
ENDLOOP.Code: Alles auswählen.
READ TABLE SCREEN WITH KEY NAME = 'HIER_NIX_EINGEBEN'.
SCREEN-INPUT = '0'.
MODIFY SCREEN.
Beitrag
von black_adept (Top Expert / 4155 / 134 /
958
)
»
Wenn es denn ginge plädiere ich fürDeathAndPain hat geschrieben: Und wenn ich drüber nachdenke, wäre die allerschönste, die eigentlich angemessene Syntax:
Code: Alles auswählen.
READ TABLE SCREEN WITH KEY NAME = 'HIER_NIX_EINGEBEN'. SCREEN-INPUT = '0'. MODIFY SCREEN.
SCREEN[ name = 'HIER_NIX_EINGEBEN' ]-input = '0'.
Nein, du bist nicht allein. CHECK macht in vielen Situationen Sinn.DeathAndPain hat geschrieben: Davon abgesehen muss CHECK die Lesbarkeit nicht verschlechtern (ich persönlich bin im Gegenteil der Meinung, dass er das niemals tut, auch wenn ich weiß, dass ich mit der Ansicht ziemlich alleine dastehe.)
Da gibt es ein Problem: Namen können doppelt vorkommen!DeathAndPain hat geschrieben: Und wenn ich drüber nachdenke, wäre die allerschönste, die eigentlich angemessene Syntax:Code: Alles auswählen.
READ TABLE SCREEN WITH KEY NAME = 'HIER_NIX_EINGEBEN'. SCREEN-INPUT = '0'. MODIFY SCREEN.
Der Screen ist natürlich in der Realität gar keine Tabelle.DeathAndPain hat geschrieben: Dass man auf SCREEN nicht richtig wie auf andere interne Tabellen zugreifen kann, halte ich für eine Eigenart, die auf technischen Unzulänglichkeiten längst vergangener Releases beruht. Heute sollte es kein Problem mehr sein, das volle Befehlsarsenal auch für SCREEN bereitzustellen.
Der Loop ist in der Tat ein Hilfskonstrukt. Eine Abbildung
des Befehlsumfangs wäre aber wirklich schön.
Der Befehl ist sogar noch viel tückischer! Entgegen derblack_adept hat geschrieben: Wenn es denn ginge plädiere ich fürSCREEN[ name = 'HIER_NIX_EINGEBEN' ]-input = '0'.
Erwartung die sich aus der Syntax ergibt erwischt er auch
nur das erste Vorkommen von 'HIER_NIX_EINGEBEN'.
Solches Coding provoziert Fehler!
Seit wann das denn?!Daniel hat geschrieben: Da gibt es ein Problem: Namen können doppelt vorkommen!
Beitrag
von ralf.wenzel (Top Expert / 3991 / 208 /
282
)
»
Das Problem beim CHECK ist, dass es den aktuellen Verarbeitungsblock verlässt, es also kontextabhängig unterschiedliche Dinge tut. Und gerade in Monolithen mit LOOP in LOOP in DO in FORM verliert man hin und wieder den Überblick - und ja, ich kenne konkrete Beispiele dafür.
Ein IF....CONTINUE...ENDIF in einem LOOP macht das gleiche wie ein CHECK in einem LOOP, aber wenn ich den LOOP rauswerfe, ist der CONTINUE syntaktisch falsch (und tut nicht einfach was anderes, wie das ein CHECK macht).
Darum finde ich das IF-Konstrukt besser, weil es eindeutiger ist. CHECK verwende ich grundsätzlich nicht mehr - weil ich es schwerer lesbar finde. Allerdings verwende ich es negativ, also nicht:
sondern:
So verhindere ich ewige IF in IF in IF-Konstrukte, die ich auch nicht sehr übersichtlich finde.
Ralf
Ein IF....CONTINUE...ENDIF in einem LOOP macht das gleiche wie ein CHECK in einem LOOP, aber wenn ich den LOOP rauswerfe, ist der CONTINUE syntaktisch falsch (und tut nicht einfach was anderes, wie das ein CHECK macht).
Darum finde ich das IF-Konstrukt besser, weil es eindeutiger ist. CHECK verwende ich grundsätzlich nicht mehr - weil ich es schwerer lesbar finde. Allerdings verwende ich es negativ, also nicht:
Code: Alles auswählen.
LOOP at itab.
if a = b.
...
endif.
endloop.Code: Alles auswählen.
loop at itab.
if a ne b.
continue.
endif.
....
endloop.Naja, es ist ein READ - jeder READ erwischt nur einen Satz. Wo nimmst du die Erwartungshaltung her, dass diese Anweisung mehrere Vorkommen erwischt?Daniel hat geschrieben:Entgegen der Erwartung die sich aus der Syntax ergibt erwischt er auch
nur das erste Vorkommen von 'HIER_NIX_EINGEBEN'.
Ralf
Zuletzt geändert von ralf.wenzel am 13.09.2017 11:19, insgesamt 1-mal geändert.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3991 / 208 /
282
)
»
*Doppelpost, sorry
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 2004 / 271 /
424
)
»
Strong NACK.
Du siehst: Bei CHECK wie bei CONTINUE ist es (wie generell beim Programmieren) erforderlich, den Überblick zu behalten, wo man sich befindet. Andernfalls hat man ein strukturelles Problem und sollte seinen Code besser gliedern (modularisieren). Der Unterschied zwischen CHECK und CONTINUE ist nur, dass CHECK (wie EXIT) halt auch Subroutinen verlassen kann. Aber für diese Unterscheidung muss man nur wissen, ob man sich in einer Schleife befindet oder nicht. Und diese Information ist beim Programmieren so essenziell, dass man sie immer im Kopf haben sollte, sonst hat man die Orientierung verloren und sollte sie erst mal wiederfinden, bevor man weitermacht.
aus Deiner ersten Version noch mehr Code innerhalb der Schleife kommt (und das ist ja keineswegs unüblich), dann wirst Du Dich mit Deiner negativen Variante gewaltig wundern, was passiert.
Das ist das typische Argument gegen CHECK. Ich halte es nicht für valide, denn an der Aufrufstelle des CHECK muss man ja nicht die ganze Aufrufhierarchie kennen, sondern nur den innersten Verarbeitungsblock. Wenn man so weit die Übersicht verloren hat, dass man nicht mehr weiß, ob man sich in einer Schleife befindet oder nicht, dann hat man ein Problem, das mit CHECK nichts zu tun hat. Weiß man das aber noch, dann weiß man genug, und dann ist es völlig egal, ob da außenrum noch weitere LOOPs, DOs oder FORMs sind.Das Problem beim CHECK ist, dass es den aktuellen Verarbeitungsblock verlässt, es also kontextabhängig unterschiedliche Dinge tut. Und gerade in Monolithen mit LOOP in LOOP in DO in FORM verliert man hin und wieder den Überblick - und ja, ich kenne konkrete Beispiele dafür.
Wenn Du aber einen LOOP in einem LOOP hast und schmeißt den inneren LOOP raus, dann passiert genau das gleiche, was Du dem CHECK gerade vorwirfst: der CONTINUE "tut einfach was anderes", wie Du es ausgedrückt hast, da er dann nämlich plötzlich die äußere Schleife fortsetzt. Das kann Dir also bei CONTINUE genauso passieren wie bei CHECK. Der einzige Befehl aus diesem Themengebiet, bei dem das nicht so ist, ist RETURN (den man wohl extra zu diesem Zweck als Ablöse für EXIT eingeführt hat).Ein IF....CONTINUE...ENDIF in einem LOOP macht das gleiche wie ein CHECK in einem LOOP, aber wenn ich den LOOP rauswerfe, ist der CONTINUE syntaktisch falsch (und tut nicht einfach was anderes, wie das ein CHECK macht).
Du siehst: Bei CHECK wie bei CONTINUE ist es (wie generell beim Programmieren) erforderlich, den Überblick zu behalten, wo man sich befindet. Andernfalls hat man ein strukturelles Problem und sollte seinen Code besser gliedern (modularisieren). Der Unterschied zwischen CHECK und CONTINUE ist nur, dass CHECK (wie EXIT) halt auch Subroutinen verlassen kann. Aber für diese Unterscheidung muss man nur wissen, ob man sich in einer Schleife befindet oder nicht. Und diese Information ist beim Programmieren so essenziell, dass man sie immer im Kopf haben sollte, sonst hat man die Orientierung verloren und sollte sie erst mal wiederfinden, bevor man weitermacht.
Hast dafür dann aber semantisch auch was anderes. Wenn nämlich hinter demralf.wenzel hat geschrieben:Darum finde ich das IF-Konstrukt besser, weil es eindeutiger ist. CHECK verwende ich grundsätzlich nicht mehr - weil ich es schwerer lesbar finde. Allerdings verwende ich es negativ, also nicht:
sondern:Code: Alles auswählen.
LOOP at itab. if a = b. ... endif. endloop.
So verhindere ich ewige IF in IF in IF-Konstrukte, die ich auch nicht sehr übersichtlich finde.Code: Alles auswählen.
loop at itab. if a ne b. continue. endif. .... endloop.
Code: Alles auswählen.
if a = b.
...
endif.Man muss halt die neue Syntax erst verinnerlichen. Wenn man sie noch nicht kennt und nur intuitiv zu verstehen sucht, dann suggeriert sie in der Tat etwas anderes. Daraus würde ich ihr aber auch keinen Vorwurf konstruieren wollen.Naja, es ist ein READ - jeder READ erwischt nur einen Satz. Wo nimmst du die Erwartungshaltung her, dass diese Anweisung mehrere Vorkommen erwischt?
Vergleichbare Themen
2
Antw.
Antw.
6687
Views
Views
2
Antw.
Antw.
1757
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.
2346
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.
4381
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.