Wie nennt ihr eure Variablen?

[Matze]

Hallo zusammen,

ich wollte mal fragen, nach welchem Muster ihr eure Variablen benennt. Benutzt ihr die ungarische Notation von Charles Simonyi oder die entschärfte Version "Systems Hungarian" oder gar etwas völlig anderes. Habe gerade den Wikipedia Artikel zur ungarischen Notation gelesen und festgestellt, dass ich das ganze ziemlich kryptisch finde. Obendrein kann sich doch kein Schwein die ganzen Abkürzungskombinationen aus Präfix und Datentyp merken. Ich müsste mir jedenfalls immer ein Cheat-Sheet neben die Tastatur legen. Die einfachere "Systems Hungarian" finde ich schon besser, allerdings scheint die auch mittlerweile wieder veraltet zu sein. Zumindest steht im Artikel auch das hier:

Die Ungarische Notation sei besonders vorteilhaft für nicht streng-typisierte Sprachen wie C, für die sie ursprünglich entwickelt wurde. Für moderne, objektorientierte Hochsprachen wie Java oder C# ist sie nicht mehr von so großer Bedeutung. Microsoft empfiehlt für das neue .NET-Framework, die ungarische Notation nicht mehr einzusetzen.

Interessant wäre auch, wie sich eure Notation bei großen Projekten bewährt hat, d.h. ob ihr euch am Ende gedacht habt: "Hätte ich's mal doch nach einem anderen Schema gemacht!" oder ob ihr zufrieden (gewesen) seid.

Und wo wir grad dabei sind: Wie sieht mit Methoden, Klassen, etc. aus? Camel-Case? Vorne immer groß?

Bin gespannt auf eure Antworten!

Beste Grüße,
Matze

[Helmut]

Also ich habe die ungarische Notation noch nie benutzt und vermisse sie auch nicht. Früher habe ich nur g für globale Variablen, p für Pointer und I für Interfaces benutzt, damit aber inzwischen auch aufgehört. Ohne ist es einfach wesentlich bequemer.

[Krishty]

Ich benutze bei Variablen ausschließlich Camel-Case mit Präfixen für den Gültigkeitsbereich (g_ für global, l_ für lokal, m_ für Member, p_ für Parameter, t_ für Template-Parameter). Bei Klassen dasselbe (nur mit C für Klassen, TC für Template-Klassen, I für reine Schnittstellen usw), bei Funktionen nichts. So weit, die Präfixe wegzulassen, gehe ich nicht – dann kollidieren nämlich ständig die Namen von Funktionen, Klassen und Variablen.

Ich schreibe die Namen immer komplett aus, weil lange Namen imho mit Auto-Vervollständigung kein Problem sind. Sind sie richtig gewählt, wird auch die Lesbarkeit nicht negativ beeinflusst, imo sogar eher positiv (das kann aber auch meine Gewohnheit sein). Sehr kurze Variablennamen oder Dummies (á la „foo“, „i“ oder „x“) benutze ich niemals, weil ich überzeugt bin, dass man mit nichts umgehen kann, das man nicht auch präzise zu benennen weiß.

Ich mache das nun seit vielen tausend Code-Zeilen so und bin vollends zufrieden. Früher, als ich nach Zerbies Büchern gearbeitet habe, war der Stil noch ein anderer – aber das habe ich mir zum Glück abgewöhnt ;)

Gruß, Ky

[Schrompf]

Privat sieht's bei uns im Code genauso aus wie bei Krishty - ein Präfix für den Scope, sonst nix. Nur dass wir uns noch den Unterstrich ersparen und danach im Camel Case weitermachen - mIstWichtig als Membervar, pAnzTassen als Parameter, gDingensVerwaltung als globales Objekt. Namespaces und Klassen sind Substantive mit Kamelsilhouette - Zeuch::DingensVerwaltung als Beispiel. Interfaces heißen meist was mit "Basis" im Namen, aber so genau ist das nicht festgelegt. Funktionen sind Verben bzw. Sätze im Imperativ, ebenso kamelig - TuWas() oder StarteAufgabe() oder sowas. Lokale Vars beginnen immer klein, kamelen dann aber auch weiter.

Ich hatte ja schonmal die Doxygen-Doku unseres Projekts hochgeladen - da sah man das ganz gut. Ich mag's so.

Hier auf Arbeit dagegen wird die ungarische Notation durchgedrückt... inzwischen selbst bei Funktionsnamen, um den Rückgabewert der Funktion anzudeuten. Ich krieg echt einen Hass. Die StyleGuide-Fetischisten hier rennen einem hinterher, wenn sie eine formlos benannte lokale Variable im Code entdecken, aber gleichzeitig darf ich die Bedeutung von zentralen System-Enums anhand von SlickEdits Cross Referencing erraten. Völlig verpeilte Prioritäten. Aber was erwarte ich von einer Firma, der festgelegte Arbeitszeiten und adrettes Aussehen wichtiger sind als die Fähigkeiten der Mitarbeiter.

*frust*

[kimmi]

Die ungarische Notation ist ein sehr effektiver Weg, Leute komplett zu verwirren. Bei C mit Win32-API hats noch Sinn gemacht, um seinen Code ( der besagte Notation nicht eingesetzt hat ) vom Rest zu unterscheiden. Ich habe das vor Urzeiten mal probiert, dann aber wieder sein gelassen, da ich irgendwann vor lauter Prefix den Sinn der Variable nicht mehr verstanden hatte.
Im Büro und Privat hat sich folgendes durchgesetzt:

Code: Alles auswählen

m_   -> Attribute von Klassen
s_    -> Statische 
g_    -> Globale Variable
 p     -> Pointer auf irgendwas
pp    -> Pointer auf Pointer auf irgendwas

Dabei habe ich mir den Underline für Attribute, statisch und global angewöhnt, ohne geht das natürlich auch. Damit sollen auch nur nicht lokale oder Variablen, mit denen man vorsichtig umgehen muss ( Pointer halt ), explizit hervorgehoben werden.
Viel wichtiger also die Benennung ist IMHO eher, daß wenn man sich auf so etwas einigt, diese im Projekt von allen Mitgliedern des Teams durchgehalten wird, damit die Leute nicht ständig umdenken müssen oder Diskussionen über richtig oder falsch einem von der wirklichen Arbeit abhalten. Das stellen wir per Code-Readings sicher. Aber dort geht es natürlich in erster Linie um die Qualität, wir sind hier nicht päpstlicher als der Papst :).
Und hier laufen alle rum wie Hulle, ich komme mich machmal schon echt overdresst vor ;).

Aber was erwarte ich von einer Firma, der festgelegte Arbeitszeiten und adrettes Aussehen wichtiger sind als die Fähigkeiten der Mitarbeiter.

Musst du um 8:00 Uhr morgens etwa da erscheinen?

Gruß Kimmi

[Schrompf]

Aber was erwarte ich von einer Firma, der festgelegte Arbeitszeiten und adrettes Aussehen wichtiger sind als die Fähigkeiten der Mitarbeiter.

Musst du um 8:00 Uhr morgens etwa da erscheinen?

Exakt. Das Ergebnis ist ein Thomas, permanent müde, permanent sauer, bei An- und Abreise immer zwangsweise im Stau stehend.

Wenn ich mal groß bin, such ich mir nen richtigen Job.

[kimmi]

Das ist ja ein Witz! Wer denkt sich so einen Tünneff aus?!

Gruß Kimmi

[Lord Delvin]

für alles, was ich außerhalb des lokalen scopes verwende gibts richtige sprechende englische Namen mit camelCase. Für lokale Sachen kommts sehr drauf an wie schnell ich den code geschrieben haben will und wie kompliziert der ist. Generell werden die Namen besser und Länger, je komplexer der Code wird. Präfixe verwende ich überhaupt nicht. Ich verwende den globalen namespace aber auch nicht selbst, was scope präfixe sehr sinnlos macht. Ich find präfixe irgendwie unleserlich und es verleitet dazu namen mehrmals zu vergeben; das Problem hat man bei steigender Projektgröße mit namespaces auch, aber da kann man ja einfach auf das using verzichten um die namen sinnvoll zu unterscheiden.
Mir wäre oft auch unklar, was der Typ eines Objekts sein soll, das von nicht streng typisierten Spracheigenschaften gebrauch macht. Ich mein sowas wie ein nullobjekt über cast operator/konstruktor zu realisieren find ich schon ganz nett, aber solange man sowas nicht macht ist der typ von irgendwas immer ziemlich eindeutig. Und von int breiten Gebrauch zu machen halte ich nicht so besonders viel, allerdings muss man sagen, dass ich für nen C++ Entwickler arg wenig systemnahes Zeug schreibe.

Interessant finde ich nur, dass jedes mal wenn die Diskussion aufkommt weniger Leute Präfixe verwenden, früher ist man ja direkt für verrückt gehalten worden, wenn man behauptet hat, dass ungarische Notation unproduktiv ist
O tempora, o mores:D
Gruß

[kimmi]

Man wird halt schlauer. Als ich die ungarische Notation noch intensiv benutzt habe, waren meine Methoden recht groß, die Variablendeklaration war oft weit weg von der wirklichen Referenzierung. Somit konnte man schneller die Übersicht verlieren. Das Problem, die Komplexität durch komplexere, wenn auch selbsterklärende Variablennamen zu bekämpfen, war halt an der falschen Ecke angesetzt. Ich gehe nun lieber prinzipiell gegen zu komplexe Methoden vor, das funktioniert besser als Namen wie lppuiA.
Die ungarische Notation ist ursprünglich für den C-Code von Windows entworfen worden. Da hat man halt nicht die Möglichkeiten, die einem ein einigermaßen moderner C++ Compiler anbietet. Zum Beispiel müssen die Variablen am Anfang deklariert werden.

Gruß Kimmi

[Zudomon]

Ich verwende immer Namen, die mir gerade passen. Da verpflichte ich mich keinerlei Standards sondern es ist eher intuitiv und Situationsbedingt. Lokale Variablen können ruhig sehr kurz und kryptisch sein, hauptsache es bläht den Code nicht unnötig auf. Der sollte für mich nämlich kurz und übersichtlich sein. Auch Kommentare sollten die Übersicht nicht unnötig behindern, also lieber drauf verzichten. Vielleicht werde ich es irgendwann mal schaffen in meinem ganzen Projekt mich zumindest an meinen eigenen Standards zu halten. Es kann auch oft vorkommen, dass die Namen von der groß und klein Schreibung her variieren, da Delphi ja nicht case sensitive ist. Naja, die Hauptsache ist für mich, dass es funktioniert und schnell dahin programmiert ist. Wenn man es dann noch nach ein paar Monaten lesen kann ist das ja schon Luxus. :D

Gruß Zudo

[Chromanoid]

Ich persönlich halte - seit dem ich Java programmiere - die Sun Java Notation für die beste und den heutigen IDEs angemessenste Notation.

http://java.sun.com/docs/codeconv/html/ ... 8.html#367
bzw.
http://java.sun.com/docs/codeconv/html/ ... C.doc.html

(Höckerschreibweise bei allem außer Konstanten; Klassen und Interfaces großer Anfangsbuchstabe; Variablen kleiner Anfangsbuchstabe; Konstanten alles groß geschrieben)

Variablen nenne ich daher oft genauso wie die Klasse nur mit kleinem Anfangsbuchstaben statt großem. Dank Syntax-Highlighting und dem kleinen Anfangsbuchstaben ist das sehr gut von den Klassen unterscheidbar. Variablen die Basistypen sind (String, int, double usw.) nenne ich meistens so wie das was sie sind. Bspw. int zeilenNum oder String textline etc... Da ich mit Netbeans oder Eclipse programmiere überlasse ich die Benamung meistens sowieso der IDE. Netbeans macht da immer sehr vernünftige Vorschläge... Ich drück also meistens einfach nur CTRL+SPACE und habe einen Namen (in Netbeans für Java).

Auf Bald
Chromanoid

[Aramis]

Feind aller Präfixe. Globale Variablen habe ich nicht. Wenn doch, haben sie auch kein Prefix. Lokale Variablen benenne ich so kurz wie möglich, zuweilen nur alphabetisch. Wieso auch anders? Wenn eine Methode/Funktion so lang ist, dass man um den Quellcode noch lesen und verstehen zu können ellenlange und selbsterklärende Variablennamen braucht, ist sie zu lang :-) Kamele für Methoden und Klassen-Namen, außer bei Zeugs das eher in den Bereich 'Utilities, Datenstrukturen, könnte auch in boost oder der STL enthalten sein' fällt - da mag ich kleingeschrieben mit vielen kleinen Unterstrichen.

Namenskonventionen sind sinnvoll, aber kein Allheilmittel für gute Softwarequalität. Zu stur angewandt imho schädlich.

[Krishty]

(Höckerschreibweise bei allem außer Konstanten; Klassen und Interfaces großer Anfangsbuchstabe; Variablen kleiner Anfangsbuchstabe; Konstanten alles groß geschrieben)

Ich habe nie verstanden, warum Konstanten komplett groß geschrieben werden. Aus Sicht einer Funktion sollte es doch keinen Unterschied machen, ob man mit einer Variablen arbeitet oder mit einer Konstanten. Oder werden da die Namen aller Werte, die nach ihrer Initialisierung nicht mehr geändert werden können (also auch nicht-static), groß geschrieben?

[Lord Delvin]

Zumal Funktionen ja sowieso möglichst seiteneffecktfrei sein sollten und dann aus Sicht der Funktion alles Konstanten sind.

[kimmi]

Zumal Funktionen ja sowieso möglichst seiteneffecktfrei sein sollten und dann aus Sicht der Funktion alles Konstanten sind.

Theoretisch funktioniert auch der Kommunismus ;). Leider halten das nicht alle durch :(.

Der Java-Konvention kann ich in großen Teilen zustimmen, wobei ich konstante Ausdrücke in C/C++ meist mit einem Großbuchstaben beginne, den Rest dann klein schreibe. Damit will ich Konflikte mit Präprozessordirektiven vermeiden.

Gruß Kimmi

[odenter]

Privat und im Beruf CamelCase underscore.

Private:
- Methoden beginnen klein
- Variablen beginnen mit einem Unterstrich

Public:
- Alles wird groß geschrieben

Protected:
- Alles wird groß geschrieben

Ausserdem sind Abkürzungen zu vermeiden und Methoden und Variablen immer auszuschreiben.
Ungarische Notation gefällt mir überhaupt nicht, in einer Script-Sprache in der es nur einen Variant-Typ gibt, mag die Sinnvoll sein, wobei ich da auch nur eine extrem abgeschwächte Form benutze.

Also "c" für Strings, "n" für numerische Werte und "o" für belibige Objekte.

[Dirk Schulz]

Hi,

ich schreibe Variablen immer ohne Präfix, wenn dochmal zwei Variablen gleich heißen sollten, kann man sie mit this-> kenntlich machen.

Eigentlich ist die Java-Konvention sehr schön, kann aber auch leider nur in Java auch genutzt werden.

In C++ stören da die SDK's oder Third-Party-Libs sehr finde ich.

Beispiel:
ich schreibe in C++ einen Map-Editor der wxWidgets und DirectX nutzt, beide SDK schreiben ihre Funktionen am Anfang groß.
Laut Konvention sollen Funktionen am Anfang klein geschrieben werden. Wenn man beides mischt, ist es für mich doch sehr unübersichtlich.

[Chromanoid]

(Höckerschreibweise bei allem außer Konstanten; Klassen und Interfaces großer Anfangsbuchstabe; Variablen kleiner Anfangsbuchstabe; Konstanten alles groß geschrieben)

Ich habe nie verstanden, warum Konstanten komplett groß geschrieben werden. Aus Sicht einer Funktion sollte es doch keinen Unterschied machen, ob man mit einer Variablen arbeitet oder mit einer Konstanten. Oder werden da die Namen aller Werte, die nach ihrer Initialisierung nicht mehr geändert werden können (also auch nicht-static), groß geschrieben?

Ich würde sagen, das liegt unter anderem daran, dass man speziell in Java auf Konstanten über Klassen zugreift - also Klasse.KONSTANTE. Würde man das ganze wie eine Variable schreiben, wäre es sehr anfällig für Verwechselungen... Alle Konstanten sollten komplett groß geschrieben sein und alle Konstanten sollten auch statisch sein, andere Konstanten machen in Java eigentlich keinen Sinn. Im diesem Sinne werden alle Namen die nur als Platzhalter für einen festen Wert stehen groß geschrieben. Ein bisschen vielleicht wie bei #define in C++ würde ich sagen. An sich sind Konstanten ja auch in Java etwas sehr besonderes und stehen eigentlich immer für allgemeines fachliches konstantes Wissen wie Pi oder den RGB Wert für schwarz oder die als Zahlen/Strings übergebenen Typausprägungen eines Datensatzes usw.
Als final deklarierte Methodenargumente o.Ä. werden übrigens nicht groß geschrieben. Mit Konstanten meint man in Java wie schon gesagt für die Anwendung festes Wissen.

[odenter]

Nachtrag.
Enums und Konstanten schreibe ich ebenfalls GROß.

#define bennutze ich in c++ überhaupt nicht sondern enums, ausser ich bin gerade extrem faul, dann ändere ich das aber später ab. Weil ich #define doof finde :)

[Krishty]

Ich würde sagen, das liegt unter anderem daran, dass man speziell in Java auf Konstanten über Klassen zugreift - also Klasse.KONSTANTE.

In C++ kapselt man Konstanten doch genau so, zumindest, wenn man ordentlich objektorientiert arbeitet.

Würde man das ganze wie eine Variable schreiben, wäre es sehr anfällig für Verwechselungen...

Wenn eine Klasse, die eine Konstante MinAllowedWidth hat, auch eine Funktion namens MinAllowedWidth() hat (oder alternativ Pi(), IntegerMaximum()), hat man imo beim Design oder der Benennung was falsch gemacht.

Ein bisschen vielleicht wie bei #define in C++ würde ich sagen.

Langsam dämmert es mir – das soll wohl dazu da sein, damit man weiß, wann man einen Wert z.B. als Größenangabe für ein statisches Array benutzen kann und wann nicht … zumindest ist das der einzige mir bekannte Fall, in dem es von Belang ist, ob ein Wert über die Ausführungszeit des Programms konstant ist … Metaprogrammierung gibt es in Java ja nicht im großen Stil.

Ich finde das schwachsinnig – wenn man schon zwischen Konstanten und Variablen unterscheidet, dann sollte man zwischen Werten unterscheiden, die man verändern kann, und Werten, bei denen das nicht geht, obwohl sie sich bei der Ausführung ändern (final). Die Information ist in hundertmal mehr Fällen hilfreich als die Information, ob ein Wert über die Ausführungszeit eines Programms konstant ist (static final) oder nicht.