Variablendeklarationen - Vor/Nachteile ungarischer Notat

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

Unit605 hat geschrieben: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.

Und mein Artikel belegt mit Quellen, dass GERADE bei Programmiersprachen, die mit typisierten und komplexen Variablen arbeiten, davon abgeraten wird.

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

GastX hat geschrieben:

• "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.

Au, jetzt wird es bitter. Muss ich dir den Unterschied zwischen einer globalen Variablen und einem Klassenattribut erklären? Für ein Singleton-Pattern brauche ich ein Klassenattribut, KEINE globale Variable. Ich hab schon ganze Dialogprogramme ohne globale Variablen geschrieben....

GastX hat geschrieben:

• "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.

Bei den Präfixen i_, e_, c_, r handelt es sich um etwas vollkommen anderes, weil keine technische Information, sondern eine semantische Information in den Namen eingebettet wird: Einen Importing-Paramter kann ich nicht überschreiben, einen Exporting-Parameter muss ich initialisieren, wenn ich ein Channing-Feld überschreibe muss mir klar sein, dass das Auswirkungen auf außen hat (auch wenn ich den von außen bekomme).

Wir haben uns gerade beim Kunden geeinigt, dass wir DIESE Präfixe verwenden und ich war nicht dagegen (ich habe es vielmehr vorgeschlagen).

GastX hat geschrieben:

• "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.

[/list][/list]

Nein, ich definiere die meistens im Programm. Zusammengehörige Daten packe ich immer in eine gemeinsame Überstruktur, zum Beispiel beim Ansteuern des Funktionsbausteins MATERIAL_MAINTAIN_DARK: Dafür nehme ich eine Struktur, die als Komponenten AMARA_UEB, AMARC_UEB, ... und AMERRDAT_UEB beinhalten. Vorteil: Ein einziges CLEAR und alles ist weginitialisiert.

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

Unit605 hat geschrieben:Uebrigens, lokale Klassen sind nicht empfohlen, sondern immer im repository anlegen. Soweit ich mich erinnere, ist die Empfehlung von Thomas Jung.

Der schreibt aber nicht die Programmierrichtlinien, sondern Horst Keller. Und Horst Keller ist für mich DIE Kompetenz in Sachen ABAP, immerhin verantwortet er auch die Erweiterung auf ABAP 7.40.... Aber ob lokale oder globale Klasse: Das ändert nichts an meiner Argumentation, dass globale Felder "ihbäh" sind.

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

ralf.wenzel hat geschrieben:

Unit605 hat geschrieben:Uebrigens, lokale Klassen sind nicht empfohlen, sondern immer im repository anlegen. Soweit ich mich erinnere, ist die Empfehlung von Thomas Jung.

Der schreibt aber nicht die Programmierrichtlinien, sondern Horst Keller. Und Horst Keller ist für mich DIE Kompetenz in Sachen ABAP, immerhin verantwortet er auch die Erweiterung auf ABAP 7.40.... Aber ob lokale oder globale Klasse: Das ändert nichts an meiner Argumentation, dass globale Felder "ihbäh" sind.

Da gehen unsere Meinung auch auseinander. Fuer mich ist Thomas Jung DIE Kompetenz in Sachen ABAP. Ich kenne beide, Du auch?

ralf.wenzel hat geschrieben:

Unit605 hat geschrieben:Mit Quellen belegt? Die BILD Zeitung ist auch eine Quelle.....

LOL wir reden hier nicht von BILD, sondern von Bjarne Stroustrup. Der hat ja nur mal eben C++ "erfunden". LOL

Wusstest Du schon, wer hauptsaechliche Saetze mit "lol" anfaengt.

C++.... na und? Was hat das mit ABAP grossartig gemeinsam? Und haben solche Leute grundlegend mit allen Recht, was sie von sich geben? Oder kann/sollte man nicht auch dort differenzieren, oder zumindestens versuchen?

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

ralf.wenzel hat geschrieben:

GastX hat geschrieben:

• "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.

Au, jetzt wird es bitter. Muss ich dir den Unterschied zwischen einer globalen Variablen und einem Klassenattribut erklären? Für ein Singleton-Pattern brauche ich ein Klassenattribut, KEINE globale Variable. Ich hab schon ganze Dialogprogramme ohne globale Variablen geschrieben....

GastX hat geschrieben:

• "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.

Bei den Präfixen i_, e_, c_, r handelt es sich um etwas vollkommen anderes, weil keine technische Information, sondern eine semantische Information in den Namen eingebettet wird: Einen Importing-Paramter kann ich nicht überschreiben, einen Exporting-Parameter muss ich initialisieren, wenn ich ein Channing-Feld überschreibe muss mir klar sein, dass das Auswirkungen auf außen hat (auch wenn ich den von außen bekomme).

Wir haben uns gerade beim Kunden geeinigt, dass wir DIESE Präfixe verwenden und ich war nicht dagegen (ich habe es vielmehr vorgeschlagen).

Damit kann ich leben:
"I" "E" "C" "R" sind für mich genauso wie "G", "S" und "L" also semantische Infomationen.
Ich bennen daher auch Attribute mit "G" wenn sie global für eine Instanz gelten, damit ich weis wenn ich da was ändere, hat das evtl auch Auswirkungen auf andere Methoden (gleich wie bei changing-Parameter). "S" für statisch ist da noch wichtiger zu wissen, weil man damit allen Instanzen einer Klasse etwas verändert. "L" ist nur in Methoden vorhanden und folglich weniger problematisch.
Warum "G" und "L"? Ganz einfach, weil man es so von alten ABAP-Code gewohnt ist.
Aber die Information ist dennoch "semantischer" Natur.

Ich hoffe damit die Wogen in dieser Diskussion ein wenig geglättet zu haben.

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

ralf.wenzel hat geschrieben:Ich habe kürzlich einem Entwickler ein FORM um die Ohren gehauen der Art:

Code: Alles auswählen.

FORM unterprogramm TABLES gt_itab.

Da traf mich fast der Schlag. Eine lokale Tabelle namens gt_..., übergeben per TABLES (also mit Kopfzeile), deren Name "itab" keine Information enthält, nicht typisiert ist (und in der gleichen Anweisung hat er andere itabs per USING übergeben).

Das eigentlich schlimme ist doch: Er muss erst mal die "allgemeinen" Programmierparadigmen einhalten um irgendeine "Notation" verwenden zu können.
Hier entwickeln acht SAPler Inhouse, es gibt keine offizielle Programmierrichtlinie, jeder so wie er mag. Der Skillgrad ist unterschiedlich hoch, kaum OO-Entwicklung und kein Eclips. Ralf würde innerhalb eines Tages wahrscheinlich die meisten Entwickler mehrfach (wegen EG ist mehrfach drin) aus dem Fenster werfen, wenn er mit einem Codereview anfangen würde.

Mir ist es egal, welche "Notation" ein Entwickler verwendet, solange die "Notation" durchgängig verwendet wird. Wenn schon die Sichtbarkeiten mit l_/g_ per Präfix angegeben werden, dann auch sauber und überall richtig.
Variablen müssen sprechend benannt werden, egal ob mit oder ohne Präfix.
Sparsamkeit bei globalen Daten ist auch angebracht, auch wenn ich keine extra Klimmzüge/Aufwand machen würde um noch mehr globale Daten zu vermeiden.

Selber verwende ich die Sichtbarkeit und die Art (t,s,v,r,etc...) im Präfix, zum Teil wegen der Lesbarkeit (mir fällt es leichter), zum Teil wegen der Codevervollständigung (die ersten drei Zeichen grenzen den Vorrat stark ein). Auffällig ist hier, dass bei den Entwicklern, die eine "Notation" verwenden, die Programme insgesamt besser strukturiert und "Programmierparadigmen" strenger eingehalten werden (keine Kopfzeilen, saubere FORM-Signaturen, EVA, etc...).

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

Dele hat geschrieben:

die offiziellen SAP-Programmierrichtlinien

Von Ralf ziemlich sicher nicht als Scherz gemeint.

Was ist daran witzig?

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

Mist: Jetzt wollte ich auf Ralfs Signaturartikel eingehen, aber da hat dieses Theman schon zig Beiträge.

Trotzdem auch noch mal meine Anmerkungen - insbesondere zu Ralfs Signatur, denn ich bin auch einer der Kandidaten, die gerne diverse Präfixe in ihrem Programmen verwenden.

Ralf begründet seine Ablehnung hauptsächlich durch:

Sichtbarkeits- oder Typinformationen behindern den Lesefluss - Sinninformationen wären besser

Wie auch einige Vorposter finde ich nicht, dass ein Präfix den Lesefluss behindert. Wenn man sich daran gewöhnt hat - und ich gehe davon aus, dass das jeder Programmierer irgendwann tut - lassen sich Präfixverseuchte Quelltexte ähnlich gut lesen wie solche ohne Präfixe. Ist ähnlich wie deutsche Texte, die durchgängig klein geschrieben werden. Ist zunächst etwas gewöhungsbedürftig aber nach kurzer Zeit geht es.
Und dass Sinninformationen in einen Variablennamen gehören halte ich für absolut bestätigenswert. Aber ich sehe nicht, dass das Eine das Andere ausschließt. In Ralfs "lt_ekko"-Beispiel wäre für mich als "lt_ekko_intercompany" ein akzeptabler Variablenname

Ob eine Variable lokal/global ist ist kontextabhängig

Ich betrachte eine Variable tatsächlich kontextabhängig. Und zwar immer auf das Coding bezogen welches ich gerade am Wickel habe. Es wird argumentiert, dass Klassendefinitionen ( systemglobal, Programmglobal ) anders sind als Variablendefinitionen und dass diese sich gleich verhalten sollten. Da hat er ja nicht unrecht - aber für Klassen gibt es eben genau diese zwei Sichtbarkeitsbereiche wohingegen es für Variablen auch zwei Sichtbarkeitsbereiche gibt, die sich aber einfach anders verhalten. Einerseits haben wir das Rahmenprogramm und andererseits die im Rahmenprogramm angesiedelten Modularisierungseinheiten wie Methoden, Forms...
Ich habe kein Problem damit dass sich Klassen anders im Namen verhalten als Variablen - es sind halt völlig andere Objekte.

Eine lokale Variable kann keine globale Variable verschatten ( was als Nachteil ausgelegt wird ) wenn man den Sichtbarkeitsbereich in den Variablennamen packt

Hier nur ganz kurz - ich finde Verschattung eher problematisch und sehe es dementsprechend nachteilig, wenn ich eine globale Variable durch eine lokale verschattet wird und da kommt mir eine Trennung von lokal/global nur zu recht, da hierdurch eine Verschattung durch die Namenswahl implizit vermieden wird.

Wenn alle lokalen Variablen einer Methode mit l_ beginnen kann man das auch weglassen

Dieses Argument zieht nur, wenn man eine Richtilinie hat, die besagt, dass alle globalen Variablen gekennzeichnet werden müssen. Aber dann geht man ja schon von einer bedingten Namensgebung aus, die ja angeblich vermieden werden sollte.

Struktur, Tabelle oder elementares Feld - Probleme bei untypisierten Variablen

Das ist tatsächlich eins der Argumente, die ich am Besten nachvollziehen kann. Für untypisierte Variablen bzw. solche, die variabel diverse Typen annehmen können muss eine solche Namensgebung natürlich versagen. Aber der Schluss "Weil wir nicht für alles eine sinnvolle Namenskonvention vorgeben können machen wir lieber gar keine Namenskonvention" ist für mich nicht der einzig mögliche. Ich bevorzuge "Weil wir nicht für alles eine sinnvolle Namenskonvention vorgeben können machen wir es dort, wo es geht"

Technische Informationen ( EKKO ) soll nicht in den Variablennamen, da redundant sondern lieber die Verwendung/Inhalt/Zweck der Variablen

Auch hier kann ich mich mit Exklusivitätsprinzip nicht anschließen. Warum soll man sich entscheiden ob man Sinn- oder Typ- oder Sichtbarkeits oder sonst irgend welche Informationen in den Variablennamen wirft. In meinen Augen ist ein "lt_ekko_offene_bestellungen" aussagekräftiger als ein "offene_bestellungen" oder ein "lt_ekko". Die Verfechter fast jeder Namenskonvention können sich hier wiederfinden - lediglich die Lesbarkeitsverfechter werden das nicht so toll finden.

Man kann leicht zur Definition einer Variablen navigieren - daher sind Sichtbarkeits- als auch technische Informationen so dicht dabei, dass man sie nicht in den Namen packen muss

In der Theorie ist das ja schön und gut. Aber wenn ich eine Variable habe, die ich mit Bezug auf eine andere Variable definiert habe, welche wieder mit Bezug auf eine weitere definiert wurde etc, kann das manchmal schon etwas ausarten. Beispiel: Rückgabeparameter der Methode CL_ABAP_STRUCTDESCR->GET_COMPONENTS. Das dauert ein paar Klicks bis man das gefunden hat. Und gerade was die Sichtbarkeit angeht. Wenn ich ein Programm bearbeite muss ich immer wieder schauen, wie eine Variable definiert ist (lokal oder global). Natürlich könnte ich jetzt jedes mal doppelklick drauf machen um zur Aufrufstelle zu navigieren - aber wenn ich auf einen Blick sehe, dass es sich hier um eine lokale Variable handelt spart mir das wieder Arbeit bzw. beim Debuggen ( wo ich den Doppelklick nicht machen kann ) weiß ich dann wo ich eine falsche Befüllung zu suchen habe.

Problemen beim Ändern des Datentyps ( gilt dann wohl auch für Änderung des Sichtbarkeitsbereichs )

Wenn man lokal und global sauber trennt ergibt sich das Problem kaum noch. Denn global kann man mit "Suchen/Ersetzen" alles austgauschen und "lokal" muss man nur den Bereich markieren und macht das dann im Editor. Oder - wenn man schon mit Eclipse arbeitet - ist das sowieso kein Problem mehr - hier hat SAP echt mal was verbessert.


Fazit: Ich bin großer Befürworter von mäßiger (semantischer) Benamung von Variablen was Sichtbarkeit und Typ angeht, wobei der Sinn einer Variablen explizit auch im Namen auftauchen sollte.