Variablendeklarationen - Vor/Nachteile ungarischer Notat
Du hast die Variable lv_uname als numerisch deklariert,
die kann daher keine Buchstaben aufnehmen.
Die Deklaration mit Bezug wäre vorteilhaft, z.B.:
DATA: myname TYPE sy-uname.
Bei mir sähe das so aus:
Aufbereitungsoptionen wie EDIT MASK oder MM/DD/YYYY
sind für Felder mit bekanntem Format nicht nötig.
Wenn du schon eigene Variablen anlegst, dann bitte
am Anfang und vor dem Coding.
Und lass den Unsinn mit dem Prefix a la 'LV_'.
Das führt nur zur Unleserlichkeit.
Es ist für die Lesbarkeit auch von Vorteil wenn man
nur einen Satz pro Zeile schreibt. Komprimierung
in Quellcode ist nicht wirklich nötig
die kann daher keine Buchstaben aufnehmen.
Die Deklaration mit Bezug wäre vorteilhaft, z.B.:
DATA: myname TYPE sy-uname.
Bei mir sähe das so aus:
Code: Alles auswählen.
WRITE: / 'Datum:', sy-datum.
WRITE: / 'Uhrzeit:', sy-uzeit.
WRITE: / 'Benutzer:', sy-uname.sind für Felder mit bekanntem Format nicht nötig.
Wenn du schon eigene Variablen anlegst, dann bitte
am Anfang und vor dem Coding.
Und lass den Unsinn mit dem Prefix a la 'LV_'.
Das führt nur zur Unleserlichkeit.
Es ist für die Lesbarkeit auch von Vorteil wenn man
nur einen Satz pro Zeile schreibt. Komprimierung
in Quellcode ist nicht wirklich nötig
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Ich verweise da einfach mal auf den Link in meiner Signatur zur Ungarischen Notation, in dem sehr deutlich dargestellt ist, warum das ausgemachter Quatsch ist, Sichtbarkeit und Datentyp in den Namen eines Datenobjektes zu schreiben.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Soll das die Grundlage fuer eine Diskussion werden... "ausgemachter Quatsch"?!?!?!ralf.wenzel hat geschrieben:Ich verweise da einfach mal auf den Link in meiner Signatur zur Ungarischen Notation, in dem sehr deutlich dargestellt ist, warum das ausgemachter Quatsch ist, Sichtbarkeit und Datentyp in den Namen eines Datenobjektes zu schreiben.
Nun gut, dann versuche ich mich auf diesem niedrigen Niveaus zu bewgen: Was auf Deiner Seite steht ist Bullshit.
Wir sprechen hier ueber ABAP !!!und ueber Leute die Lesen koennen. Ich will hier nur mal die Parameter abstecken.
Das Prefix erhoeht sicher nicht die Lesbarkeit, fuer einen Legastheniker. Was nicht abwertend sein soll, sondern nur der Klarstellung.
Natuerlich vereinfacht ein Prefix im ABAP die Lesbarkeit, gerade im ABAP. Einem ABAPler brauche ich sicher nicht erklaeren wieso.
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Hi!
Ich hab mir deinen Artikel bzgl. Ungarischer Notation gerade durchgelesen. Grundsätzlich bin ich beim 3. Punkt voll und ganz deiner (und auch der anderen erwähnten Personen) Meinung. Der (genaue) techn. Typ eines Feldes hat im Namen nichts verloren. Die Verwendung ist zehnmal besser.
Was aber die ersten beiden Punkte betrifft, muss ich sagen, dass ich ich das vor Allem in ABAP als durchaus brauchbar erachte:
Wir in unserer Firma haben entschieden alles in englisch zu programmieren. Da ABAP nun sehr viele Schlüsselwörter besitzt aber kein Camel-Case wird es rein nur mit einem Namen ohne irgendwelche Zusätze (lv_, lt_) sehr schwierig im Code zwischen Variablen, Methoden, Befehlen usw. zu unterscheiden (nein, wir haben leider noch kein Eclipse). Einzig in Klassen, da gebe ich dir recht, ist es dank des Zusatzes me-> bzw. <classname>=> sehr leicht den Kontext einer Variable zu erkennen. Nur muss das dann auch, meiner Meinung nach, von der Programmierumgebung forciert werden um ein Vorteil zu sein. Glaub mir ich habs echt versucht meine Kollegen auf die Verwendung von me-> zu drillen, aber manche sind einfach zu faul für vier zus. Zeichen. Da bin ich schon froh, dass wir uns auf ein dreier-Kürzel (gt_, gs_ usw.) einigen konnten.
Was die techn. Info im Variablennamen angeht haben wir uns auf t für Tabellen, s für Strukturen, d für Datenelemente, r für Referenzen und a für Any geeinigt. n, p, i wie du sie in deinem Beispiel erwähnt hast halte ich auch nicht für schlau weil man sich zu sehr einengt. Hingegen wird man wohl eher selten zwischen Tabellen, Strukturen und Referenzen hin- und herwechseln, auch weil der Zugriff darauf so unterschiedlich ist, dass man dann eh alles umbauen muss. Was die "generische" Programmierung hingegen angeht ist es so meines Erachtens sogar besser, wenn man weis, dass z.B. in einen Feldsymbol eine Tabelle erwartet wird. Auch wenn der genaue Typ erst zu Laufzeit bekannt ist.
lg ADT
Ich hab mir deinen Artikel bzgl. Ungarischer Notation gerade durchgelesen. Grundsätzlich bin ich beim 3. Punkt voll und ganz deiner (und auch der anderen erwähnten Personen) Meinung. Der (genaue) techn. Typ eines Feldes hat im Namen nichts verloren. Die Verwendung ist zehnmal besser.
Was aber die ersten beiden Punkte betrifft, muss ich sagen, dass ich ich das vor Allem in ABAP als durchaus brauchbar erachte:
Wir in unserer Firma haben entschieden alles in englisch zu programmieren. Da ABAP nun sehr viele Schlüsselwörter besitzt aber kein Camel-Case wird es rein nur mit einem Namen ohne irgendwelche Zusätze (lv_, lt_) sehr schwierig im Code zwischen Variablen, Methoden, Befehlen usw. zu unterscheiden (nein, wir haben leider noch kein Eclipse). Einzig in Klassen, da gebe ich dir recht, ist es dank des Zusatzes me-> bzw. <classname>=> sehr leicht den Kontext einer Variable zu erkennen. Nur muss das dann auch, meiner Meinung nach, von der Programmierumgebung forciert werden um ein Vorteil zu sein. Glaub mir ich habs echt versucht meine Kollegen auf die Verwendung von me-> zu drillen, aber manche sind einfach zu faul für vier zus. Zeichen. Da bin ich schon froh, dass wir uns auf ein dreier-Kürzel (gt_, gs_ usw.) einigen konnten.
Was die techn. Info im Variablennamen angeht haben wir uns auf t für Tabellen, s für Strukturen, d für Datenelemente, r für Referenzen und a für Any geeinigt. n, p, i wie du sie in deinem Beispiel erwähnt hast halte ich auch nicht für schlau weil man sich zu sehr einengt. Hingegen wird man wohl eher selten zwischen Tabellen, Strukturen und Referenzen hin- und herwechseln, auch weil der Zugriff darauf so unterschiedlich ist, dass man dann eh alles umbauen muss. Was die "generische" Programmierung hingegen angeht ist es so meines Erachtens sogar besser, wenn man weis, dass z.B. in einen Feldsymbol eine Tabelle erwartet wird. Auch wenn der genaue Typ erst zu Laufzeit bekannt ist.
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
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 / 3946 / 201 /
281
)
»
Mein Originalposting zu dem Thema wurde leider versehentlich vom Mod gelöscht, da habe ich mich vorsichtiger ausgedrückt. Leider bringst du kein sachliches Argument, warum (!) die Lesbarkeit verbessert wird. Mein Artikel, auf den ich verweise, ist dagegen voller sachlicher Argumente. Aber den hast du wahrscheinlich nicht gelesen....Unit605 hat geschrieben:Soll das die Grundlage fuer eine Diskussion werden... "ausgemachter Quatsch"?!?!?!ralf.wenzel hat geschrieben:Ich verweise da einfach mal auf den Link in meiner Signatur zur Ungarischen Notation, in dem sehr deutlich dargestellt ist, warum das ausgemachter Quatsch ist, Sichtbarkeit und Datentyp in den Namen eines Datenobjektes zu schreiben.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Was macht ihr denn mit globalen Variablen? Eigentlich sollte man auf globale Felder komplett verzichten. Auch einen Report kann man so schreiben, dass die eigentliche Logik in einer lokalen Klasse steckt, in der verbietet sich die Verwendung globaler Variablen von Haus aus.a-dead-trousers hat geschrieben: Wir in unserer Firma haben entschieden alles in englisch zu programmieren. Da ABAP nun sehr viele Schlüsselwörter besitzt aber kein Camel-Case wird es rein nur mit einem Namen ohne irgendwelche Zusätze (lv_, lt_) sehr schwierig im Code zwischen Variablen, Methoden, Befehlen usw. zu unterscheiden (nein, wir haben leider noch kein Eclipse). Einzig in Klassen, da gebe ich dir recht, ist es dank des Zusatzes me-> bzw. <classname>=> sehr leicht den Kontext einer Variable zu erkennen. Nur muss das dann auch, meiner Meinung nach, von der Programmierumgebung forciert werden um ein Vorteil zu sein. Glaub mir ich habs echt versucht meine Kollegen auf die Verwendung von me-> zu drillen, aber manche sind einfach zu faul für vier zus. Zeichen. Da bin ich schon froh, dass wir uns auf ein dreier-Kürzel (gt_, gs_ usw.) einigen konnten.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
So weit ich mich erinnere, hast Du in Deinem Originalposting auch den Begriff "ausgemachter Quatsch" verwendet. Waere schoen, wenn der Admin das Original noch irgendwo ausgraben kann.
Warum verwendest Du (falls du es vorher wirklicht nicht gemacht hast) jetzt so eine Ausdrucksweise?
Du WILLST doch provozieren. Also wundere Dich dann nicht ueber meine Antwort. Ist doch genau was Du bezweckt hast. Freu Dich doch lieber ueber den Erfolg.
Warum liest Du mein Posting nicht? Dort hab ich doch geschrieben, dass ich einem ABAPLer das nicht erklaeren muss.
Wieso erschwert den ein Prefix die Lesbarkeit eines Programmers? Nur weil Du der Meinung bist und dieses gerne als Fakt sehen willst.
Es ist doch wohl fuer jeden ABAPler einfacher mit P_Datum und/oder S_Datum bei einer Selektion zu arbeiten, als nur mit 'Datum'. Ich hoffe jetzt nicht, dass ich DAS auch noch erklaeren muss.
Und leider(?!?!?!?) ist es gerade im ABAP oft sehr wichtig zu wissen, ob etwas Global oder Local ist, da einige Dinge im ABAP global definiert werden muessen.
Warum verwendest Du (falls du es vorher wirklicht nicht gemacht hast) jetzt so eine Ausdrucksweise?
Du WILLST doch provozieren. Also wundere Dich dann nicht ueber meine Antwort. Ist doch genau was Du bezweckt hast. Freu Dich doch lieber ueber den Erfolg.
Warum liest Du mein Posting nicht? Dort hab ich doch geschrieben, dass ich einem ABAPLer das nicht erklaeren muss.
Wieso erschwert den ein Prefix die Lesbarkeit eines Programmers? Nur weil Du der Meinung bist und dieses gerne als Fakt sehen willst.
Es ist doch wohl fuer jeden ABAPler einfacher mit P_Datum und/oder S_Datum bei einer Selektion zu arbeiten, als nur mit 'Datum'. Ich hoffe jetzt nicht, dass ich DAS auch noch erklaeren muss.
Und leider(?!?!?!?) ist es gerade im ABAP oft sehr wichtig zu wissen, ob etwas Global oder Local ist, da einige Dinge im ABAP global definiert werden muessen.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Das ist doch genau das, was ich sage: P_DATUM und S_DATUM sind absolut nichtssagend. Viel wichtiger ist: Was für ein Datum ist das? Wo wird es verwendet? Wo ist der semantische Bezug. Wenn man (du scheinst ja beim Selektionsbild zu sein) von den acht Zeichen schon zwei für redundante Informationen verschwendet, bleibt nicht mehr viel Platz für wirklich wichtige Informationen.
Und auch an dich die Frage: Warum hampelst du mit globalen Feldern in deinen Programmen herum? Von denen sagt ja sogar die SAP in ihren Programmierrichtlinien, dass man sie nicht verwenden sollte.
Und auch an dich die Frage: Warum hampelst du mit globalen Feldern in deinen Programmen herum? Von denen sagt ja sogar die SAP in ihren Programmierrichtlinien, dass man sie nicht verwenden sollte.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
"Globale" Variablen sehen wir kontext-abhängig. Instanz-Variablen einer Klasse (egal ob lokal in einem Programm oder im Repository) und globale Variablen in einem Programm beginnen mit G. Alles statische beginnt mit S (wir versuchen in Methoden bzw. Form-Routinen keine statische Variablen zu definieren, somit haben sie eigentlich bei uns einen globalen Kontext). Konstanten beginnen mit C.ralf.wenzel hat geschrieben:Was macht ihr denn mit globalen Variablen? Eigentlich sollte man auf globale Felder komplett verzichten. Auch einen Report kann man so schreiben, dass die eigentliche Logik in einer lokalen Klasse steckt, in der verbietet sich die Verwendung globaler Variablen von Haus aus.
So gut die Idee ist, lokale Klassen zu verwenden, so sehr verabscheue ich deren Umsetzung in ABAP. Man muss sie erst wieder in Includes verpacken um halbwegs wiederverwendbaren bzw. übersichtlichen Code zu haben (Nochmal: Kein Eclipse). Nach Möglichkeit lege ich daher schon von Haus aus eine Klasse im Repository an und schreib erst danach das Programm, das den Aufruf bewerkstelligt. Oder im mach gleich eine OO-Transaktion draus.
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 a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Da waren sie wieder: Meine acht Probleme! Sei froh, dass du die Beschränkung nur hier hast (Von Tabellen mit 16 Zeichen mal abgesehen). In IS-H gibt es einige Stellen an denen man techn. mit acht Zeichen auskommen muss (und das bei oft mehr als 100 Felder die man anlegen muss)ralf.wenzel hat geschrieben:Das ist doch genau das, was ich sage: P_DATUM und S_DATUM sind absolut nichtssagend. Viel wichtiger ist: Was für ein Datum ist das? Wo wird es verwendet? Wo ist der semantische Bezug. Wenn man (du scheinst ja beim Selektionsbild zu sein) von den acht Zeichen schon zwei für redundante Informationen verschwendet, bleibt nicht mehr viel Platz für wirklich wichtige Informationen.
Definier mal eine SELECT-OPTION mit Bezug auf ein DDIC-Objektralf.wenzel hat geschrieben:Und auch an dich die Frage: Warum hampelst du mit globalen Feldern in deinen Programmen herum? Von denen sagt ja sogar die SAP in ihren Programmierrichtlinien, dass man sie nicht verwenden sollte.
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 / 3946 / 201 /
281
)
»
Im ABAP verpackt man alles in Includes. Methoden, Klassen, Testklassen. Man sieht sie halt oft nicht. Ich habe kein Problem damit, ein Include für eine lokale Klasse anzulegen (in der Regel sind es sogar zwei, weil ich Definition und Implementation in unterschiedliche Includes schreibe). Abgesehen davon braucht man nicht zwingend ein Include, man kann die Klasse auch einfach in den Report schreiben (was aber, wie du schon sagst, nicht sonderlich übersichtlich ist).a-dead-trousers hat geschrieben:ralf.wenzel hat geschrieben:So gut die Idee ist, lokale Klassen zu verwenden, so sehr verabscheue ich deren Umsetzung in ABAP. Man muss sie erst wieder in Includes verpacken um halbwegs wiederverwendbaren bzw. übersichtlichen Code zu haben (Nochmal: Kein Eclipse). Nach Möglichkeit lege ich daher schon von Haus aus eine Klasse im Repository an und schreib erst danach das Programm, das den Aufruf bewerkstelligt. Oder im mach gleich eine OO-Transaktion draus.
Regel bei mir ist: Was ich nur in diesem einen Programm brauche, lege ich nicht global an. Gerade habe ich einen Fall, wo ich das ändern muss, weil eine Transaktion ein Coding enthält, das ich eigentlich nur einmal brauchte. Dann kam eine zweite Anwendung hinzu und jetzt eine dritte. Daraufhin habe ich gesagt: Dann baue ich das um auf globale Klassen (was ja fast per Mausklick geht), weil ich sonst mehrere Programme in eines codiere und das ist dann wahrlich nicht mehr übersichtlich.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
So weit muss ich gar nicht gehen. Gegeben sei ein Kunden-Namensraum....a-dead-trousers hat geschrieben:Da waren sie wieder: Meine acht Probleme! Sei froh, dass du die Beschränkung nur hier hast (Von Tabellen mit 16 Zeichen mal abgesehen). In IS-H gibt es einige Stellen an denen man techn. mit acht Zeichen auskommen muss (und das bei oft mehr als 100 Felder die man anlegen muss)Definier mal eine SELECT-OPTION mit Bezug auf ein DDIC-Objektralf.wenzel hat geschrieben:Und auch an dich die Frage: Warum hampelst du mit globalen Feldern in deinen Programmen herum? Von denen sagt ja sogar die SAP in ihren Programmierrichtlinien, dass man sie nicht verwenden sollte.
Jedes redundante Zeichen ist ein Zeichen zuviel, gerade wenn dabei wichtige Informationen fehlen. Ich habe kürzlich einem Entwickler ein FORM um die Ohren gehauen der Art:Code: Alles auswählen.
FORM unterprogramm TABLES gt_itab.Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
ralf.wenzel hat geschrieben:Das ist doch genau das, was ich sage: P_DATUM und S_DATUM sind absolut nichtssagend. Viel wichtiger ist: Was für ein Datum ist das? Wo wird es verwendet? Wo ist der semantische Bezug. Wenn man (du scheinst ja beim Selektionsbild zu sein) von den acht Zeichen schon zwei für redundante Informationen verschwendet, bleibt nicht mehr viel Platz für wirklich wichtige Informationen.
Und auch an dich die Frage: Warum hampelst du mit globalen Feldern in deinen Programmen herum? Von denen sagt ja sogar die SAP in ihren Programmierrichtlinien, dass man sie nicht verwenden sollte.
Mir geht es bei P_datum und S_datum lediglich um das Prefix. Ich wollte es noch aendern in P_cccccc und S_cccccc, was ich besser mach gemacht haette.
Dieses, wie Du es nennst "redundante Informationen verschwendet", ist es eben nicht. Im Programm ist ein fuer den Programmierer einen riesen Hilfe wenn er sich an dieses Prefxe haelt.
Natuerlich kann auch jeder Programmieren immer rumscrollen oder auch die Rueckwaertsnavigation nutzen und nachsehen was den nun 'cccccccccc' (Ohne jeden Prefix) denn nun ist, ein Parameter oder Select-option.
Wenn man oefter mal solche Programme anpassen muss, weiss man was man an diesem P_cccccc und S_ccccccc hat.
Den Vorteil diese Ungarischen Notation lernt man doch GERADE im ABAP !!! (bitte nicht vergessen, ABAP!) sehr schnell schaetzen, wenn man Programme anpassen muss, die sich an wirklich NICHTS halten.
Das erste was ich immer mache, ich "Suche' und 'Ersetze" viele der Variablen, damit das Programm ueberhaupt lesbar wird.
Dann ich auch noch mal: ich finde die ganze Diskussion überraschend emotional. Und es stört mich, das getan wird, als ob es die eine Wahrheit gibt.
Jetzt, wo man selber (damit meine ich Daniel und Ralf) für sich zu einer Erkenntnis gekommen ist, sind alle, die was anderes meinen nicht lernfähig, machen Quatsch, arbeiten unsinnig... Was soll das?
Und noch ein paar Anmerkungen zur eigentlichen Diskussion:
Wir haben genug mit komplexen Sachverhalten zu tun. Wieso sollte dann so etwas (oder die Doppeldeutigkeit des Begriffes "global") einen aus der Bahn werfen?
Jetzt, wo man selber (damit meine ich Daniel und Ralf) für sich zu einer Erkenntnis gekommen ist, sind alle, die was anderes meinen nicht lernfähig, machen Quatsch, arbeiten unsinnig... Was soll das?
Und noch ein paar Anmerkungen zur eigentlichen Diskussion:
- Schnell einig sind wir uns anscheinend bei den Typen: auch meiner Ansicht haben die nix im Namen verloren. Nur ist deswegen dieses Beispiel (auch im Heuristika-Text) gerade nicht exemplarisch.
- "Global 1": ja, der Begriff "global" wird unterschiedlich genutzt. Mag verwirrend sein, aber nicht widersprüchlich (da immer auch der Kontext zu berücksichtigen muss).
- "Global 2": "Auf globale Variablen kann man verzichten." Nein. Bei Klassen z.B. für das Singletonpattern nicht. Bei einer Klasse, die ein Log sammelt, ebenfalls nicht. Und es fallen einem sicher auch mehr Beispiele ein. Man sollte die Verwendung möglichst sparsam halten, dass es aber nicht vorkommt, halte ich für ein Gerücht.
- Wie ja auch bei "global" festgestellt, Doppeldeutigkeiten erschweren das Lesen. Und da sind wir doch froh, dass man von Tabellen mit Kopfzeilen weg ist, oder? Und "loop at lt_irgendwas into ls_irgendwas" sorgt dafür, dass auch weiter unten im Coding klar ist, wo was steht.
- "Wenn man auf globale Variablen verzichtet, braucht man das 'l' nicht mehr, ist doch eh alles lokal": Nein, natürlich nicht. Gibt schliesslich auch Parameter. Und mit den häufig genutzten Präfixen "I" "E" "C" "R" sieht man auch im weiteren Codingverlauf, dass die Dinger keine lokalen Variablen sind.
- "Die Unterscheidung nach V, S, T macht im dynamischen Umfeld keinen Sinn": Bitte mal Beispielcoding. Da arbeitet man doch eh häufig mit Referenzen, die dann wieder LR_ o.ä. heissen.
- "Wie soll dass dann bei geschachtelten Tabellen / tiefen Strukturen aussehen?": Nun, die definierst man doch eher im DDIC, oder? Und um Namenskonventionen im DDIC ging es hier nicht.
Wir haben genug mit komplexen Sachverhalten zu tun. Wieso sollte dann so etwas (oder die Doppeldeutigkeit des Begriffes "global") einen aus der Bahn werfen?
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Und wenn schon, häng dich doch nicht an einzelnen Worten auf. Ich bin aus dem Pott, da redet man so: Kurz, knapp, deutlich. Das ist ja kein persönlicher Angriff. manmanman, was ist bloß aus der Diskussionskultur in diesem Land geworden? Ich bin groß geworden zu Zeiten, wo Wehner und Strauß sich blutige Wortgefechte im Bundestag geliefert haben und trotzdem nachher noch ein Bier zusammen getrunken haben.Unit605 hat geschrieben:So weit ich mich erinnere, hast Du in Deinem Originalposting auch den Begriff "ausgemachter Quatsch" verwendet. Waere schoen, wenn der Admin das Original noch irgendwo ausgraben kann.
Doch, mir!Unit605 hat geschrieben:Warum liest Du mein Posting nicht? Dort hab ich doch geschrieben, dass ich einem ABAPLer das nicht erklaeren muss.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Vergleichbare Themen
0
Antw.
Antw.
1206
Views
Views
2
Antw.
Antw.
1286
Views
Views
Unterschiede/Vor-/Nachteile OPEN DATASET vs FB
von gs3rr4 » 15.06.2018 12:27 • Verfasst in ABAP® für Anfänger
von gs3rr4 » 15.06.2018 12:27 • Verfasst in ABAP® für Anfänger
4
Antw.
Antw.
619
Views
Views
Nachteile einer Hash-Tabelle in ABAP
von DerAzubi » 17.10.2022 15:22 • Verfasst in ABAP® für Anfänger
von DerAzubi » 17.10.2022 15:22 • Verfasst in ABAP® für Anfänger
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.