Der _
-
tfa schrieb:
Wo bitte ist der Unterschied, ob ich m für Member, p für Pointer, i für Integer oder Index oder sonst irgendein Präfix an die Variablennamen hänge? Alles gleich grauenhaft!
der unterschied ist recht einfach: das eine hat den hang sich zu ändern. das andere eher nicht.
oder um es an einem einfachem beispiel zu sagen: mit der umstellung von 16 auf 32 oder von 32 auf 64 bit hätte sogar der letzte depp erkennen müssen, dass die ungarische notation käse ist. die bei ms haben das mit der einführung von .net verstanden und verzichten dort vollständig auf diese notation.
membervariablen hingegen ändern sich äußerst selten und wenn dann ist meist ein größeres redesign der klassen notwendig.tfa schrieb:
Erhard Henkes schrieb:
Richtig schön wäre es, wenn man im Editor mit Farbe arbeiten könnte. Dann könnte man Member-Variablen durch Färbung kennzeichen. Müsste umschaltbar sein mit im Extrabereich festgelegten Modus: entweder m_Blabla oder [Farbe]BlaBla[/Farbe].
Als Java-Entwickler und Anwender der handelsüblichen Java-IDEs kann ich dazu nur sagen: LOL!
weißt du. ich bin auch anhänger der ide-fraktion, aber trotz allem benutze ich vi (im klassischen modus) um mal schnell zu schauen, was in einer datei steht. da nützt es mir herzlich wenig, wenn das irgendeine ide auf ihre weise löst.
ansonsten: das einbauen eines solchen features sollte in einer c++-ide wohl nur wenige stunden bedürfen.
-
Shade Of Mine schrieb:
Vorallem: wofür? m_ hat keinen Vorteil, wir können nur die Nachteile wegdiskutieren - aber diese Konvention kommt aus C zeiten wo man alle geprefixt hat. In modernen Sprachen verwendet man nichts derartiges und in c++ ist es auch nicht nötig.
Finde diese Aussage etwas zu pauschal. Aus technischer Sicht sind Namen Schall und Rauch, aber da Code ja nun mal primär für Menschen geschrieben werden soll, sollte man in der Regel schon irgendwelche einheitlichen Richtlinien verwenden.
Ob nun mit Präfix, Suffix, Asterix oder Obelix,
die meisten Leute die ich kenne, kennzeichnen auch in "modernen" Sprachen Eigenschaften von Variablen über den Namen. Selten den Typ, aber doch fast immer den Scope. Ich kenne z.B. niemanden, der "i" für eine globale Variable verwendet. Als Schleifenvariable ist "i" hingegen völlig ok. Suffixe/Präfixe/Groß-/Kleinschreibung ergeben sich dann meist aus solchen Überlegungen.Wie weit man bei solchen Konventionen geht, hängt aber sicher von der verwendeten Sprache und dem Kenntnisstand des Teams ab. In C++ würde ich z.B. die folgenden Scopes durch entsprechende Kennzeichnung unterscheiden:
- global
- statische Member
- Member
- lokal
- eventuell noch Parameter
Außerdem würde ich mindestens noch Typnamen von Objektnamen unterscheiden.
-
HumeSikkins schrieb:
Finde diese Aussage etwas zu pauschal. Aus technischer Sicht sind Namen Schall und Rauch, aber da Code ja nun mal primär für Menschen geschrieben werden soll, sollte man in der Regel schon irgendwelche einheitlichen Richtlinien verwenden.
Ob nun mit Präfix, Suffix, ......oder ohne diese. Ich war (kurzzeitig) auch Anhänger der Ungarischen Notation (liegt fast 10 Jahre her), für Scopes hatte ich noch nie ein wirklichen Bedarf für Präfixe/Suffixe, und durch eine sprechende Namensgebung erklären sich einige Variablen auch gänzlich selbst.
Verwende was du meinst, einen Sinn sehe ich weder in der UN noch in irgendwelchen anderen Verstümmelungen von Variablenbezeichnern. Ja, jeder arbeitet nach Konventionen (Ich sag z.B. CamelCase & PascalCase), ob dies aber wirklich bis auf das kleinste Detail reglimentiert werden muss wage ich zu bezweifeln.
Und zu deinen Scopes:
global - Sollte man eh wo möglich vermeiden (In der Regel haben meine Programme keine, oder nur solche die vom Framework bedingt sind).statische Member - Hier sehe ich keinen Grund von einer expliziten Trennung von den Membern, zumal sich hier recht häufig durch eine sinnvolle Benennung die unterscheidung ergibt (z.B. instanceCount legt es schon recht nahe).
Member, lokal und Parameter: Wenn man seine Methoden/Funktionen übersichtlich in der Größe hält, sehe ich auch hier keinen Unterscheidungsgrund (Wenn man Methoden auf maximal eine, vielleicht auch zwei Bildschirmseiten begrenzt ist dies garkein Thema). Bei Membern kann man zudem wenn nötig this-> vorsetzen.
Daher mein Fazit:
Sehe keinen Handlungsbedarf für Präfixe/Suffixe.
-
asc schrieb:
HumeSikkins schrieb:
Finde diese Aussage etwas zu pauschal. Aus technischer Sicht sind Namen Schall und Rauch, aber da Code ja nun mal primär für Menschen geschrieben werden soll, sollte man in der Regel schon irgendwelche einheitlichen Richtlinien verwenden.
Ob nun mit Präfix, Suffix, ......oder ohne diese. Ich war (kurzzeitig) auch Anhänger der Ungarischen Notation (liegt fast 10 Jahre her), für Scopes hatte ich noch nie ein wirklichen Bedarf
D.h. du nennst eine globale Variable auch mal "i" oder erzwingst "sprechende" Namen für Schleifenvariablen?
Verwende was du meinst
Vielen Dank. Das mache ich
einen Sinn sehe ich weder in der UN noch in irgendwelchen anderen Verstümmelungen von Variablenbezeichnern. Ja, jeder arbeitet nach Konventionen (Ich sag z.B. CamelCase & PascalCase), ob dies aber wirklich bis auf das kleinste Detail reglimentiert werden muss wage ich zu bezweifeln.
Ebenso wie du, halte ich nichts von der klassischen UN und ich hatte auch nicht das Gefühl, dass es um selbige ging.
Ich bin aber ein großer Fan von *einheitlichen* Konventionen. Wie die genau aussehen ist mir wurscht. Nur sollten sie in Projekt X, Datei Y genau so ausehen, wie in Projekt X, Datei Z. Hier CamelCase und dort mit_vielen_kleinen_unterstrichen halte ich z.B. für Käse.
und zu deinen Scopes:
global - Sollte man eh wo möglich vermeiden (In der Regel haben meine Programme keine, oder nur solche die vom Framework bedingt sind).Die Tatsache, dass man global Variablen vermeiden sollte, befreit einen nicht davon sie zu benennen, wenn sie dann doch mal auftreten sollten
statische Member - Hier sehe ich keinen Grund von einer expliziten Trennung von den Membern, zumal sich hier recht häufig durch eine sinnvolle Benennung die unterscheidung ergibt (z.B. instanceCount legt es schon recht nahe).
Member, lokal und Parameter: Wenn man seine Methoden/Funktionen übersichtlich in der Größe hält, sehe ich auch hier keinen Unterscheidungsgrund (Wenn man Methoden auf maximal eine, vielleicht auch zwei Bildschirmseiten begrenzt ist dies garkein Thema). Bei Membern kann man zudem wenn nötig this-> vorsetzen.
Also ich für meinen Teil verwende Präfix/Suffixe/andere Konventionen
nicht anstelle von sinnvollen Grundregeln (wenig global, kurze Funktionen, sprechende Namen...), sondern lediglich als zusätzliche Hilfestellung.
Manchmal ist ein foo einfach ein foo und dann ist this->foo eben nicht gleich lokaler foo. Ob ich in so einem Fall nun this->foo schreibe oder eben generell
einen künstlichen Name verwende (myFoo, aFoo, foo_, wie auch immer), erscheint mir schlicht eine Frage des persönlichen Geschmacks zu sein und nicht eine Frage von Pro/Contra. Und genau deshalb halte ich Aussagen wie die von Shade für zweifelhaft.Sehe keinen Handlungsbedarf für Präfixe/Suffixe.
Was in meinen Augen auch völlig ok ist.