Goldene Regeln der Programmierung
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
In ABAP 7.40:babap hat geschrieben:Code: Alles auswählen.
DATA: lt_tabelle TYPE irgendeine Tabelle. FIELD-SYMBOLS: <lt_tabelle> LIKE LINE OF lt_tabelle. * füllen APPEN INTITIAL LINE TO lt_tabelle ASSIGNING <lt_tabelle>. <lt_tabelle>-Feld1 = ... LOOP AT lt_tabelle ASSIGNING <lt_tabelle>. <lt_tabelle>-feld2 = ... * mach sonstwas ENDLOOP. READ TABLE lt_tabelle assigning <lt_tabelle> index Zahl. * oder ... with key feld1 = 'XX' .
Code: Alles auswählen.
data: tab type irgendeine Tabelle
loop at tab assigning field-symbol(<tabline>).
Code: Alles auswählen.
read table tab with (table) key ... assigning field-symbol(<tabline>).Das entrümpelt Deklarationsblöcke ganz erheblich.
Ansonsten verstehe ich die Diskussionen gar nicht -- wenn ich mit Referenzen arbeite, brauche ich zum Dereferenzieren doch eh wieder Feldsymbole.
Off-Topic: Liebe Admins, kriegt ihr irgendwie ein Smartphone-tauglicheres Alternativlayout hin? Das ist ja wie SAPGUI auf einem iPhone :-/
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Tatsächlich tragen wir hier was zusammen, was sich "aus unserer Sicht" am Besten in der Praxis (und aus der eigenen Erfahrung) bewährt hat.
Wir alle wissen, was von SAP-Dokumentationen, -Beschreibungen oder -Empfehlungen zu halten ist ;-D
Das, was ich oben geschrieben habe, entspricht in etwa den Anweisungen, die ich vor ein paar Jahren bei SAP in einem Programmierteam erhalten habe.
Viele Grüße
babap
Wir alle wissen, was von SAP-Dokumentationen, -Beschreibungen oder -Empfehlungen zu halten ist ;-D
Das, was ich oben geschrieben habe, entspricht in etwa den Anweisungen, die ich vor ein paar Jahren bei SAP in einem Programmierteam erhalten habe.
Viele Grüße
babap
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das war ja kein Vorwurf, sondern lediglich ein Hinweis darauf, dass es mit ABAP 7.40 interessante Neuerungen gibt 
Das ist doch das Schöne an unserem Beruf: Es ist stets alles in Bewegung.
Das ist doch das Schöne an unserem Beruf: Es ist stets alles in Bewegung. Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hi,
ein Aspekt fiel mir noch auf, es wurde geschrieben, dass man lieber Referenzen nimmt, weil man "globale" Feldsymbole in einer Klasse nicht benutzen kann oder darf (man benötigt sie angeblich, um aus performancegründen auf Tabelleninhalte zuzugreifen).
Bin öfter mal zum Thema Performance engagiert und unterwegs, von daher weiß ich, dass die Realität bei der Programmier-Performance sich oft ganz anders darstellt, als man gemeinhin denkt.
Probleme bei der Programmperformance sind oft überflüssige und wiederholte Datenzugriffe (und mal wieder ein Select-Single, auf 'ne Zeile, die man vorhin schon geholt hatte, oder die das übergeordnete Programm gerade eben erst gelesen hatte ... etc.) Abhilfe bringt hier das Vermeiden von select, und die Konsequente Nutzung von SAP-Lesebausteinen (die es für fast alle Standardtabellen gibt). Bei eigenen Tabellen schreibt man einen Pufferbaustein, oder nimmt gleich die Persistenten Objekte ...
Weitere Problempunkte sind die Schleifenverarbeitungen, wo eine Tabelle verarbeitet wird, und aus anderen Tabellen was dazu gesucht wird ... sobald man Loop in Loop in Loop hat, geht die Performance mit Faktor O(n³) den Bach runter.
Wenn man mehrere Tabellen mit Keyzugriff verarbeitet, lohnt es sich fast immer vorher zu sortieren und in einer einzigen Schleife den ganzen Kram abzuarbeiten ... Da ist etwas mehr Gehirnschmalz und etwas mehr Coding erforderlich, aber der Gewinn ist immens.
Die "Move"-Performace, über die man früher noch ofter nachdachte, und zu der es bestimmte Tipps gibt, ist aus meiner Sich nicht mehr so dramatsich.
Bestimmte Techniken wie lazy sharing etc. führen dazu, dass so gut wie garnicht mehr "gemoved" wird, sondern ein move führt bloß dazu, dass das Zielfeld eine Referenz auf das Ausgangsfeld erhält. (es ist quasi ein impliziter Assign mit Feldsymbol).
Erst in dem (oft unwahrscheinlichen) Fall, wenn sich Quelle oder Ziel ändern, wird die Referenz aufgelöst und der Wert übertragen oder geändert. Das kann zu dem unglaublichen Effekt führen, dass man 100 Kopien einer großen Tabelle im Programm erstellt und mit diesen Arbeite, sie sortiert etc. Das Programm fliegt aber mit Speicherüberlauf raus, wenn in der letzten Programmzeile noch mal eben die Quelltabelle geändert wird ... denn dann wird einiges an Moves und Speicer fällig.
Zum Thema "Global" habe ich nur die Meinung: lieber nicht ... geht alles lokal oder per Übergabevariablen (Funktionsbaustein, Klasse).
Gerade Feldsymbole kann man mit ANY erstmal neutral anlegen, und dann universell verwenden.
Mit Assign auf Feldnummer oder Feldnamen kommt man an jedes Feld einer Struktur ran ... etc.
Habe mal in einem SAP-Projekt (bei SAP) vollvariabel programmieren müssen ... man wusste nicht, welche Struktur da "reinschneit" ... und das ging alles ohne Referenzen, ohne globale Variablen, ohne globale Feldsymbole ...
(Das Einzige, wofür man wirklich eine Referenz braucht, außer für Objekte, ist CREATE DATA ... und diese Referenz muss man gleich wieder in ein Feldsymbol dereferenzieren, damit man gescheit damit arbeiten kann ...)
Viele Grüße
babap
ein Aspekt fiel mir noch auf, es wurde geschrieben, dass man lieber Referenzen nimmt, weil man "globale" Feldsymbole in einer Klasse nicht benutzen kann oder darf (man benötigt sie angeblich, um aus performancegründen auf Tabelleninhalte zuzugreifen).
Bin öfter mal zum Thema Performance engagiert und unterwegs, von daher weiß ich, dass die Realität bei der Programmier-Performance sich oft ganz anders darstellt, als man gemeinhin denkt.
Probleme bei der Programmperformance sind oft überflüssige und wiederholte Datenzugriffe (und mal wieder ein Select-Single, auf 'ne Zeile, die man vorhin schon geholt hatte, oder die das übergeordnete Programm gerade eben erst gelesen hatte ... etc.) Abhilfe bringt hier das Vermeiden von select, und die Konsequente Nutzung von SAP-Lesebausteinen (die es für fast alle Standardtabellen gibt). Bei eigenen Tabellen schreibt man einen Pufferbaustein, oder nimmt gleich die Persistenten Objekte ...
Weitere Problempunkte sind die Schleifenverarbeitungen, wo eine Tabelle verarbeitet wird, und aus anderen Tabellen was dazu gesucht wird ... sobald man Loop in Loop in Loop hat, geht die Performance mit Faktor O(n³) den Bach runter.
Wenn man mehrere Tabellen mit Keyzugriff verarbeitet, lohnt es sich fast immer vorher zu sortieren und in einer einzigen Schleife den ganzen Kram abzuarbeiten ... Da ist etwas mehr Gehirnschmalz und etwas mehr Coding erforderlich, aber der Gewinn ist immens.
Die "Move"-Performace, über die man früher noch ofter nachdachte, und zu der es bestimmte Tipps gibt, ist aus meiner Sich nicht mehr so dramatsich.
Bestimmte Techniken wie lazy sharing etc. führen dazu, dass so gut wie garnicht mehr "gemoved" wird, sondern ein move führt bloß dazu, dass das Zielfeld eine Referenz auf das Ausgangsfeld erhält. (es ist quasi ein impliziter Assign mit Feldsymbol).
Erst in dem (oft unwahrscheinlichen) Fall, wenn sich Quelle oder Ziel ändern, wird die Referenz aufgelöst und der Wert übertragen oder geändert. Das kann zu dem unglaublichen Effekt führen, dass man 100 Kopien einer großen Tabelle im Programm erstellt und mit diesen Arbeite, sie sortiert etc. Das Programm fliegt aber mit Speicherüberlauf raus, wenn in der letzten Programmzeile noch mal eben die Quelltabelle geändert wird ... denn dann wird einiges an Moves und Speicer fällig.
Zum Thema "Global" habe ich nur die Meinung: lieber nicht ... geht alles lokal oder per Übergabevariablen (Funktionsbaustein, Klasse).
Gerade Feldsymbole kann man mit ANY erstmal neutral anlegen, und dann universell verwenden.
Mit Assign auf Feldnummer oder Feldnamen kommt man an jedes Feld einer Struktur ran ... etc.
Habe mal in einem SAP-Projekt (bei SAP) vollvariabel programmieren müssen ... man wusste nicht, welche Struktur da "reinschneit" ... und das ging alles ohne Referenzen, ohne globale Variablen, ohne globale Feldsymbole ...
(Das Einzige, wofür man wirklich eine Referenz braucht, außer für Objekte, ist CREATE DATA ... und diese Referenz muss man gleich wieder in ein Feldsymbol dereferenzieren, damit man gescheit damit arbeiten kann ...)
Viele Grüße
babap
Dazu hätte ich auch gleich mal eine Frage, weil ich eigentlich auch bemüht bin, globale Variablen, soweit möglich, zu vermeiden: Wenn man mit Dynpros arbeitet, ist mir keine Möglichkeit der Datenübergabe (außer SAP/ABAP Memory, aber macht das hier Sinn??) bekannt. Hierfür bräuchte man ja dann gezwungenermaßen globale Variablen, oder wie löst ihr das?babap hat geschrieben: Zum Thema "Global" habe ich nur die Meinung: lieber nicht ... geht alles lokal oder per Übergabevariablen
[...]
Habe mal in einem SAP-Projekt (bei SAP) vollvariabel programmieren müssen ... man wusste nicht, welche Struktur da "reinschneit" ... und das ging alles ohne Referenzen, ohne globale Variablen, ohne globale Feldsymbole ...
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Mit dem Bus Screen Framework. Ich kann dir nachher ein paar Zeilen dazu schreiben, wenn ich im Büro bin. Am iPhone ist mir das zu anstrengend
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Eine Möglichkeit wären PUPLIC-Variablen einer Klasse (statisch) oder eines Objektes.Pyro hat geschrieben:Wenn man mit Dynpros arbeitet, ist mir keine Möglichkeit der Datenübergabe (außer SAP/ABAP Memory, aber macht das hier Sinn??) bekannt. Hierfür bräuchte man ja dann gezwungenermaßen globale Variablen, oder wie löst ihr das?
z.B.: CL_CLASS=>GD_DATUM bzw. GR_OBJECT->GD_DATUM als Feldname im Screenpainter verwenden.
Wobei man hier streng genommen eigentlich auch mit globalen Variablen arbeitet. GR_OBJECT müsste global im Programm bekannt sein und ein Attribut einer Klasse als PUBLIC (ohne Read-Only) zu Definieren/Verwenden ist nicht gut. Dafür sollte es nach OO bzw. MVC ja GETter/SETter geben.
Was das BUS hier anders macht würde mich interessieren.ralf.wenzel hat geschrieben:Mit dem Bus Screen Framework.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das macht es genau so, allerdings nicht statisch, sondern mit dem Dynpro als Objektinstanz. Allerdings ist (jetzt wird meine Aussprache wieder zu blumig) ein Objektattribut nicht einfach nur ein Feld, sondern ein Feld mit angeklebter Logik, also mit einem semantischen Kontext.
Das ist es so im Groben. Man muss Dialogprogrammierung eigentlich gar nicht mehr können, weil fast alles schon im SAP-Teil steckt. tabstrips, Table Controls, etc. Wird alles nur noch instanziiert und aufgerufen.
Das ist es so im Groben. Man muss Dialogprogrammierung eigentlich gar nicht mehr können, weil fast alles schon im SAP-Teil steckt. tabstrips, Table Controls, etc. Wird alles nur noch instanziiert und aufgerufen.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
ein Dynpro verwende ich bei neuen Applikationen maximal noch beim Start (und das braucht nach herkömmlicher Logik noch globale Variablen).
Dann übergibt das Programm alle eingegebenen Variablen an Objekt oder Funktionsbausteine zur Prüfung (AT ...) oder zur Weiterverarbeitung (START OF SELECTION ...).
Die weitere Anwendung tummelt sich dann nur noch auf ALV-Grids oder agiert mit Dialogboxen.
Für weitere Programmierfälle braucht man aus meiner Sicht NIEMALS mehr globale Variablen.
(ist ein beliebtes Thema bei Fehlersuchen, die auch zu meinen "Emergency-Aktivitäten" zählen ...)
Viele Grüße
babap
ein Dynpro verwende ich bei neuen Applikationen maximal noch beim Start (und das braucht nach herkömmlicher Logik noch globale Variablen).
Dann übergibt das Programm alle eingegebenen Variablen an Objekt oder Funktionsbausteine zur Prüfung (AT ...) oder zur Weiterverarbeitung (START OF SELECTION ...).
Die weitere Anwendung tummelt sich dann nur noch auf ALV-Grids oder agiert mit Dialogboxen.
Für weitere Programmierfälle braucht man aus meiner Sicht NIEMALS mehr globale Variablen.
(ist ein beliebtes Thema bei Fehlersuchen, die auch zu meinen "Emergency-Aktivitäten" zählen ...)
Viele Grüße
babap
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Und du hast niemals Anforderungen, wo man mal ein echtes Dynpro braucht? Bzw. wo dein ALV nur einen Teil der Informationen halten kann? Z.B. so was wie eine Datenerfassung mit ein paar Tabstrips.
Naja - und dann frage ich auch gleich ganz ketzerisch - wenn du die eingegebenen Variablen an ein Objekt übergibst müsste dieses ( oder eine Referenz darauf ) doch global definiert sein. Und der Aufruf einer FuGr oder eines statischen Objekts erzeugt doch auch implizit globale Variablen ( im FuGr-Kontext ), so dass sich die Globalität in meinen Augen nur aus dem Programm in die Modularisierungseinheit verlagert.
Naja - und dann frage ich auch gleich ganz ketzerisch - wenn du die eingegebenen Variablen an ein Objekt übergibst müsste dieses ( oder eine Referenz darauf ) doch global definiert sein. Und der Aufruf einer FuGr oder eines statischen Objekts erzeugt doch auch implizit globale Variablen ( im FuGr-Kontext ), so dass sich die Globalität in meinen Augen nur aus dem Programm in die Modularisierungseinheit verlagert.
Hallo,
über implizite Globalisierungen und andere intere Dinge möchte ich hier kein Haare spalten.
Ich denke, es ist klar, was ich mit "Vermeiden von Globalen Variablen" meine (viele Programme sind voll von überflüssig als global definierten Variablen).
Mein Ansatz ist es, so modular und objektnah zu programmieren wie möglich, auch wenn man in einem "Report-Kontext" arbeitet.
Damit werden die Referenzvariablen NICHT global definiert, sondern etwaige Prüfungen bzw. Verarbeitungen werden als Form-Routine angelegt, und die Referenze sind dort lokal.
Diesen Form-Routinen übergebe ich die globalen Variablen schon mal in der USING-Anweisung (wohl wissend, dass das nicht unbedingt notwendig wäre, weil man ja noch im Report ist ...). Damit bin ich so "lokal wie möglich" und kann den Absprung in Funktionsbausteine oder OO-Objekte starten!
Viele Grüße
babap
über implizite Globalisierungen und andere intere Dinge möchte ich hier kein Haare spalten.
Ich denke, es ist klar, was ich mit "Vermeiden von Globalen Variablen" meine (viele Programme sind voll von überflüssig als global definierten Variablen).
Mein Ansatz ist es, so modular und objektnah zu programmieren wie möglich, auch wenn man in einem "Report-Kontext" arbeitet.
Damit werden die Referenzvariablen NICHT global definiert, sondern etwaige Prüfungen bzw. Verarbeitungen werden als Form-Routine angelegt, und die Referenze sind dort lokal.
Diesen Form-Routinen übergebe ich die globalen Variablen schon mal in der USING-Anweisung (wohl wissend, dass das nicht unbedingt notwendig wäre, weil man ja noch im Report ist ...). Damit bin ich so "lokal wie möglich" und kann den Absprung in Funktionsbausteine oder OO-Objekte starten!
Viele Grüße
babap
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Naja, zumindest lokale Klassen muss man programmobal deklarieren....
Oder Felder auf die du dich in Select-Options beziehst.
Oder Felder auf die du dich in Select-Options beziehst.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich bin kein Haarspalter, ich lege nur Wert auf Genauigkeit ))
)) Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Vergleichbare Themen
1
Antw.
Antw.
1794
Views
Views
2
Antw.
Antw.
991
Views
Views
SAP Entwicklungssystem und RFC Programmierung
von sNud » 28.08.2021 13:36 • Verfasst in ABAP® für Anfänger
von sNud » 28.08.2021 13:36 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
2180
Views
Views
0
Antw.
Antw.
1306
Views
Views
SAP Workflow Programmierung
von Yeliz92 » 25.01.2018 12:59 • Verfasst in Material Management & Produktionsplanung
von Yeliz92 » 25.01.2018 12:59 • Verfasst in Material Management & Produktionsplanung
0
Antw.
Antw.
1452
Views
Views
Unicodevorgaben bei der Programmierung
von JürgenFFM » 07.11.2007 11:29 • Verfasst in Dialogprogrammierung
von JürgenFFM » 07.11.2007 11:29 • Verfasst in Dialogprogrammierung
Frage die ABAP Experten
Über diesen Beitrag
- zzcpak
- joachim
- cosmo
- crayfish
- Anonymous
- M. Lahr
- babap
- Alpha
- UserBC
- kotelna
- ereglam
- doceX
- ralf.wenzel
- foessleitnerj
- a-dead-trousers
- black_adept
- ewx
- erp-bt
- Pyro
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.