Goldene Regeln der Programmierung

Hinweise, Tips und Tricks, FAQs - keine Anfragen!!
50 Beiträge • Vorherige Seite 3 von 4 (current) Nächste
50 Beiträge Vorherige Seite 3 von 4 (current) Nächste

Re:

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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'
.
In ABAP 7.40:

Code: Alles auswählen.

data: tab type irgendeine Tabelle

loop at tab assigning field-symbol(<tabline>).
bzw.

Code: Alles auswählen.

read table tab with (table) key ... assigning field-symbol(<tabline>).
etc.

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 :-/
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Goldene Regeln der Programmierung

Beitrag von babap (Expert / 681 / 1 / 1 ) »
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

Re: Goldene Regeln der Programmierung

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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.
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Goldene Regeln der Programmierung

Beitrag von babap (Expert / 681 / 1 / 1 ) »
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

Re: Goldene Regeln der Programmierung

Beitrag von Pyro (Specialist / 121 / 14 / 18 ) »
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 ...
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?

Re: Goldene Regeln der Programmierung

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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 ;)
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Goldene Regeln der Programmierung

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
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?
Eine Möglichkeit wären PUPLIC-Variablen einer Klasse (statisch) oder eines Objektes.
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.
ralf.wenzel hat geschrieben:Mit dem Bus Screen Framework.
Was das BUS hier anders macht würde mich interessieren.
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

Re: Goldene Regeln der Programmierung

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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.
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Goldene Regeln der Programmierung

Beitrag von babap (Expert / 681 / 1 / 1 ) »
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

Re: Goldene Regeln der Programmierung

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Goldene Regeln der Programmierung

Beitrag von babap (Expert / 681 / 1 / 1 ) »
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

Re: Goldene Regeln der Programmierung

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Naja, zumindest lokale Klassen muss man programmobal deklarieren....

Oder Felder auf die du dich in Select-Options beziehst.
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Goldene Regeln der Programmierung

Beitrag von babap (Expert / 681 / 1 / 1 ) »
Ist klar ;-)
... wie gesagt, diese Haarspalterei bringt nichts ...

Re: Goldene Regeln der Programmierung

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Ich bin kein Haarspalter, ich lege nur Wert auf Genauigkeit ;)))
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Goldene Regeln der Programmierung

Beitrag von babap (Expert / 681 / 1 / 1 ) »
Noch eine goldene Regel von mir:

Ich definiere alle Klassen im Data Dictionary.

Sie sind viel einfacher zu pflegen und zu dokumentieren, und, der größte Vorteil, sie lassen sich einfach testen!

Gruß
babap

Vergleichbare Themen

1
Antw.
1645
Views
Regeln für automatischen Ausgleich
von Buetzy » 06.08.2008 11:10 • Verfasst in Financials
2
Antw.
516
Views
SAP Entwicklungssystem und RFC Programmierung
von sNud » 28.08.2021 13:36 • Verfasst in ABAP® für Anfänger
1
Antw.
2032
Views
GUI Programmierung: Dynpro?
von fabis » 01.03.2012 20:35 • Verfasst in ABAP® für Anfänger
0
Antw.
1169
Views
0
Antw.
1296
Views
Unicodevorgaben bei der Programmierung
von JürgenFFM » 07.11.2007 11:29 • Verfasst in Dialogprogrammierung

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140