Variablendeklarationen - Vor/Nachteile ungarischer Notat

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

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

Mit Verlaub, aber das ist falsch. Für Klassen gibt es zwei Sichtbarkeitsbereiche: Global (im ganzen System verfügbar) und lokal (in einem Teilbereich des Systems verfügbar). Außer globalen und lokalen Klassen gibt es keine Klassen.

Bei Datenobjekten ist das anders: Es gibt globale Daten (die auf der Datenbank, also im ganzen System verfügbar), es gibt programmlokale Variablen und prozedurlokale Daten. Ich sage: Programmlokale Daten (die hier fälschlich als "globale Daten" bezeichnet werden) sollte man nicht einsetzen (sagt die SAP ja auch), mit globalen Daten kann ich nur arbeiten, wenn ich sie in lokale kopiere (und sei es durch einen SELECT).

black_adept hat geschrieben:Ich habe kein Problem damit dass sich Klassen anders im Namen verhalten als Variablen - es sind halt völlig andere Objekte.

Ich habe großen Respekt vor dir und deinen Kenntnissen, aber jetzt schreibst du Amok: Gerade im OO ist eine Klasse nichts anderes als ein komplexer Datentyp. Darauf beruht das ganze objektorientierte Konzept. In meinen Augen gibt es keine Begründung dafür, dass der eine komplexe Datentyp (nehmen wir eine Tabelle) anders behandelt werden sollte als der andere komplexe Datentyp (eine Klasse).

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

Ich könnte dir zig Anwendungen dafür nennen, wo sowas sinnvoll und absolut nachvollziehbar ist. So weit will ich aber nicht gehen. Das Konzept der Verschattung ist ein gewollter Effekt, den ich auch nutzen können will.

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

Oder wenn man die Verwendung globaler Variablen grundsätzlich verbietet, wie die SAP das tut. Versuche mal in einer Klasse eine globale Variable zu definieren.

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

Und die, die den Quatsch dann tippen müssen

Warum man sich entscheiden sollte? Damit eine gewisse Einheitlichkeit im Coding herrscht und nicht jeder macht, was er will. Das führt dann nur zu "gt_itab" und "lv_datum".

black_adept hat geschrieben: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,

...werfe ich dich aus meinem Projektteam Ohne Witz: Sowas macht man nicht. Um es in C zu formulieren: Setze niemals einen Pointer auf einen Pointer!

black_adept hat geschrieben:Beispiel: Rückgabeparameter der Methode CL_ABAP_STRUCTDESCR->GET_COMPONENTS. Das dauert ein paar Klicks bis man das gefunden hat.

Zwei: Einen auf den Methodennamen und einen auf die Deklaration in der Signatur, die mir oben angezeigt wird.

black_adept hat geschrieben:Und gerade was die Sichtbarkeit angeht. Wenn ich ein Programm bearbeite muss ich immer wieder schauen, wie eine Variable definiert ist (lokal oder global).

Du musst schauen, ob die Variable global oder lokal definiert ist? Dann solltest du nicht mit globalen Feldern arbeiten - das verbietet die SAP nicht ohne Grund, wo sie es kann

black_adept hat geschrieben: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 )

Nein, der Debugger zeigt die Deklaration per Mouseover an. Da musst du *noch* *nichtmal* klicken.

black_adept hat geschrieben:Denn global kann man mit "Suchen/Ersetzen" alles austgauschen und "lokal" muss man nur den Bereich markieren und macht das dann im Editor.

Nein, das ist nicht richtig. Wenn du ein Feld im Typ veränderst, das global einen anderen Namen hat als lokal, stehst du dann vor dem Problem, dass Suchen/Ersetzen nicht mehr geht. Insbesondere: Wenn ich eine FORM Routine habe, die von mehreren Stellen aufgerufen wird, ist der Name in der Formroutine meist allgemeiner als außerhalb.

Beispiel: Ich habe eine Form-Routine zur Konvertierung von Beträgen. Außerhalb der FORM-Routine heißen die Beträge nach ihrem Kontext, innerhalb der Form-Routine habe ich mehrere Kontexte (oder keinen, je nach Betrachtungsweise), dann habe ich einen Namenskonflikt, den ich so lösen kann, dass ich das Feld "betrag" nenne (weil ich ihn nicht gleichzeitig netwr und dmbtr oder wie auch immer nennen kann).

Wenn du den Typ änderst, wirst du mit suchen/ersetzen nicht weit kommen.....

Hinzu kommt: Nehmen wir eine Struktur vom Typ MARA und du machst einen ASSIGN COMPONENT SY-INDEX... ASSIGNING <....>. Wie nennst du ein Feldsymbol, das nacheinander jeden möglichen Typ annehmen kann, wenn du den Typ als Teil des Namens verwenden willst? Wie nennst du ein Datenobjekt bei einer Dereferenzierung, wenn du gar nicht weißt, welchen Typ dieses Datenobjekt hat?

Ich frag mich manchmal echt, wie manche hier programmieren, wenn die nicht jeden Tag auf dieses Problem stoßen....

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

Einer von uns beiden muss zum Deutschkurs: eine semantische Benamung beschreibt den Sinn, den Inhalt. Semantik ist die Bedeutungslehre. Wenn du schreibst "Befürworter von mäßiger semantischer Benamung" und "wobei der Sinn....auch im Namen auftauchen sollte", drückst du dich doppelt aus (weil beides semantisch ist). Sichtbarkeit und Typ sind keine semantischen Attribute, sondern technische.

Aber Hut ab, es gehört schon ein wenig Mut dazu, Leuten wie Horst Keller, der SAP, Linus Thorvalds, Bjarne Stroustrup und Robert Martin zu widersprechen. Aber es gibt ja auch Leute, die behaupten, die Mondlandung der Amis sei ein Fake gewesen.....

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

Ralf hat geschrieben:Bei Datenobjekten ist das anders: Es gibt globale Daten (die auf der Datenbank, also im ganzen System verfügbar), es gibt programmlokale Variablen und prozedurlokale Daten.

Da ich Variablen bisher nur in Programmobjekten benötigt habe, können Variablen ( anders als Daten ) auch nur die zwei Zustände annehmen. Und wenn das Programmobjekt der Bezugspunkt ist, gibt es für diesen Bezugspunkt eben nur noch die zwei Unterscheidungen global und lokal.

Ralf hat geschrieben:

ich hat geschrieben:Ich habe kein Problem damit dass sich Klassen anders im Namen verhalten als Variablen - es sind halt völlig andere Objekte.

Gerade im OO ist eine Klasse nichts anderes als ein komplexer Datentyp. Darauf beruht das ganze objektorientierte Konzept. In meinen Augen gibt es keine Begründung dafür, dass der eine komplexe Datentyp (nehmen wir eine Tabelle) anders behandelt werden sollte als der andere komplexe Datentyp (eine Klasse).

Wieder eine Frage des Bezugspunkts. Wenn ich das SAP-System als Bezugspunkt nehme gibt es keine Variablen, aber (Datenbank)Tabellen, andere DDIC-Beschreibungen und Programmobjekte. Diese dürfen innerhalb des SAP-Systems einer gewissen Konvention unterliegen.
Wenn ich hingegen ein Programmobjekt als Bezugspunkt wähle, gibt es keine (Datenbank)Tabellen mehr sondern nur noch interne Tabellen und alles möglich was ich sonst sonst so in Variablen packen kann. Und hier im Programmobjekt darf eben eine andere Namenskonvetion gelten als zum Bezugspunkt "System".
Klassen die innerhalb eines Programms definiert werden haben aber tatsächlich ein Problem, da hier hier auch klassenglobale Variablen=Attribute haben kann. --> 3 Sichtbarkeiten: Programmglobal, Klassenglobal ( für im Programm definierte Klassen ) und lokal bzgl. der kleinsten Modularisierungseinheit. Und hier trenne ich in meinen Programmen auch dies, indem ich für Attribute den Präfix "m" (für member) verwende um ebendieser Doppeldeutigkeit Herr zu werden.

Ralf hat geschrieben:Ich könnte dir zig Anwendungen dafür nennen, wo sowas sinnvoll und absolut nachvollziehbar ist. So weit will ich aber nicht gehen. Das Konzept der Verschattung ist ein gewollter Effekt, den ich auch nutzen können will.

Cool - ein einziges sinnvolles Beispiel würde mich da schon interessieren.

Ralf hat geschrieben:Oder wenn man die Verwendung globaler Variablen grundsätzlich verbietet, wie die SAP das tut. Versuche mal in einer Klasse eine globale Variable zu definieren.

Das nennt sich da Attribut. Und wenn SAP globale Variablen verbieten würde, hätten Sie ja auch Alternativen vorgesehen um Select-Options oder (für Dynpros sehr hilfreich) TABLES-Definitionen zu ersetzen. Leider habe ich diese bisher nicht gefunden.

Ralf hat geschrieben:Und die, die den Quatsch dann tippen müssen

Quatsch ist keine sinnvolle Diskussionsgrundlage. Period!

Ralf hat geschrieben:Warum man sich entscheiden sollte? Damit eine gewisse Einheitlichkeit im Coding herrscht und nicht jeder macht, was er will.

Da bin ich absolute anderer Meinung! Eine Richtlinie Semantik und Typ und Sichtbarkeit zu verwenden halte ich für sinnvoll.

Ralf hat geschrieben:...werfe ich dich aus meinem Projektteam...Setze niemals einen Pointer auf einen Pointer!

Ich liebe Definitionen wie field-symbols: <ls_itab> like line of lt_itab. oder ls_feldname type Klassenname=>public_Type oder lv_field type type_pool_strukturtyp-feldname. Gerade letzteres könnte bei Strukturen, die geschachtelt mittels Includes definiert wurden schon klickaufwändiger zu finden sein.
Außerdem hat man nicht immer die volle Kontrolle darüber, wie man etwas referenzieren möchte. Wenn ich weiß, dass sich der Datentyp einer Variablen, die ich verwenden soll noch mal ändern könnte, dann referenziere ich halt auf die Variable statt auf ihren Typ und erzeuge damit schon die erste Referenztiefe.
Da werde ich wohl nie in einem deiner Projektteams sein

Ralf hat geschrieben:Du musst schauen, ob die Variable global oder lokal definiert ist? Dann solltest du nicht mit globalen Feldern arbeiten

Wenn ich nur an von mir geschriebenen Eigenentwicklungen arbeiten würde wäre das tatsächlich kaum kein Problem. Aber ich komme rum und darf auch mal anderer Leute Coding anpassen und freue mich, wenn bei denen eine Coderichtlinie die zumindest and HN angeleht ist existiert.

Ralf hat geschrieben:Nein, der Debugger zeigt die Deklaration per Mouseover an. Da musst du *noch* *nichtmal* klicken.

Nur rudimentär: "Structure, flat, ..." oder "Type=C132" aber nicht das Datenelement oder der Strukturname.

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

Ralf hat geschrieben:Nein, das ist nicht richtig. Wenn du ein Feld im Typ veränderst, das global einen anderen Namen hat als lokal, stehst du dann vor dem Problem, dass Suchen/Ersetzen nicht mehr geht. Insbesondere: Wenn ich eine FORM Routine habe, die von mehreren Stellen aufgerufen wird, ist der Name in der Formroutine meist allgemeiner als außerhalb.

Beispiel: Ich habe eine Form-Routine zur Konvertierung von Beträgen. Außerhalb der FORM-Routine heißen die Beträge nach ihrem Kontext, innerhalb der Form-Routine habe ich mehrere Kontexte (oder keinen, je nach Betrachtungsweise), dann habe ich einen Namenskonflikt, den ich so lösen kann, dass ich das Feld "betrag" nenne (weil ich ihn nicht gleichzeitig netwr und dmbtr oder wie auch immer nennen kann).

Wenn du den Typ änderst, wirst du mit suchen/ersetzen nicht weit kommen.....

Huch - ich versuche die ganze Zeit zu verstehen was du mir hiermit sagen willst bzw. wo es ein Problem gibt, welches auf HN zurückzuführen ist. Ich sehe es einfach nicht.

Ralf hat geschrieben:Hinzu kommt: Nehmen wir eine Struktur vom Typ MARA und du machst einen ASSIGN COMPONENT SY-INDEX... ASSIGNING <....>. Wie nennst du ein Feldsymbol, das nacheinander jeden möglichen Typ annehmen kann, wenn du den Typ als Teil des Namens verwenden willst? Wie nennst du ein Datenobjekt bei einer Dereferenzierung, wenn du gar nicht weißt, welchen Typ dieses Datenobjekt hat?

Ich frag mich manchmal echt, wie manche hier programmieren, wenn die nicht jeden Tag auf dieses Problem stoßen....

Dem 1. Teil deiner Aussage kann ich halb zustimmen, wenn eine Richtlinie so etwas nicht abdeckt. Aber ich bin durchaus bereit für ein Feldsymbol welches der Reihe nach Tabellentypen oder elementare Typen aufnehmen kann einen Feldnamen <field> zuzulassen oder <lx_fieldname> wobei das "x" für "unbestimmter Datentyp" steht. Alles nur eine Frage an wie viele Fälle man bei der Richtlinienerstellung gedacht hat.

Den 2. Teil deiner Aussage hingegen empfinde ich schon als abwertend ohne das jetzt näher erläutern zu wollen.

Ralf hat geschrieben:Aber Hut ab, es gehört schon ein wenig Mut dazu, Leuten wie Horst Keller, der SAP, Linus Thorvalds, Bjarne Stroustrup und Robert Martin zu widersprechen. Aber es gibt ja auch Leute, die behaupten, die Mondlandung der Amis sei ein Fake gewesen.....

*sigh*
Lieber Ralf - DAS ist genau die Art von Argumenten, die ich mindestens als arg abwertend dem Angesprochenen ( also in diesem Fall mir) gegenüber ansehe und die eigentlich nichts an neuen Fakten zur Diskussion beitragen aber die Stimmung unnötig aufheizen. Und ich lehne mich jetzt mal aus dem Fenster und behaupte, dass ich nicht der Einzige bin, der das so sieht.

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

black_adept hat geschrieben:Nachtrag - habe folgendes schöne Zitat zu diesem Thema gefunden:

Ultimately, as in the MSDN rating, naming conventions are kind of personal. Pointing out how stupid someone's variable names are is like telling them how stupid they are for naming their first born child "Melvin."

Das sehe ich anders. In einem Auto ist es nicht dem VW-Mitarbeiter am Band überlassen, wie er welches Kabel verlegt. Softwareentwicklung ist ebenso ein industrieller Prozess, an den man industrielle Standards anlegen kann und sollte. Die Zeiten, wo ein Mitarbeiter eines Autoherstellers seine Initialen im Auto hinterließ, sind vorbei. Demnach überlasse ich die Wahl von Variablennamen nicht mehr dem Entwickler, sondern gebe sie vor - in einer Weise, in der ich das für sinnvoll halte (ich = jeder, der das Sagen hat). So wie an einem VW Golf jede Schraube, jede Schweißnaht und jedes Bauteil exakt vorgegeben ist.

Und wenn ich eine Reihe von Gründen UND eine Reihe von kompetenten Menschen habe, die eine bestimmte Richtung weisen, reicht mir das erstmal - zumal dann, wenn sich das mit meinen eigenen Erfahrungen deckt.

Ich bin gelernter Elektroniker, als solcher lernt man, dass Kabel (z. B. in einer Wand) waagerecht oder senkrecht verlegt werden müssen. Klar, das funktioniert nicht besser, als wenn man sie diagonal in die Wand legt, aber es vereinfacht die Wartung. Früher war sowas egal, da hat man versucht, es sich möglichst einfach zu machen und hat sie diagonal durch die Wand gelegt. Wie sehr das die Wartung behindert hat, habe ich am eigenen Leib erlebt.

Tabellen mit Kopfzeilen werden auch von Leuten benutzt, die es sich möglichst einfach machen wollen. Das ist für mich kein Grund, das auch zu tun - ich mach es lieber fachlich richtig (nämlich ohne das Erzeugen zweier gleichnamiger Datenobjekte), auch wenn es minimal mehr Arbeit macht. Dafür bin ich Fachmann auf meinem Gebiet.

Ich habe neulich bei einem Kunden gesagt: Wenn die Geräte, die ihr in eurem Kerngeschäft herstellt, fachmännisch auf dem gleichen Niveau gewartet würden wie euer SAP-System, wäre der Laden hier längst pleite -- weil man dann "eben schnell" mit ein bisschen Isolierband was flickt, statt es fachmännisch korrekt zu machen. Der eine macht das so, der andere so, aber nichts einheitlich.

Und einem Kollegen habe ich neulich gesagt: Wenn du dein Auto in die Werkstatt bringst, willst du auch, dass das gescheit gemacht wird und nicht so, dass der Mechaniker es sich möglichst leicht macht. Sonst kann es sein, dass in der nächsten Kurve die Bremsen nicht richtig funktionieren.

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

Unit605 hat geschrieben:Aepfel und Birnen.....

Ich frag mich, warum in der Elektronik farblich unterschiedliche Kabel benutzt werden. Ist doch auch nur Quatsch.

Nein, überhaupt nicht. Und kein Mensch würde auf die Idee kommen, ein industrielles Produkt herzustellen, ohne festzulegen, welche Ader in welcher Farbe zu legen ist.

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

ralf.wenzel hat geschrieben:

ralf.wenzel hat geschrieben:

Unit605 hat geschrieben:Warum liest Du mein Posting nicht? Dort hab ich doch geschrieben, dass ich einem ABAPLer das nicht erklaeren muss.

Doch, mir!

Ich warte immer noch.....

Du wartest nicht immer noch..... Du provozierst immer noch.

Aber das ist man ja von Dir so gewohnt.... nur Du merkst es nicht.

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

Grosskotzig etwas von "Diskussionskultur" daher labern und selber sich in keinster Weise daran halten.

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

Off Topic:
Was hat eure Antipathie füreinander eigentlich noch mit dem Thema zu tun?
Wenn ich ehrlich bin geht ihr mir beide damit ziemlich auf den Keks!

Zum Thema:

ich kenne auch viele Firmen die Präfixe vorschreiben in ihren Programmierrichtlinien. In unserer firma sind diese Präfixe auch Vorschrift. Und ich finde die persönlich auch ziemlich gut. Für mich erhöht das die Lesbarkeit sogar. Und ob nun mit oder ohne, ist das nicht (wenn es nicht gerade vorgeschrieben ist) immer auch eine persönliche Geschmacksfrage?

Re: Variablendeklarationen - Vor/Nachteile ungarischer Notat

Na dafür habe ich in meiner noch recht kurzen Karriere aber schon ne Menge unterschiedlicher Programmierstile und Namensgebungen gesehen (auch innerhalb eines Betriebs).

Wie gesagt, ich mag die Präfixe und solange kein Kunde von mir verlangt die wegzulassen lass ich die davor!