Schreibweise von Membervariablen

Den Typ einer variablen zu erkennen ist meistens nicht das problem. Wenn man sich an die Regel hält das Funktionen nicht größer als 20 Zeilen sein sollten (idr) dann kann man die Variablendefinition meist auf einen Blick sehen auch ohen UN und Intellisense und Co. Wichtiger ist es den SINN der Variablen zu verstehen. Also sowas wie

_ppLPDWsrc

Ist nunmal echt wenig aussagekräftig.

dagegen wäre

sourceBuffer

doch viel schneller als das zu Begreifen was es ist.

Wenn Ihr euch fragt ob euer Codingstyle brauchbar ist... Dann stellt euch einfach mal vor Ihr müssted den Sourcecode am Telefon mit jemand besprechen der ihn gerade nicht sehen kann.

Was glaubt ihr wäre in solch einer Situation leichter zu besprechen?

LPCWSTR pLVWBbn = TTWA2TX(L"Hello There");

oder

wchat_t* textBuffer = CharToWChar("Hello There");

Ich Wette drum das ihr die zweite Zeile NICHT buchstabieren müsst.

In dem Zusammenhang steht auch meine Ablehnung gegen den Unterstrich am Anfang "_buffer". Versucht das mal jemandem Vorzulesen...

Also: Unterstrich buffer plus Unterstrich eingabe = Unterstrich Ausgabe ....

_matze

Was hat die UN mit kryptischen, nichtssagenden Bezeichnern der Marke "_paslöf_kjsö" zu tun?! Es ist einfach falsch, das gleichzusetzen. Sowas mache ich jedenfalls nicht. Du versuchst, deine Position zu stärken, indem du der Gegenpartei einfach Dinge unterstellst...

Hallo

Schau dir mal die WinAPI an: Das soll UN sein und ist verdammt kryptisch. Am meisten stört mich aber, dass eben kein gleiches Verhalten angewandt wird. Basistypen werden benannt, Listen auch, aber eigenen Klassen nicht. Das ist doch Mist.

chrische

_matze schrieb:

Was hat die UN mit kryptischen, nichtssagenden Bezeichnern der Marke "_paslöf_kjsö" zu tun?! Es ist einfach falsch, das gleichzusetzen. Sowas mache ich jedenfalls nicht. Du versuchst, deine Position zu stärken, indem du der Gegenpartei einfach Dinge unterstellst...

Ach, unterstellen... soso..

Dann halt realte Beispiele: Windows SDK V6.1 (Aka, nichts davon in der Liste ist erfunden, alles copy/paste)

g_pGB;
g_pMC;
g_pMP;
g_pME;
g_pMEE;
pFSrc
pCTR
pvi
ddsd
pbS
pbD
d3dlr
pmk

Und das war jetzt nur aus einem kleinen Sourcefile. Jetzt das Ratespiel, wofür steht das?

_matze

Na ja, die ersten paar sind globale Pointer!

Meine Frage gilt weiterhin: was hat die UN mit solch kryptischen Bezeichnern zu tun? Die ist lediglich für den Präfix "g_p" verantwortlich, nicht für das nachstehende Kauderwelsch. Wie gesagt, UN enthebt einen nicht von der Verantwortung, halbwegs aussagekräftige Namen zu vergeben. Deine Beispiele sind Müll, da hast du ganz Recht. Das liegt aber nicht an der UN, sondern an dem anderen Teil des jeweiligen Namens...

F98

Das ist genau das, was ich weiter vorne schon meinte. Ihr führt hier krasse Beispiele auf, um ein simples und funktionierendes Prinzip zu demontieren. Blos weil paar Bremser ihre Variablen nicht richtig benennen können, heißt das noch lange nicht, dass das Prinzip falsch ist. Diese Leute würde auch mit jedem anderen Prinzip ihre Variablen falsch benennen.

asc

F98 schrieb:

Blos weil paar Bremser ihre Variablen nicht richtig benennen können, heißt das noch lange nicht, dass das Prinzip falsch ist.

Ich habe dennoch im Code ein "anzahlEintraege" lieber als ein "iAnzahlEintraege", alleine schon weil ich ersteres ohne im Lesefluss stoppen zu müssen lesen kann. Für letzteres muss ich erst einmal zusätzlich wissen für was das i steht, wirklich Mehrinformationen erhalte ich daraus nicht.
Wie heißt es so schön: "Man liest häufiger Code, als das man ihn schreibt".

Zudem hasse ich es wegen Typänderungen gleich die Bezeichner ändern zu müssen, wenn sie das gleiche machen wie vorher. Beispielsweise wenn ich aufgrund des Wertebereiches eine Anpassung machen muss, ändert dies nichts an der Funktion der Variable.

Zudem: Wir leben in einer Zeit in der die objektorientierte, sowie generische Programmierung, gang und gäbe ist. Spätestens hier kann man keine festen (Meiner Meinung nach: kryptischen) Präfixe mehr einsetzen. Einerseits weil die Typen zunehmen und zum zweiten weil man die Typen teilweise garnicht mehr bestimmen kann.

Wo liegt also der Sinn in diesen Präfixen?

cu André

F98

asc schrieb:

Ich habe dennoch im Code ein "anzahlEintraege" lieber als ein "iAnzahlEintraege", alleine schon weil ich ersteres ohne im Lesefluss stoppen zu müssen lesen kann. Für letzteres muss ich erst einmal zusätzlich wissen für was das i steht, wirklich Mehrinformationen erhalte ich daraus nicht.

Wo ist das Problem, bei einer lokalen Variable den Namen iCount oder iElementCount zu wählen. Global braucht man solche Variablen/Namen sowieso nicht, da Listen (List) eh ihre eigenen Properties namens Count haben.

asc schrieb:

Zudem hasse ich es wegen Typänderungen gleich die Bezeichner ändern zu müssen, wenn sie das gleiche machen wie vorher. Beispielsweise wenn ich aufgrund des Wertebereiches eine Anpassung machen muss, ändert dies nichts an der Funktion der Variable.

Wie oft änderst Du in Deinem Code die Typen aufgrund des Wertebereiches? Das ist doch eher ein Hinweis auf konzeptionelle Mängel und hat nichts mit den Namen an sich zu tun. Außerdem ändert man doch keine Strings in int oder double, sondern bleibt in einer ähnlichen Typkategorie (float/double, int/unsigned int ...).

asc schrieb:

Zudem: Wir leben in einer Zeit in der die objektorientierte, sowie generische Programmierung, gang und gäbe ist. Spätestens hier kann man keine festen (Meiner Meinung nach: kryptischen) Präfixe mehr einsetzen.

Hier stimme ich Dir zu, meine Verfahrensweise habe ich schon paar Einträge vorher erläutert.

asc schrieb:

Einerseits weil die Typen zunehmen und zum zweiten weil man die Typen teilweise garnicht mehr bestimmen kann.

Man muss hierbei sicherlich unterscheiden:

1. Basistypen: int, double ...
2. höhere Basistypen: List ...
3. abstrakte Typen: XMLParser-Klassen, Netzwerk-Klassen ...

Wobei jedes seine Funktion hat und sich nicht alles mit "Objekt o" erledigen lässt und ich dabei u.U. Probleme im Bezug auf den Kontext bekomme.

asc

F98 schrieb:

Wo ist das Problem, bei einer lokalen Variable den Namen iCount oder iElementCount zu wählen. Global braucht man solche Variablen/Namen sowieso nicht, da Listen (List) eh ihre eigenen Properties namens Count haben.

Ich habe hier einfach irgendeinen Bezeichner genommen, mach dich nicht am Count/Anzahl fest. Das gilt unabhängig von der Variable.

F98 schrieb:

asc schrieb:

Zudem hasse ich es wegen Typänderungen gleich die Bezeichner ändern zu müssen, wenn sie das gleiche machen wie vorher. Beispielsweise wenn ich aufgrund des Wertebereiches eine Anpassung machen muss, ändert dies nichts an der Funktion der Variable.

Wie oft änderst Du in Deinem Code die Typen aufgrund des Wertebereiches? Das ist doch eher ein Hinweis auf konzeptionelle Mängel und hat nichts mit den Namen an sich zu tun. Außerdem ändert man doch keine Strings in int oder double, sondern bleibt in einer ähnlichen Typkategorie (float/double, int/unsigned int ...).

"Konzeptionelle Mängel" bekommst du immer wenn ein Kunde nachträglich etwas geändert haben will. Oder wenn man erst nur ein Land betrachtet, und dann wegen Internationalisierung ändere Datentypen verwenden muss. Die Frage ist, ob dies überhaupt unter "Konzeptionelle Mängel" fällt. Es sind Änderungen am Iterativen Softwareentwurf (Nicht jede Software wird in dem Sinne "fertig" das sie beim Kunden läuft, sondern über Jahre hinweg gepflegt und angepasst).

F98 schrieb:

asc schrieb:

Einerseits weil die Typen zunehmen und zum zweiten weil man die Typen teilweise garnicht mehr bestimmen kann.

Man muss hierbei sicherlich unterscheiden:

1. Basistypen: int, double ...
2. höhere Basistypen: List ...
3. abstrakte Typen: XMLParser-Klassen, Netzwerk-Klassen ...

Wieso muss ich hier unterscheiden? Warum Sonderfälle schaffen?
Ich bin ein Fan davon alles was möglich ist, zu vereinheitlichen. Um so weniger Sonderfälle es gibt, um so leichter kommen auch neue Programmierer in einen Projekt klar.

cu André

So, genug über die Ungarische Notation und irgendwelche Präfixe diskutiert. Ich mach hier mal zu.

Thread geschlossen.

Hallo

asc schrieb:

F98 schrieb:

asc schrieb:

Einerseits weil die Typen zunehmen und zum zweiten weil man die Typen teilweise garnicht mehr bestimmen kann.

Man muss hierbei sicherlich unterscheiden:

1. Basistypen: int, double ...
2. höhere Basistypen: List ...
3. abstrakte Typen: XMLParser-Klassen, Netzwerk-Klassen ...

Wieso muss ich hier unterscheiden? Warum Sonderfälle schaffen?
Ich bin ein Fan davon alles was möglich ist, zu vereinheitlichen. Um so weniger Sonderfälle es gibt, um so leichter kommen auch neue Programmierer in einen Projekt klar.

cu André

Genau das ist doch die Kardinalsfrage, um die ihr euch die ganze Zeit drückt? Warum Sonderfälle schaffen?

chrische

F98

Um zu trennen, zu ordnen.

Also wir benennen auf der Arbeit die Membervariablen immer "my_name" und die Paramter einer Funktion "_name"

_matze

Ist auch lustig, wie manche ihre Argumentation immer am gestörten Lesefluss festmachen. Ich sehe das so: wer seinen eigenen Code liest, wird wohl kaum Schwierigkeiten mit den eigenen Präfixen haben. Und bei fremdem Code kann man Präfixe, die man nicht auf Anhieb interpretieren kann, doch einfach ignorieren. Die einzige Voraussetzung sind sprechende Bezeichner, die (wie bereits erwähnt) bei der UN genauso Pflicht sind wie sonst auch. Das ist doch nur eine zusätzliche Möglichkeit, den Typ einer Variable zu erkennen. Wer will, kann den Typ trotzdem anhand des restlichen Namens erahnen oder seine IDE bemühen.

Gerooo

So ma wieder anheizen hier die Diskussion

Meine Taktik (allerdings hauptsächlich C++):

Klassen: KlassenName
Funktionen: verbUndEvtlZusatz()
Funktionsparameter: inVarName / outVarName
Members: m_VarName
Locals: l_VarName
Funktions-Rückgabewert: l_Ret (immer einmalig definiert am Funktionskopf wegen Compiler 1st-Par-Referenz-Optimierung)
Schleifenzähler und sonstige sehr temporäre Variablen: i, j, k, l (ints) / s, s1 (strings) / c, c1 (chars)
Iteratoren: it_WozuGebraucht
Enums: e_Type_Value (z.B: e_Options_ThisOption)
Properties: PropertyName
Globals: g_VarName (kommt aber nie vor, da ich globals grundsätzlich vermeide)
(echte)Konstanten: c_ConstantenName
Defines: DEFINE

Bei Objekt-instanzen hau ich meistens zumindest noch ne Kurzform vom Klassen-Typ in den Namen. Bei simple types bringe ich den Typ nur unter im Variablennamen, falls er besonders relevant ist und nicht durch den Variablen-namen schon klar ist. Wenns um Pointer geht, mach ich das meist auch noch klar im Namen. UN halte ich für überzogen.
Ich finds extrem praktisch, wenn man auf einem Blick sieht, wie die Storage der Variablen ist. Insbesondere in Funktionen, wenn man sofort sieht, ob ne Variable Parameter, Member oder Local ist (und nein, meine Funktionen sind nicht seitenlang). Das an der Gross-/Kleinschreibung vom ersten Buchstaben festzumachen, dauert mir zu lange (man siehts halt nicht auf den allerersten Blick) und die IDE möchte ich dafür auch nicht bemühen (geht auch nicht schnell genug). Der Unterstrich dient mir zur klaren Trennung fürs Auge von Storage und Name.

Der Stil hat sich für mich die letzten 10 Jahre bewährt, und ich hab nie Stress mit Kollegen, obwohl ich mit >50 Codern zusammenarbeite (ganz im Gegenteil, wird regelmässig übernommen der Stil).

Aber letztendlich natürlich jeder so, wie er möchte. Im Team sollte man allerdings schon die Prima-Donna zuhause lassen und sich am restlichen Code orientieren.

jule37

eigentlich ist es ja müßig darüber zu reden, weil eh jeder so seine eigene art hat. ich finde, alles was übersichtlich und selbsterklärend ist prinzipiell gut (ich hasse nichts mehr, als wenn leute ihre variablen aus abkürzungen zusammenfrickeln... man kommt nicht immer dahinter was es sein soll wenn man fremden code liest).

ich finde, die java coding conventions haben da nen guten ansatz geliefert mit klassen groß schreiben und variablen klein (also der anfangsbuchstabe). in c# halte ich es so, dass ich alles was public ist groß und alles was private ist klein schreibe.
aber vielleicht finde ich das auch bloss einleuchtend, weil man mir vorher die java coding conventions eingetrichtert hat.
übrigens: es dauert auf keinen fall länger, an der groß/kleinschreibung was zu erkennen... ist halt immer nur die frage, wie man's gewohnt ist.

gegen die ungarische notation spricht aus meiner sicht auch nichts mehr, obwohl ich schätze, dass dieses konzept wohl schon etwas in die jahre gekommen ist (jede moderne ide zeigt dir per mouseover den typen und owner einer variable an und da microsoft für c# eine kostenlose ide veröffentlicht kann die auch wirklich jeder nutzen).
ich denke mal, die ungarische notation wird mit der zeit nach und nach aussterben. und solange es programmierer gibt wird es unterschiedliche notationsweisen für variablen geben; und streit darum, welche die beste ist.

jule37 schrieb:

gegen die ungarische notation spricht aus meiner sicht auch nichts mehr...

normalerweise finde ungarische notation doof, aber ein 'm_' vor membervariablen ist trotzdem irgendwie praktisch.

~fricky schrieb:

jule37 schrieb:

gegen die ungarische notation spricht aus meiner sicht auch nichts mehr...

normalerweise finde ungarische notation doof, aber ein 'm_' vor membervariablen ist trotzdem irgendwie praktisch.

Und wie schon andere erwähnt haben hat das nichts mit Ungarischer Notation zu tuen, weil hier keine Typinformationen in den Namen codiert werden.

@F98:
bezüglich deines Beispiels auf Seite 4, was machst du mit protected/internal ?

Danke und Gruß

F98

MrCamelcase schrieb:

@F98:
bezüglich deines Beispiels auf Seite 4, was machst du mit protected/internal ?

Danke und Gruß

Es findet von der Nomenklatur her keine Unterscheidung statt, ist im Grunde auch nicht wichtig, anhand eines Variablennamens zu sehen, ob private oder protected. Mir fällt auf die Schnelle kein Gegenbeispiel ein (Ich muss weg.).