Der _

Erhard Henkes

Wenn schon p, dann bitte für "pointer". Wenn schon m, dann bitte für "member".
mBlaBla, pBlaBla und pmBlaBla, damit könnte man als Vereinbarung leben (ungefähr analog MFC). Nachteil ist, dass man nach den Kleinbuchstaben groß schreiben muss. Also kein blabla, nur BlaBla.

Dravere

Darf ich mal fragen, wieso ihr es immer wieder schafft, euch darüber die Köpfe einzuschlagen?
Jeder hat seinen eigenen Stil beim Programmieren, und das betrifft wirklich alles, von Ritualen über die Klammersetzung bis hin zu den Namen, wo ist daher das Problem?
Es wird nie einen einheitlichen Geschmack geben. (Und mein Geschmack werden immer 90% ablehnen :D).

@Shade Of Mine & SideWinder,
m_ und _ behindern IntelliSense? Wenn es doch nur das wäre, daher besser VA X zulegen, das hat keine Probleme damit, zumindest nicht das ich wüsste.

Grüssli

asc

Dravere schrieb:

m_ und _ behindern IntelliSense? Wenn es doch nur das wäre, daher besser VA X zulegen, das hat keine Probleme damit, zumindest nicht das ich wüsste.

Etwas OT: Hat eigentlich jemand mal überprüft ob der VA X eigentlich auch mit dem Handle-Body Idiom klarkommt? (Hier verweigert Intellisense jegliche Unterstützung)

Shade Of Mine

Dravere schrieb:

@Shade Of Mine & SideWinder,
m_ und _ behindern IntelliSense? Wenn es doch nur das wäre, daher besser VA X zulegen, das hat keine Probleme damit, zumindest nicht das ich wüsste.

Ist VA mittlerweile klug genug um bei

f

auf m_foo erweitern zu können? Wenn ja, gut. Aber die wenigsten Leute verwenden VA und VA als bedingung anzusetzen um die Coding Convention verwenden zu können... ich weiss nicht. 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.

das einzige wo ein foo_ sinn macht, ist bei namenskonflikten. aber ein m_* hat einfach nur nachteile.

Dravere

Shade Of Mine schrieb:

Ist VA mittlerweile klug genug um bei ... f ... auf m_foo erweitern zu können?

Ach das habt ihr gemeint, tut mir leid, dann habe ich euch falsch verstanden.
Nein, das macht VA nicht und fände ich auch doof. Wenn du eine Membervariable suchst, dann tippst du auch m_ ein, dann hat man eine zusätzliche Sortierung. VA macht sogar automatisch den Unterstrich, falls du m eintippst und danach auf die Shift-Taste drückst.

Shade Of Mine schrieb:

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.

Es ist nicht nötig, es hat keine Vorteile und es hat keine Nachteile. Es ist eine reine Glaubensfrage und das ist alles. Ich verwende auch C für class und Präfixe für primitive Typen.
Das C für class, damit ich folgendes schreiben kann:

CBase Base;

Und die Präfixe für primitive Typen um wirklich hervorzuheben, dass die Variable von einem primitiven Typ ist und von welchem. Bei Funktionen verwende ich die gleiche schreibeweise wie bei Boost, usw. usf. Aber das ist alles Geschmacksache.

Ich finde es so leserlicher und der andere finde es auf die andere Art leserlicher. Ich finde Buch X besser und der andere Buch Z besser. Ich glaube nicht an Gott und der andere glaubt daran. Es kommt alles auf das gleiche raus

@asc,
Tut mir leid, ich verstehe jetzt nicht gerade, was du darunter verstehst ... *diese ganzen Fachausdrücke unbedingt noch weiter auswendig lernen muss*

Grüssli

asc

Dravere schrieb:

@asc,
Tut mir leid, ich verstehe jetzt nicht gerade, was du darunter verstehst ... *diese ganzen Fachausdrücke unbedingt noch weiter auswendig lernen muss*

Falls du VA X hast kannst du mir ja mal sagen ob folgendes (recht einfach gehaltenes Beispiel) in der Methoden A::foo, beim Eintippen von impl-> die Member dieses Types aufgeführt werden:

main.cpp

#include "a.h"
int main()
{
  A a;
}

a.h

class A
{
  private:
    struct AImpl;
    AImpl * impl;

  public:
    A();
    ~A();
    int foo();
};

a.cpp

#include "a.h"

struct A::AImpl
{
  long a;
  long b;
};

A::A()
: impl(new A::AImpl)
{
}

A::~A()
{
  delete impl;
}

int A::foo()
{
  // Eingabe von impl->
  // Liefert es die Member a,b oder nicht?
}

cu André

Nexus

Profi-Programmierer schrieb:

Oh mann was bist du für ein n00b.
Also: das m hat nicht nur den Vorteil kürzer zu sein und eine deutlich stärkerer Assoziation zu Member zu haben, es verhindert auch die Standardproblematik vollständig.

Durch deine Beleidigungen wird deine Argumentation nicht besser. Du hast m nämlich nur mit der Anzahl Tastendrücke befürwortet. Die anderen Argumente sind vor allem Behauptungen ohne Begründung (das Wort "Standardproblematik" z.B. sagt so gut wie gar nichts aus). Ansonsten würde beispielsweise auch nichts gegen myFoo sprechen. Aber da du sowieso die Ansicht vertrittst, du besässest hier die einzig wahre Meinung und Beleidigungen scheinbar zu deinem Umgangston gehören, bringt es wohl eh nichts, was ich hier gerade schreibe...

Aber überhaupt, ich kann hier nur Dravere zustimmen, jeder hat wohl seinen eigenen Programmierstil. Dennoch finde ich diesen Thread sinnvoll, um sich die verschiedenen Möglichkeiten anzuschauen und über diese zu diskutieren. Eigentlich schade, dass das einige nicht verstanden haben und versuchen, anderen ihren Stil aufzudrängen und deren Meinungen als dumm darstellen...

Dravere

asc schrieb:

Falls du VA X hast kannst du mir ja mal sagen ob folgendes (recht einfach gehaltenes Beispiel) in der Methoden A::foo, beim Eintippen von impl-> die Member dieses Types aufgeführt werden:

Das schluckt VA X ohne Probleme. Also die Member a und b werden angezeigt.

Und dieser Implementation von der Klasse in der Klasse, wie es z.b. std::string hat, zumindest soweit ich das in Erinnerung habe, sagt man Handle-Body Idiom?

@Nexus,
Das Problem aber bei solchen Dingen ist, dass man nicht nur m_ oder sowas anschauen kann. Wenn schon muss man sich den ganzen Stil anschauen. Und ich persönlich bin zu faul meinen ganzen Stil mal endlich aufzuschreiben. Irgendwann mach ich es, sobald ich es nötig habe. In Firmen und grösseren Projekten bekommt man ja oft sowieso einen anderen Stil auferlegt, daher hatte ich es noch nie nötig, das Zeug aufzuschreiben.

Grüssli

Shade Of Mine

Dravere schrieb:

Wenn du eine Membervariable suchst, dann tippst du auch m_ ein, dann hat man eine zusätzliche Sortierung. VA macht sogar automatisch den Unterstrich, falls du m eintippst und danach auf die Shift-Taste drückst.

Also muss ich _mehr_ tippen als ohne m.

Es ist nicht nötig, es hat keine Vorteile und es hat keine Nachteile. Es ist eine reine Glaubensfrage und das ist alles. Ich verwende auch C für class und Präfixe für primitive Typen.

Und damit dass ich mehr tippen muss habe ich bereits einen nachteil.

einen kleinen comment zur ungarischen notation:
in der oop welt ist der typ egal, das objekt zaehlt.

klingt sehr verwirrend, aber wenn man es laenger betrachtet macht es sinn und sollte einem zu denken geben.

das ist zB wieder super an java. da schleppen die leute keine sinnlosen c konstrukte mit "weil man es halt so macht" sondern koennen gleich sauberen stil lernen. fuer sowas muss man java wieder lieben

Erhard Henkes

fuer sowas muss man java wieder lieben

Dravere

Shade Of Mine schrieb:

Also muss ich _mehr_ tippen als ohne m.

Shade Of Mine schrieb:

Und damit dass ich mehr tippen muss habe ich bereits einen nachteil.

Ganz ehrlich, was kostet dich mehr, die Tiparbeit oder die Denkarbeit? Dieses kleine m_ oder sonst irgendein kleines Anhängsel fällt komplett weg im Vergleich, vor allem wenn man es mit der Zeit voll automatisch tippt. Wie gesagt, am Ende ist es eine Glaubensfrage
Aber wenn du einen Vorteil haben willst, meiner Meinung nach kann man solchen Code schneller lesen und da kann man eine Menge Zeit sparen

Shade Of Mine schrieb:

einen kleinen comment zur ungarischen notation:
in der oop welt ist der typ egal, das objekt zaehlt.

Ich weiss jetzt nicht ob das auf mich bezogen war, aber ich benutze die Präfixe bei primitiven Datentypen, genau weil sie eben keine wirklichen Objekte sind in C++. Bei Objekten brauche ich ja sowas nicht. Das m_ oder C (bei Klassen) gehört im übrigen nicht zur ungarischen Notation. Und zur Unterscheidung zwischen einem Zeiger auf ein Objekt oder ein Objekt selber, finde ich ein p immer noch eine gute Sache.
Zudem benutze ich eher das Systems Hungarian, welche die Abwandlung von Microsoft des ursprünglichen Apps Hungarian ist. Allerdings mit ein paar kleinen Änderungen, bzw. Vereinfachungen. Ich finde meinen Code dann eben leserlicher und genau darum soll es gehen. Es soll keine Namenskonflikte lösen, es soll keine Tipparbeit erleichtern, es soll keine direkten Vorteile schaffen, zumindest in meinen Augen nicht. Ich mache es nur, damit ich meinen Code später schneller und besser wieder verstehe.

Shade Of Mine schrieb:

das ist zB wieder super an java. da schleppen die leute keine sinnlosen c konstrukte mit "weil man es halt so macht" sondern koennen gleich sauberen stil lernen. fuer sowas muss man java wieder lieben

Dafür kommen diese super java Leute an C oder C++ und verzapfen Unsinn, weil sie keine Ahnung vom Rest der Welt haben
(Und nur zur Klarstellung, ich sage hier weder dass du Unsinn verzapfst noch mein ich den Satz wirklich ernst, denn ich berufe mich immer noch darauf, dass der Stil eine reine Glaubensfrage ist )

Man kann es auslegen wie man will, deshalb kann man auch alle Nachteile wegdiskutieren und durch Vorteile ersetzen und umgekehrt. Das ist der beste Hinweis darauf, dass es eine reine Glaubensfrage ist.

Grüssli

ghorst

ich nutze m_ soweit ich kann. das ganze resultiert aus der erkenntnis, dass man code häufiger wartet, denn schreibt.
ich bin extrem faul, aber auf eine vorausschauende art. ich benutze das ganze um mir erklärungen und dokumentationen zu ersparen.

btw. das ganze hat wenig mit der ungarischen notation zu tun. die ist grauenhaft, weil sie versucht kommentare in den quellcode einzufügen. ein , m oder m tut das nicht. es ist nur ein eindeutiger bezeichner für die variable.

Erhard Henkes

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].

tfa

ghorst schrieb:

btw. das ganze hat wenig mit der ungarischen notation zu tun. die ist grauenhaft, weil sie versucht kommentare in den quellcode einzufügen. ein , m oder m tut das nicht. es ist nur ein eindeutiger bezeichner für die variable.

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!

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!

Quellcode

Ist ja mal übel derb, wie sich hier der Kopf zerbrochen wird, und wie heftig
diskutiert. Naja, ich glaube um "Style" braucht man sich nicht zu streiten...
Ist Geschmackssache^^....

Erhard Henkes

Vor allem läuft es auf eine intellektuelle Pseudo-Überlegenheit der "Java-Entwickler" hinaus, einfach nur lächerlich.

ghorst

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.

HumeSikkins

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.

asc

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.

HumeSikkins

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.