Goldene Regeln der Programmierung

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

Re: Re:

Beitrag von doceX (ForumUser / 4 / 0 / 0 ) »
doceX hat geschrieben:
doceX hat geschrieben:
babap hat geschrieben:Hallo,

meine goldene Regel zu internen Tabellen:

Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.

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 "fährt" direkt auf der Tabellenzeile rum und muß sie nicht "modifyen".

Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen

Code: Alles auswählen.

APPEND <lt_tabelle> to LT_TAB2 (ASSIGNING <lt_tab2> "wenn man will").
Gruß
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 gesendet 8)

Code: 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.
Gruss doceX

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


Re: Re:

Beitrag von doceX (ForumUser / 4 / 0 / 0 ) »
doceX hat geschrieben:
doceX hat geschrieben:
babap hat geschrieben:Hallo,

meine goldene Regel zu internen Tabellen:

Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.

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 "fährt" direkt auf der Tabellenzeile rum und muß sie nicht "modifyen".

Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen

Code: Alles auswählen.

APPEND <lt_tabelle> to LT_TAB2 (ASSIGNING <lt_tab2> "wenn man will").
Gruß
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,
Gruss doceX

Re: Goldene Regeln der Programmierung

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
UserBC hat geschrieben:Meine Regeln:
Regel 1:
Verwende möglichst Klassen und Methoden statt Funktionsgruppen und FuBa's
Mit welcher Begründung?
UserBC hat geschrieben:Regel 2:
Manipuliere in einer Methode keine globalen Variablen, sondern nur Aktualparameter.
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 3:
Manipuliere Standardtabellen niemals direkt, sondern immer per Batch-Input.
Sofern das geht. Es gibt Situationen, in denen das einfach nicht möglich ist.
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.
Naja, beim Appenden finde ich Workareas eingängiger, aber beim Ändern von itabs gebe ich dir recht.
UserBC hat geschrieben:Regel 6:
Verwende nie die Listenausgabe per write, sondern verwende immer eine ALV.
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 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.
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.

Es gibt Entwickler, die sind verwirrt, wenn sie sowas sehen ;)

Noch ne Regel: Verwende sprechende / funktionale Konstanten. Ich kann die Programme nicht mehr zählen, in denen ich ein "constants: gc_x = 'X'." gesehen habe, das dann für alles und jedes verwendet wird, wo ein x gebraucht wird. Gruselig. Wenn man parametrisieren will, braucht man für jeden semantischen Zusammenhang eine eigene Konstante.
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Goldene Regeln der Programmierung

Beitrag von foessleitnerj (ForumUser / 51 / 4 / 18 ) »
Hi!

Meine persönlichen prinzipiellen goldenen Regeln:

- Optimale Lösungen realisieren - Optimal was Technologie, Performance, Realisierungsaufwand, Benutzerfreundlichkeit, ... betrifft.
- Immer ein Auge auf die Performance haben (lokal Puffern, DB Zugriffe optimieren, Fieldsymbols, Shared Objects, Speicherbreiche mit FREE freigeben, Paralellisierung andenken, ... )
- Wartungsfreundlich/Lesbar Programmieren (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, ... )
- Moderne Tools, Funktionen verwenden - SAP liefert mit jedem Release neue Funktionen, neue Möglichkeiten aus. - Bei jedem Release gehe ich Schritt für Schritt die Neuerungen (Releasenotes!) durch und hinterfrage was mir Vorteile in der Entwicklung bringt.
-Immer Hinterfragen - Was einmal perfekt war, kann in einer anderen Situation/Umgebung kontraproduktiv sein. Immer die Lösungswege kritisch hinterfragen.

Ansonsten noch ein paar grundsächliche Regeln (die natürlich auch immer begründete Ausnahmen haben können):

- Objektorientiert entwicklen. (Wobei die Anlage von statischen Klassen mit ein paar Methoden für mich noch nicht objektorientiert ist ... )
- Modular entwickeln. (Spagetticode ... )
- FIELD-SYMBOLS verwenden
- Nicht mehr benötigte Objekte, interne Tabellen, .. mit FREE freigeben
- "Abwärtskompatibel" entwickeln. (Neue Methodenparameter so ergänzen, dass bestehende Verwender davon nicht beeinflusst werden)
- Kommentieren, Kommentieren, Kommentieren (Jedoch nur knapp und was zum Verständniss des Codings notwendig ist)
- Native SQL, DB Hints, ADBC nur in begründeten Fällen verwenden (z.B. bei Hana Zugriffen in Side-by-Side, ... )
- Open SQL optimal realisieren (niemals SELECT *, dafür Joins, Subselects, Indices, ... )
- Vorsicht bei FOR ALL ENTRIES, UPDATE/DELETE/INSERT xxx from Table yyyy - Wenn möglich anders lösen - Kann sich je DB unterschiedlich verhalten.
- Sprechende Namen verwenden. (ich meine damit lokale Felder, Tabellen, Strukturen, Methoden, Unterprogramme, ... )
- Testen, Testen, Testen. (Nichts ist schlimmer als eine Lösung die man der Fachabteilung freigibt, und die beim ersten Aufruf crashed!)
- ....

lg Fößleitner Johann
Die Performance und Ergebnisse von SELECTs und JOINs im Produktivsystem überprüfen?
=> SQL Cockpit
http://www.cadaxo.com

Re: Goldene Regeln der Programmierung

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
foessleitnerj hat geschrieben:... Speicherbreiche mit FREE freigeben ...
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.
In meinem Programm hab ich eine riesige Tabelle einem Returning (per Value) Parameter zugewiesen. Und da ich gedacht hab, um Speicher zu sparen, dass es besser wäre den "alten" Speicher zu löschen hab ich das mit FREE auch getan, mit dem unangenehmen Nebeneffekt, dass plötzlich das Programm den doppelten Speicher benötigt hat und mit einem TSV_NEW_PAGE_ALLOCATION_FAILED gedumpt ist.
Versteh mich nicht falsch, grundsätzlich bin ich deiner Meinung, dass mann immer "aufräumen" sollte, nur darf man das nicht zu verallgemeinern.
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, ...
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:FIELD-SYMBOLS verwenden
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.

Beim Rest deiner Ausführungen bin ich zu 100% deiner Meinung. "Das meine ich erst! :P
* Nein! Wirklich!

lg ADT

Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
foessleitnerj

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 ) »
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.
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.
Wie oft wechselt man die Datenbank in einem Unternehmen?
foessleitnerj hat geschrieben:- Sprechende Namen verwenden. (ich meine damit lokale Felder, Tabellen, Strukturen, Methoden, Unterprogramme, ... )
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.

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!)
Zitat:"Wer testet, ist unsicher" ;)

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

Re: Goldene Regeln der Programmierung

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.
Fazit: Ralf behauptet dass seine Programme trotz wochenlangen Testens unbrauchbar sind.Bild

Schönes Wochenende
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Goldene Regeln der Programmierung

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
YMMD
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Goldene Regeln der Programmierung

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Oder sie sind durch wochenlanges Testen unbrauchbar geworden... :o

Re: Goldene Regeln der Programmierung

Beitrag von erp-bt (Specialist / 163 / 4 / 21 ) »
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.
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.

Viele Grüße,
...entwickelnder Berater...beratender Entwickler

Re: Goldene Regeln der Programmierung

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
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.
Artikel kenne ich da leider keinen.
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. Eine große Einschränkung der Feld-Symbole hab ich ja schon aufgezeigt: Sie lassen sich leider nicht global in Klassen, sehrwohl aber lokal in Methoden, verwenden. Aber auch Referenzvariablen haben einen entscheidenden Nachteil: Einige der eingebauten ABAP-Befehle funktionieren nicht mit Referenzen und man muss diese vorher erst wieder einem Feldsymbol zuweisen.

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

email: stefan@schmoecker.de

Re: Goldene Regeln der Programmierung

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
black_adept hat geschrieben:
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
...
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.
Ok, ja stimmt... wenn man es so liest... :oops:
Ich hab ntürlich gemeint, dass sowohl Feldsymbole als Referenzen in ABAP typisiert werden können, im Gegensatz zu Zeigern in C/C++.
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 babap (Expert / 681 / 1 / 1 ) »
Hallo,
eine gute Möglichkeit sind auch Referenzen
wenn ich das Coding von SAP-Modulen betrachte, werden dort kaum Referenzen benutzt.

Ich hatte im letzten Projekt eine Individualanwendung zu betreuen und zu optimieren, da wurden im gleichen Codingabschnitt herkömmliche LOOP - MODIFY Sequenzen, Referenzen und Feldsymbold verwendet ... ein Chaos sondergleichen.

Der Nachteil von Referenzen sind aus meiner Sicht, dass das Coding dem Abap-OO-Coding bei der Benutzen von Objekten und Attributen sehr ähnlich ist (gebraucht wird diese Art der Tabellenbearbeitung nicht wirklich)

Von daher ... meine und die SAP-Empfehlung: Feldsymbole!

Viele Grüße
babap

Re: Goldene Regeln der Programmierung

Beitrag von erp-bt (Specialist / 163 / 4 / 21 ) »
Hi,

Code: Alles auswählen.

Von daher ... meine und die SAP-Empfehlung: Feldsymbole!
Wobei die SAP-Empfehlung, zumindest den offiziellen Programmierrichtlinien nach, etwas differenzierter ist:

Setzen Sie Feldsymbole und Datenreferenzen für den Verwendungszweck ein, der am besten zu ihrer Semantik passt:
o Feldsymbole für Wertezugriffe (Wertesemantik)
o Datenreferenzen für Referenzübergaben (Referenzsemantik)

Wobei die Anmerkung zur Regel wieder etwas schwammig ist:

"Eigentlich fügt sich der Gebrauch von Datenreferenzvariablen besser in Programme ein, die auf ABAP Objects basieren, da sie die gleiche Semantik aufweisen wie Objektreferenzvariablen und so gesehen das modernere Programmierkonzept repräsentieren. Feldsymbole weisen dagegen immer noch einen größeren Funktionsumfang als Datenreferenzen auf und können daher nicht in jedem Fall durch eine solche ersetzt werden. Aus diesem Grund wird der Gebrauch von Feldsymbolen für dynamische Zugriffe auf Datenobjekte weiterhin empfohlen, obwohl aus Gründen der Einheitlichkeit und der Einfachheit eigentlich der alleinige Gebrauch von Datenreferenzen wünschenswert wäre".

In den älteren Modulen findet man naturgemäß Datenreferenzen sehr selten. Schaut man sich aber etwas in den neueren Modulen oder neueren Frameworks um, findet man das dann doch schon häufiger.

Viele Grüße,
...entwickelnder Berater...beratender Entwickler

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 3 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 3 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 3 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