Eine Frage des Stils?

Hallo,

ich habe mir verschiedene, in C oder C++ geschriebene, Frameworks und Programme angeguckt. Dabei sind mir hauptsächlich zwei Programmierstile aufgefallen.

Bei einem Stil werden die
* Methoden SoGeschrieben
* Attribute soGeschrieben

Wobei die Methoden in manchen Fällen auch mit einem kleinen Buchstaben beginnen.

Bei dem anderen Stil werden die
* Methoden so_geschrieben
* Attribute m_so_geschrieben

In einigen Fällen wurde das m am Anfang eines Attributes auch weggelassen.

Nun frage ich mich, wann welcher Stil verwendet wird. QT nutzt den ersten.
Der Linux Kernel wurde im zweiten Stil geschrieben. Das ließ mich vermuten, dass der zweite Stil noch aus C stammt (mit Funktionen und structs natürlich). Allerdings habe ich dann Boost gesehen, welches auch im zweiten Stil geschrieben wurde.

Aus einem Buch habe ich den ersten Stil für C++ gelernt. Der zweite verwirrt mich jetzt ein bisschen, da ich bspw. durch Frameworks z.T. dazu gezwungen bin mir diesen in einigen Klassen anzueignen.

Meine Konkrete Frage ist nun:
Wann wird welcher Stil benutzt? Gibt es dafür eine Art "best practice" oder ist man an dieser Stelle dem Gemüt des Frameworkentwicklers ausgeliefert?

Vielen Dank und Grüße

yacb
(yet another c(++) beginner)

knivil

Es gibt keine Regel oder Richtlinie. Jedem ist freigestellt wie er sein Programm schreibt.

best practice

Dieses und Industriestandard (als Buzzwort im Sinne von "best practice") sind fuer Idioten. Glueck verschenken, selber denken!

Wie nennst du denn Variablen? Macht es wirklich so viel aus, den ersten Buchstaben einer Methode gross oder klein zu schreiben? Irgendwer hat mal die Namenskonventionen fuer das Projekt festgelegt und der Einheitlichkeit wegen wird sich dran gehalten.

NEO.PIXEL

Alles eine Frage des Geschmacks.. Das ist genau so wie mit der "Ungarischen Notation". Ob diese sinnvoll ist oder nicht sei dahin gestellt.. Ich hab sie mir angewöhnt..

Und meine Methoden beginn ich jetzt immer mit mldsgvloxhtrltj_foo();

Es ist ganz sicher eine Frage des eigenen Geschmacks, aber es hat(te) oft auch einige praktische Hintergründe.

Beispiel:

class Auto
{
private:
 double mPreis;

public:
 Auto(double Preis) : mPreis(Preis) { }
};

In diesem Fall ist das m als Präfix sinnvoll, weil man so keine Namensüberschneidung bekommt. Folgendes wäre nämlich fatal:

class Auto
{
private:
 double Preis;

public:
 Auto(double Preis) : Preis(Preis) { } // Selbstinitialisierung!
};

Wie man dieses Problem löst ist dann Stilfrage. Folgendes wäre auch möglich:

class Auto
{
private:
 double Preis;

public:
 Auto(double Preis)
 {
  this->Preis = Preis;
 }
};

Und die differenzierte Schreibweise von Funktionen war damals so gängig, da man so besser sehen konnte, dass es sich um eine Funktion handelt. Und so weiter...

Wie du das also für dich löst bleibt dir selbst überlassen. Such dir das aus, was dir am besten zusagt und womit du dich am besten identifizieren kannst.

Sollte dein Stil absolut grauenvoll sein, dann wird man dich da schon darauf hinweisen, wenn du mal Code postest.

Shade Of Mine

vvvvvvvv schrieb:

In diesem Fall ist das m als Präfix sinnvoll, weil man so keine Namensüberschneidung bekommt. Folgendes wäre nämlich fatal:
class Auto
{
private:
 double Preis;

public:
 Auto(double Preis) : Preis(Preis) { } // Selbstinitialisierung!
};

Ne, das ist vollkommen OK so. Ich verwende das staendig. (bis auf dass ich Variablen immer klein schreibe)

Danke für die schnellen Antworten.
So etwas in der Art habe ich mir schon gedacht, wollte es nur noch einmal bestätigt haben.

Es ist denn wohl eine Frage der Gewöhnung, dass man in einem Programm verschiedene Stile verwenden muss, damit man die verschiedenen Bibliotheken nutzen kann (Polymorphie lässt grüßen).

Shade Of Mine schrieb:

vvvvvvvv schrieb:
In diesem Fall ist das m als Präfix sinnvoll, weil man so keine Namensüberschneidung bekommt. Folgendes wäre nämlich fatal:
class Auto
{
private:
 double Preis;

public:
 Auto(double Preis) : Preis(Preis) { } // Selbstinitialisierung!
};
Ne, das ist vollkommen OK so. Ich verwende das staendig. (bis auf dass ich Variablen immer klein schreibe)

Aber spätestens bei einer Setter-Funktion wird es dann zum Problem:

void setX(int x) { x = x; }

volkard

vvvvvvvv schrieb:

Aber spätestens bei einer Setter-Funktion wird es dann zum Problem:
void setX(int x) { x = x; }

void setX(int x) { this->x = x; }

Nexus

Ich bezweifle, dass sich ein Totschlagargument für oder gegen Präfixe wie "m", "my" oder "m_" bei Membervariablen finden lässt. Persönlich benutze ich "my".

Allgemein zu Namenskonventionen: Wenn du nur für dich programmierst, such dir eine aus. Das Wesentliche ist, einheitlich zu bleiben.

Shade Of Mine schrieb:

vvvvvvvv schrieb:
In diesem Fall ist das m als Präfix sinnvoll, weil man so keine Namensüberschneidung bekommt. Folgendes wäre nämlich fatal:
class Auto
{
private:
 double Preis;

public:
 Auto(double Preis) : Preis(Preis) { } // Selbstinitialisierung!
};
Ne, das ist vollkommen OK so. Ich verwende das staendig. (bis auf dass ich Variablen immer klein schreibe)

Und was würde passieren wenn es eine Klasse Preis gibt?

LG

Jockelx

InitListe schrieb:

Und was würde passieren wenn es eine Klasse Preis gibt?

Wie wäre es mit ausprobieren? Lässt sich nicht kompilieren.

knivil

Polymorphie lässt grüßen

Namenskonventionen haben nix mit Polymorphie zu tun.

Nexus

Jockelx schrieb:

Wie wäre es mit ausprobieren? Lässt sich nicht kompilieren.

Wie wäre es mit richtig ausprobieren?

knivil schrieb:

Namenskonventionen haben nix mit Polymorphie zu tun.

Einheitliche Namen hingegen schon. Darauf basiert die ganze Funktionsüberladung oder das Duck-Typing bei Templates. ADL ist ein weiteres Beispiel.

volkard

Nexus schrieb:

Ich bezweifle, dass sich ein Totschlagargument für oder gegen Präfixe wie "m", "my" oder "m_" bei Membervariablen finden lässt.

Sehe ich auch so in C++. Wobei wir evtl eine Renaissance des m_ erleben werden. Wegen der Properties in C# und C++/CLI.

Nexus schrieb:

Persönlich benutze ich "my".

Da ist kritisch anzumerken, daß my in der Literatur eigentlich nur bei Anfängeranfängerbüchern genommen wird. Hier kennen wir Dich. Aber ein Fremder wird dich vielleicht schnell in eine Schublade stecken wollen, wo Du seit Jahren nicht mehr hereinpaßt.

Nexus

volkard schrieb:

Da ist kritisch anzumerken, daß my in der Literatur eigentlich nur bei Anfängeranfängerbüchern genommen wird.

Wirklich? Das wäre mir weder aufgefallen noch habe ich davon gehört. "CKlasse" und so, okay. Aber "my" als Präfix? Allerdings muss ich sagen, dass ich wohl zu wenig Anfängerbücher kenne, um das gut beurteilen zu können. Danke jedenfalls für den Hinweis.

Ich könnte mir auch "m" überlegen. "m_" geht nicht, weil ich ausser bei Makros keine Unterstriche verwende und das komisch aussieht. Oder gar nichts? Wobei mir der Gedanke nicht gefällt, auf this-> zurückgreifen zu müssen und vielleicht deswegen sogar fehlerhaften Code zu kompilieren. Nachgestelltes "_"? Kommt mir auch etwas merkwürdig vor. Vorerst werde ich wohl bei "my" bleiben. Ich mache mir ohnehin schon Feinde mit grossgeschriebenen Funktionsnamen.

Etwas Gutes hat es wenigstens: Die Member-Präfixe sind ziemlich gut zu refactoren. Als ich vor einiger Zeit meine Namenskonvention für Variablen auf Kleinschreibung umgestellt habe, hatte ich etwa dreihundert Mal länger, alle anderen Stellen im Projekt zu finden.

volkard schrieb:

Hier kennen wir Dich. Aber ein Fremder wird dich vielleicht schnell in eine Schublade stecken wollen, wo Du seit Jahren nicht mehr hereinpaßt.

Danke

Michael E.

Nexus: Ich hab meine Attributsnamen ohne Schnickschnack. Wenn ich mal nen Parameter mit demselben Namen hab, bekommt der nen Unterstrich angehängt. Find ich schön, weil man den Parameter nur genau einmal braucht, nämlich zum Setzen des Attributs.

volkard

Nexus schrieb:

volkard schrieb:

Da ist kritisch anzumerken, daß my in der Literatur eigentlich nur bei Anfängeranfängerbüchern genommen wird.

Wirklich? Das wäre mir weder aufgefallen noch habe ich davon gehört. "CKlasse" und so, okay. Aber "my" als Präfix? Allerdings muss ich sagen, dass ich wohl zu wenig Anfängerbücher kenne, um das gut beurteilen zu können. Danke jedenfalls für den Hinweis.

Und was hälst Du von
"mein" als Präfix?

class Person
{
   int meinAlter;
   int meineGroesse;
   ...
}

Zucken Dir jetzt die Lachmuskeln?
Gib es zu, die Mundwinkel sind zuerst hochgerutscht beim Lesen, dann runter beim Erkennen, und dieser Satz läßt sie wieder hochrutschen, weil ich so frech bin.

Yamakuzure

Also my_ meide ich wie der Teufel das Weihwasser. Aber nicht nur weil es, genau wie m_ , in Anfängerbüchern vorkommt, sondern weil ich beruflich auch viel mit Perl zu tun habe, und da ist my das Schlüsselwort um eine Variable zu definieren.

Generell empfinde ich nicht nur m_ sondern auch alle Anderen Präfixe als hässlich, wenn sie einen Unterstrich voraussetzen.

Ich bevorzuge sprechende Namen, bei Funktionen und Variablen; Das erste Wort klein, folgende Groß.
Bei Definitionen wie Klassen, Structs und Templates das erste Wort auch groß. Hier allerdings mit C, S oder T als Präfix. (Denn da eignen sie sich hervorragend um klare Unterscheidungen zu erhalten.)

Für Funktionsparameter habe ich mal die Vorgabe aus den Programmierrichtlinien eines früheren Arbeitgebers übernommen. Dort wurden alle Argumente mit einem kleinen a (wie "Argument") begonnen, und Übernahmen von Argumenten mit einem kleinen x (wie "eXtended"). Das finde ich zwar nicht sonderlich hübsch, es ist aber ganz praktisch.

Der obige Code würde bei mir damit in etwa so aussehen:

class CAuto
{
private:
  double preis;

public:
  CAuto(double aPreis) : preis(aPreis) { }
  void setPreis (double aPreis)
    {
      double xPreis = normalizeLumpSum(aPreis);
      preis = xPreis;
    }
};

Achja: Und wie man sieht verwende ich den GNU-Stil in leicht abgewandelter Form, der kommt auch noch von besagten Richtlinien.

Unterm Strich ist es keine echte Stil- sondern nur Geschmacksfrage. Als schlechten Stil würde ich es nur empfinden, wenn Notationen und Stile in einem Projekt gemischt sind. (Aber zumindest für den Stil gibts ja astyle. ;))

Nexus

@ volkard: Deutsche Bezeichner wähle ich grundsätzlich nicht. Und ja, deine Posts sind ab und zu recht amüsant

Yamakuzure schrieb:

Ich bevorzuge sprechende Namen, bei Funktionen und Variablen; Das erste Wort klein, folgende Groß.

Bis hier dachte ich: Ah, ein typischer Anti-UNler, der mehr Wert auf semantische als formale Aussagekraft legt.

Yamakuzure schrieb:

Bei Definitionen wie Klassen, Structs und Templates das erste Wort auch groß. Hier allerdings mit C, S oder T als Präfix. (Denn da eignen sie sich hervorragend um klare Unterscheidungen zu erhalten.)

Hier musste ich die Schublade dann doch wieder wechseln. Um mal einige Dinge kritisch zu hinterfragen und dich zum Nachdenken anzuregen:

Warum die Unterscheidung zwischen struct und class ? Ich habe das Gefühl, du orientierst dich zu stark an Schlüsselwörtern.
Wäre nicht z.B. auch ein I für Interface angebracht? Das ist oft nämlich weiter von statusbehafteten class -Klassen entfernt als eine Struktur.
Warum T für Templates? Templates sind an den spitzen Klammern eindeutig zu erkennen.
Wie unterscheidest du struct und class , wenn es sich um Templates handelt?
Was machst du mit Typedefs?

Nexus schrieb:

knivil schrieb:

Namenskonventionen haben nix mit Polymorphie zu tun.

Einheitliche Namen hingegen schon. Darauf basiert die ganze Funktionsüberladung oder das Duck-Typing bei Templates. ADL ist ein weiteres Beispiel.

Prototyping lässt grüßen.

Yamakuzure

Meine Antworten in kursiv, okay?

Nexus schrieb:

Warum die Unterscheidung zwischen struct und class ? Ich habe das Gefühl, du orientierst dich zu stark an Schlüsselwörtern.
Es gibt Programme, bei denen ich eine globale Ansammlung von Umgebungswerten (aka Environment) brauche. Das sind meist kleine Programme, die sich im Wesentlichen auf den C-Kern beschränken. Hier benutze ich Structs in der Tat als eben solche, auch wenn struct nur ein Alias für class ist. Die C-Fans in meiner Firma kommen damit außerdem besser klar.

Wäre nicht z.B. auch ein I für Interface angebracht? Das ist oft nämlich weiter von statusbehafteten class -Klassen entfernt als eine Struktur.
Interace? Ich verwende manchmal Interface-Klassen, und die haben ein C wie Class.

Warum T für Templates? Templates sind an den spitzen Klammern eindeutig zu erkennen.
Weil die Header genauso heißen, aber keine spitzen Klammern haben können.

Wie unterscheidest du struct und class , wenn es sich um Templates handelt?
Nur Klassen-Templates bekommen das T. Entschuldige bitte, die Einschränkung habe ich vergessen zu erwähnen. Templated structs und Funktionen sind Structs und Methoden. Bei Structs verwende ich sie allerdings eh nur für TMP, und da haben sie Funktionscharakter und werden auch so benannt.

Was machst du mit Typedefs?
Oh, die hatte ich vergessen. Also Außerhalb geschlossener Strukturen bekommen typedefs einfach sprechende Namen wie andere Typen auch, innerhalb geschlossener Strukturen sinds meist nicht-reservierte Abkürzungen mit einem Unterstrich davor. Ich weiß, das ist böse, grausam, und darf man nicht machen. Aber die Angewohnheit ist fast 20 Jahre alt (bei typedefs) und ich kanns mir irgendwie nicht abgewöhnen...

Achja: Und ja, ich bin da wirklich _ziemlich_ Schlüsselwort verhaftet, aber ja nicht ausschließlich.

Fast vergessen: Endlich mal jemand, der nachfragt, wenn was komisch klingt. Dankeschön!