doceX hat geschrieben:doceX hat geschrieben:babap hat geschrieben:Hallo,
meine goldene Regel zu internen Tabellen:
Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.Man "fährt" direkt auf der Tabellenzeile rum und muß sie nicht "modifyen".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' .
Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen
GrußCode: Alles auswählen.
APPEND <lt_tabelle> to LT_TAB2 (ASSIGNING <lt_tab2> "wenn man will").
babap
Ebenfalls auch eine gute Möglichkeit welche kein Modify benötigt sind Referenzen.
Code: Alles auswählen.
DATA: lt_tadir type table of tadir,
Zusatz zum obigen Beitrag *Wurde zu früh gesendetGruss doceXCode: Alles auswählen.
DATA: lt_tadir type table of tadir, lr_tadir type ref to tadir. DATA: l_obj_name type sobj_name. LOOP AT lt_tadir REFERENCE INTO lr_tadir. l_obj_name = lr_tadir->obj_name ENDLOOP.
doceX hat geschrieben:Gruss doceXdoceX hat geschrieben:babap hat geschrieben:Hallo,
meine goldene Regel zu internen Tabellen:
Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.Man "fährt" direkt auf der Tabellenzeile rum und muß sie nicht "modifyen".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' .
Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen
GrußCode: Alles auswählen.
APPEND <lt_tabelle> to LT_TAB2 (ASSIGNING <lt_tab2> "wenn man will").
babap
Ebenfalls auch eine gute Möglichkeit welche kein Modify benötigt sind Referenzen.
Code: Alles auswählen.
DATA: lt_tadir type table of tadir,
Mit welcher Begründung?UserBC hat geschrieben:Meine Regeln:
Regel 1:
Verwende möglichst Klassen und Methoden statt Funktionsgruppen und FuBa's
So halte ich es sogar in FORM-Routinen. Dort arbeite ich NIE mit globalen Feldern, wenn es sich irgendwie vermeiden lässt. Ein Dynpro-Modul besteht bei mir in aller Regel nur aus einem PERFORM mit globalen Felder auf der rufenden Seite.UserBC hat geschrieben:Regel 2:
Manipuliere in einer Methode keine globalen Variablen, sondern nur Aktualparameter.
Sofern das geht. Es gibt Situationen, in denen das einfach nicht möglich ist.UserBC hat geschrieben:Regel 3:
Manipuliere Standardtabellen niemals direkt, sondern immer per Batch-Input.
Naja, beim Appenden finde ich Workareas eingängiger, aber beim Ändern von itabs gebe ich dir recht.UserBC hat geschrieben:Regel 5:
Verwende Feldsymbole statt Workareas, es sei denn du benötigt noch eine Prüfung,
bevor du entscheidest, ob du die Tabelle aus dem Workarea updatest oder
ob du die manipulierten Daten aus dem Workarea verwirft.
Jede globale Regel ist falsch WRITE-Listen haben durchaus ihre Berechtigung, insbesondere aus Performance-Sicht. Auch wenn ich sie nicht sonderlich (genauer: überhaupt ganz und gar nicht) leiden kann.UserBC hat geschrieben:Regel 6:
Verwende nie die Listenausgabe per write, sondern verwende immer eine ALV.
Ich gehe sogar noch weiter in diesem Punkt: Ich lege mir zu jedem im Programm verwendeten Dict-Typ einen darauf referenzierenden Typen im Coding an. DEN verwende ich. Ich hab es mehr als einmal erlebt, dass man im Programm dann doch einen anderen DDIC-Typ nimmt - mit dem Erfolg, dass man x Stellen im Programm ändern muss. Auf diese Weise erzeuge ich mir einen "Single Point of Maintenance", ändere die Deklaration im TOP ein einziges Mal und das zieht sich durchs ganze Programm.UserBC hat geschrieben:Regel 7:
Bezieh dich bei der Variablen-Deklaration immer auf auf eine Dict-Typ,
falls kein passender vorhanden ist; lege einen an und versorge Ihn mit den
entsprechenden Metadaten, Übersetzungen und Dokumentationen.
Da gebe ich dir grundsätzlich recht, nur bin ich da letztens über etwas interessantes gestolpert. Speicherallokierung erfolgt in SAP/ABAP "lazy". Sprich am Beispiel einer großen Tabelle die du per Zuweisung von A auf B "kopierst" wird die Kopie erst dann wirklich durchgeführt wenn sich eine der beiden Variablen ändert.foessleitnerj hat geschrieben:... Speicherbreiche mit FREE freigeben ...
Ich bin Regex-Junkie. Um die Ausdrücke besser warten zu können hab ich mir angewöhnt, sie in kleinere, wiederverwendbare Happen zu zerlegen und dann je nach Anwendungszweck per Concatenate in eine (statische) Variable zusammenzubauen. Somit kann ich anhand der Beschreibung der (Teil-)Ausdrücke auf die Funktionsweise des (neuen) Gesamtausdrucks schließen.foessleitnerj hat geschrieben:... z.B. Regex sind toll, wenn sie komplex werden ist die Wartung selbst für den Ersteller schon eine Wissenschaft. Für eine Regex-Rookie ist dass dann eine Black Box. Als Beispiel bei Regex - wenn ich sie verwende, teile ich diese in ein paar eigene Regex-Calls auf und kommentiere sehr genau was hier passiert. Gleiches gilt für XSLT, Javascript, ...
Vorallem mit deinen Hinweis auf objektorientierte Programmierung (den ich voll und ganz unterstütze) muss ich hier leider deinen Enthusiasmuss etwas bremsen. Ich kommen immer mehr zur Überzeugung, dass man Refernezvariablen einem Feldsymbol vorziehen sollte:foessleitnerj hat geschrieben:FIELD-SYMBOLS verwenden
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
foessleitnerj
Zitat:"Wer testet, ist unsicher"foessleitnerj hat geschrieben:- Open SQL optimal realisieren (niemals SELECT *, dafür Joins, Subselects, Indices, ... )
Eiweh. Es gibt oft genug gute Gründe, select * zu verwenden, zumal bei kleinen Tabellen. Stichwort Tabellenpufferung.
Wie oft wechselt man die Datenbank in einem Unternehmen?foessleitnerj hat geschrieben:- Vorsicht bei FOR ALL ENTRIES, UPDATE/DELETE/INSERT xxx from Table yyyy - Wenn möglich anders lösen - Kann sich je DB unterschiedlich verhalten.
Da kann man sich drüber streiten, was "sprechend" ist. Ich finde "lt_ekko" überhaupt nicht sprechend, weil es mir nur sagt, dass es eine lokale Tabelle mit der Struktur von EKKO ist. Die Deklaration, die damit in den Namen transportiert wird, ist nur einen Doppelklick weit weg und in gescheiten Umgebungen ist ohnehin klar, wo eine Variable sichtbar ist. Bei Feldsymbolen weiß ich oft gar nicht, was da drinstehen wird.foessleitnerj hat geschrieben:- Sprechende Namen verwenden. (ich meine damit lokale Felder, Tabellen, Strukturen, Methoden, Unterprogramme, ... )
Was NICHT in der Deklaration steht und was unter Umständen nur durch eine aufwendige Codeanalyse herauszufinden ist: Was ist denn drin in der lt_ekko? Einkaufsbelege, ok. Anfragen? Angebote? Bestellungen? Normalbestellungen? CC-Bestellungen (die die gleiche Belegart haben, also besonders schwer herauszufinden)? Retourenbestellungen? Bestellungen mit Endlieferkennzeichen?
Ich finde es wichtig, den semantischen Kontext in einem Namen herauszustellen statt der Deklaration - wobei es hier eine Reihe wirklich guter Leute gibt, die anderer Meinung sind.
foessleitnerj hat geschrieben:- Testen, Testen, Testen. (Nichts ist schlimmer als eine Lösung die man der Fachabteilung freigibt, und die beim ersten Aufruf crashed!)
Fazit: Ralf behauptet dass seine Programme trotz wochenlangen Testens unbrauchbar sind.ralf.wenzel hat geschrieben:Ich habe mal mit einer Modulbetreuerin ein Programm wochenlang rauf- und runtergetestet, anschließend sagte sie: "Das ist das wohl am besten getestete Programm, das es auf dem (Kundenname)-System gibt und geben wird". Die erste produktive Buchung ist dann gleich in die Hose gegangen.
Das mit den Referenzen habe ich eigentlich immer noch nicht so richtig verstanden. Es wird zwar immer wieder darauf verwiesen (z.B. in den ABAP Programmierrichtlinien), dass im Rahmen der Objektorientierung Referenzvariablen, anstelle von Feldsymbolen verwendet werden sollen. Aber so den richtigen Vorteil habe ich noch nicht entdeckt irgendwie. Feldsymbole sind ja eigentlich dereferenzierte Referenzvariablen. Das was Du da oben beschreibst, scheint ja eher ein Spezialfall zu sein, oder?a-dead-trousers hat geschrieben: Vorallem mit deinen Hinweis auf objektorientierte Programmierung (den ich voll und ganz unterstütze) muss ich hier leider deinen Enthusiasmuss etwas bremsen. Ich kommen immer mehr zur Überzeugung, dass man Refernezvariablen einem Feldsymbol vorziehen sollte:
- REFERENCE INTO ist annähernd gleich schnell wie ASSIGNING, da nur eine Adresse kopiert werden muss
- FIELD-SYMBOLS lassen sich in Klassen nicht verwenden. Beispiel: Eine Klasse verwaltet eine Menge von Datensätzen in einer internen Tabelle. Ich hätte diese gerne so modularisiert, dass ich eigene Search-Methoden für bestimmte Such-Muster verwenden kann. Das Ergebnis der Methoden ist die gesuchte Zeile in der Tabelle. Aber was ist, wenn ich diese gleich verändern möchte ohne "teure" Kopieraktionen durchführen zu müssen. Was "früher" über (globale) Feldsymbole loker möglich war, ist in Klasse nicht mehr erlaubt. Also bleiben nur die Referenzvariablen übrig. Mir ist schon klar, dass das eigentlich dem objektorientierten Ansatz wiederspricht, daher verwende ich solche Konstrukte auch nur für die interne (private; max. protected) Abwicklung in den Klassen aber nie in public. Das soll auch als Beispiel dienen, wo objektorientiertheit dem optimierten Zugriff auf Ressourcen im Wege steht, aber auch wie man diese Problem, zumindest für interne Verarbeitungen umgehen kann, ohne Codeduplizierung, die man bei FIELD-SYMBOLS in Klassen zwangsläufig machen muss.
Artikel kenne ich da leider keinen.erp-bt hat geschrieben:Das mit den Referenzen habe ich eigentlich immer noch nicht so richtig verstanden. Es wird zwar immer wieder darauf verwiesen (z.B. in den ABAP Programmierrichtlinien), dass im Rahmen der Objektorientierung Referenzvariablen, anstelle von Feldsymbolen verwendet werden sollen. Aber so den richtigen Vorteil habe ich noch nicht entdeckt irgendwie. Feldsymbole sind ja eigentlich dereferenzierte Referenzvariablen. Das was Du da oben beschreibst, scheint ja eher ein Spezialfall zu sein, oder?
Kennst Du da irgendeinen Grundlagenartikel o.ä. der das ganze einem näher bringt. ich habe da nur so eine alte SAP Präsentation, in der aber auch nicht viel mehr steht, als in der Online-Hilfe.
Aber Feldsymbole können doch auch typisiert werden. Dieser Teil der Ausführung sollte also nicht den Ausschlag geben wenn man sich entscheiden will ob man lieber Feldsymbole oder Referenzen verwendet.a-dead-trousers hat geschrieben:...
Referenzen musst du dir (analog wie die Feld-Symbole) wie Zeiger in C/C++ vorstellen mit dem Zusatz, dass diese auch typisiert sein können und somit einen schnellen Zugriff auf die (Teil-)Objekte bieten
...
Ok, ja stimmt... wenn man es so liest...black_adept hat geschrieben:Aber Feldsymbole können doch auch typisiert werden. Dieser Teil der Ausführung sollte also nicht den Ausschlag geben wenn man sich entscheiden will ob man lieber Feldsymbole oder Referenzen verwendet.a-dead-trousers hat geschrieben:...
Referenzen musst du dir (analog wie die Feld-Symbole) wie Zeiger in C/C++ vorstellen mit dem Zusatz, dass diese auch typisiert sein können und somit einen schnellen Zugriff auf die (Teil-)Objekte bieten
...
wenn ich das Coding von SAP-Modulen betrachte, werden dort kaum Referenzen benutzt.eine gute Möglichkeit sind auch Referenzen
Code: Alles auswählen.
Von daher ... meine und die SAP-Empfehlung: Feldsymbole!