Der _

Nexus

Shade Of Mine schrieb:

was genau ist der sinn von sowas?
m_foo ist furchtbar weil es intellisense erschwert
foo ebenso nur ist es kürzer und daher besser
foo ist ok, weil es intellisense nicht zerstört aber ich sehe den sinn nicht.

SideWinder schrieb:

Außerdem macht ein führender Unterstrich meistens das IntelliSense schwächer, da ich zumindest zwei Buchstaben schreiben muss (_ + Anfangsbuchstabe) um dann mit CTRL+SPACE zu erweitern.

Manchmal finde ich das für das Intellisense aber auch gut. Nehmen wir einmal an, man kennt etwas aus der STL nicht genau und will dessen Funktionen nachschlagen. Da kann man std::deque:: eintippen und da kommt die schöne Liste der Memberfunktionen. Da die privaten und nicht benötigten Funktionen dank _ am Anfang unten in der Liste stehen, hat man einen besseren Überblick.

Ich selber verwende bei privaten Variablen eigentlich keinen _ vorne, sondern nur einen grossgeschriebenen Namen, der auch gut kennzeichnet, wofür die Variable steht. Bei Parametern setze ich oft "New" vorne dran. Aber ich programmiere eher freizeitmässig und habe auch keine gigantischen Projekte; bei meinen eigenen Projekten weiss ich also meistens, was wofür steht. Zum Beispiel:

class MyClass
{
private:
   int Style;
public:
   int GetStyle() const;
   void SetStyle(int NewStyle);
};

Allerdings habe ich bei einigen kleinen Vorlageheaders, die ich eher zur Übung programmiert habe (z.B. ein Containertemplate) die wenigen privaten Member mit _ und Abkürzungen bezeichnet, da man diese oft braucht und sie eben beim IntelliSense hinten stehen (z.B. _ptr , _dim ). Im Allgemeinen werde ich jedoch private Member im Normalfall wie oben bezeichnen.

Erhard Henkes schrieb:

So langsam bin ich doch für this.

Das finde ich unschön. Meiner Ansicht nach ist es besser, wenn sich die Namen von Membervariablen und Parametern klar unterscheiden. Dann kann man auch das this-> weglassen, ohne immer Angst haben zu müssen, dass etwas anderes gemeint sein könnte.

Ihr seht, ich bin mir selber nicht ganz sicher ;). Momentan mache ich die Variante wie im Code oben und fahre eigentlich gut damit. Falls ich in Zukunft aber auf Probleme stosse, steige ich wahrscheinlich auf MyStyle oder myStyle um.

Erhard Henkes

Wie soll man wissen, was hier wirklich optimal ist, wenn selbst ein C++-Guru wie Herb Sutter Unterstriche verwendet und diese wegen des Standards von vorne nach hinten verlagert.

Erhard Henkes schrieb:

Wie soll man wissen, was hier wirklich optimal ist, wenn selbst ein C++-Guru wie Herb Sutter Unterstriche verwendet und diese wegen des Standards von vorne nach hinten verlagert.

Ein Profi sollte auch Entscheidungen treffen können. Egal ob es eine perfekte Lösung ist.

Nexus

Erhard Henkes schrieb:

Wie soll man wissen, was hier wirklich optimal ist, wenn selbst ein C++-Guru wie Herb Sutter Unterstriche verwendet und diese wegen des Standards von vorne nach hinten verlagert.

Ich wollte hier weder jemandem meine Schreibweise aufzwingen noch sie als absolut oder optimal bezeichnen, sondern nur zeigen, wie ich es mache, und dass ich es grundsätzlich nicht schlecht so finde. Und ich denke, das trifft auch für die meisten anderen Poster hier zu...

In diesem Thread geht es wohl eher darum, verschiedene Möglichkeiten zu diskutieren. Klar gibt es nicht den einzig richtigen Ansatz.

Ihr n00bs, richtig macht man das wenn schon so:
mFoo
denn:
1. Man muss nur eine Taste drücken statt zwei für den Unterstricht oder gar drei für m_
2. Wenn man die Markierung an das Ende setzt kann man sie auch gleich weglassen.
3. Eigentlich totaler quatsch, wenn man nicht mal mehr weiß was eine Membervariable ist und was nicht, dann hat der Code ganz andere Probleme.
Um in getter und setter die gleichen Namen zu verwenden gibt es zwei Möglichkeiten:
a) Man hängt an den Parameter ein _ an (davor, danach ist wie gesagt quatsch) oder etwas ähnliches (z.B. p)
b) Man verwendet die gleichen Namen und benutzt this->, indem man einfach den Code Generator der IDE nutzt

Profi-Programmierer schrieb:

b) Man verwendet die gleichen Namen und benutzt this->, indem man einfach den Code Generator der IDE nutzt

Nein, ebend nicht. Gleicher Name geht nicht wegen Namenskoonflikten! Es geht nicht um den Scope sondern um Compile-Fehler!

Nexus

Profi-Programmierer schrieb:

Ihr n00bs, richtig macht man das wenn schon so:
[...]

Leute mit so freundlichem Umgangston und dann noch derart schlagfertigen und ausführlich begründeten Argumenten sind generell nicht ganz ernst zu nehmen...
(Habt ihr gewusst, mit "m" am Anfang kann man sich Tasten sparen... Ich benutz ab jetzt nur noch Abkürzungen für Variablen und #defines für lange Schlüsselwörter :p).

asc

Profi-Programmierer schrieb:

Ihr n00bs, richtig macht man das wenn schon so:
mFoo

Ahh, ein Experte der den Begriff Noob einsetzt, und die einzig wahre Lösung^TM hat.

Ein Profiprogrammierer wüsste das die Realität anders aussieht, und selbst innerhalb einer Firma Abweichungen beim Styleguide über Projekte hinweg durchaus im Rahmen des Möglichen sind.

Profi-Programmierer schrieb:

3. Eigentlich totaler quatsch, wenn man nicht mal mehr weiß was eine Membervariable ist und was nicht, dann hat der Code ganz andere Probleme.

Warum sollte dies wichtig sein? Wenn man die Information braucht, kann man auch this-> davor schreiben (Was in der Regel auch dazu führt das eine IDE die Member auflistet so das dies nicht einmal deutlich mehr Tipaufwand bedeuten könnte). Warum irgendwelche wie auch immer gearteten Präfixe oder Postfixe nutzen? Ich sehe darin keinen Sinn (Lesbarer wird der Code davon auch nicht).

Wenn man sich ohnehin an ein paar allgemeine Regeln hält, wie z.B. das Funktionen nicht zu lang werden sollten (Im Idealfall mit einen Blick erfassbar sind), kommt das Scopeproblem in der Regel auch nicht zum tragen. Wer mit ewig langen Funktionen arbeitet macht eh etwas falsch.

Profi-Programmierer schrieb:

Um in getter und setter die gleichen Namen zu verwenden gibt es zwei Möglichkeiten:...

Mindestens die dritte übliche unterschlägst du: Man nennt Funktionen nach ihrer Funktion.

cu André

Erhard Henkes

oder etwas ähnliches (z.B. p)

Das kleine p sollte man wirklich nur für "pointer" verwenden, nicht für "parameter". "pBlaBla" sollte ein Zeiger auf "BlaBla" sein.

Nexus schrieb:

Profi-Programmierer schrieb:

Ihr n00bs, richtig macht man das wenn schon so:
[...]

Leute mit so freundlichem Umgangston und dann noch derart schlagfertigen und ausführlich begründeten Argumenten sind generell nicht ganz ernst zu nehmen...
(Habt ihr gewusst, mit "m" am Anfang kann man sich Tasten sparen... Ich benutz ab jetzt nur noch Abkürzungen für Variablen und #defines für lange Schlüsselwörter :p).

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.

Die anderen Postings habe ich zur Kenntnis genommen und die angesprochenen Punkte sind auch richtig, allerdings sehe ich nicht inwiefern sie einem meiner Punkte widersprechen würden bzw. überhaupt mit diesen kollidieren.

Obwohl zum "p": war doch nur ein Beispiel und da sind wir auch schon wieder beim Thema warum sollte man einen Zeiger mit p kodieren? Auch hier sehe ich keinen Grund wie bei den Membern. Wenn man nicht mehr weiß was ein Zeiger ist hat der Code ganz andere Probleme.

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