da ich per Sufu nicht wirklich meine Frage beantworten konnte würde ich gerne eure Meinung bzw. eure Hilfe in Anspruch nehmen

Ich würde mir gerne aneignen "sauberen, schönen" C++ Code zu schreiben - wer will das nicht.

Vor allem bei Variablen weiß ich einfach nicht was in der Praxis gern gesehen wird bzw. ich sehe oft so bezeichnungen die irgendwas bedeuten ich aber nicht weiß wie ich das schnell verstehen soll:

für was benutzt man z.B:

1. int var_ = ...;
2. int _var = ...;
3. int __var = ...;

Kann es sein das eines ne Membervariable einer Klasse ist?
Macht es sinn für pointer so was zu machen:

1. p_shift = ...;
2. ptr_shift = ...;

Es wäre sehr nett wenn jemand einfach mal so losposten würde was ihm dazu einfällt bzw. wie er das so meint....

Danke

(Variante 3 würde ich auf keinen Fall verwenden - Bezeichner mit doppeltem Unterstrich sind für freie Verwendung durch den Compiler reserviert)

ich persönlich würde KEINE Kennzeichnung vornehmen. Und schon gar nicht mit führenden Unterstrichen, weil da einige Compiler eigene Keywords haben, mit denen man sich in die Quere kommt.

Wichtiger ist, dass man anhand der Variable gleich versteht, was sie fachlich beinhaltet. Also nix mit "var" oder so, sondern "Spielkarte" oder "VergleichsFunktion" oder ...

Das Einzige, was ich bisweilen mache, um die Lesbarkeit zu erhöhen, sind kleine und übliche Abkürzungen ("Stk" statt "Stueck") und Trennungen in zusammengesetzten Begriffen ("Automobilfuehrerscheinkennzeichen" ist IMO schlechter zu lesen als "AutomobilFuehrerScheinKennzeichen", "Automobil_FSchein_Kz" oder so). Allerdings muss man da sehr vorsichtig sein mit ähnlichen Begriffen und "Abkürzungsfehlern".

Mit welcher Technik (Pointer, Referenz, ....) diese Fachlichkeit abgebildet ist, kann man in der Definition nachschlagen und muss man nicht mit dem Variablennamen rumschleppen und bei der kleinsten Änderung an 1000 Stellen ändern (von denen man immer > 10 vergisst/nicht ändern kann und sich dann sowieso nicht darauf verlassen kann).

Gruß,

Simon2.

guter stil ist meiner meinung nach auch, seine bezeichner und kommentare in englisch zu halten.

Meiner Meinung nach auch ... aber unsere Firmenkonventionen fordern Anderes.
Wobei mit Lesbarkeit da wichtiger ist ... habe mal Code von einem Englischlegastheniker (hat sich selbst so bezeichnet) gelesen - da bekommt man die Krise und wünscht sich, er hätte doch Deutsch genommen.

Gruß,

Simon2.

int var_ = ...;
...
Kann es sein das eines ne Membervariable einer Klasse ist?

sieht man tatsächlich manchmal bei membervariablen, ich würde jedenfalls sagen man versteht was damit gemeint ist. wenn mans schon abgrenzen will tuts aber auch ein 'm_' vor der variablen.

thordk schrieb:

guter stil ist meiner meinung nach auch, seine bezeichner und kommentare in englisch zu halten.

find ich auch

ichBinGast schrieb:

int var_ = ...;
...
Kann es sein das eines ne Membervariable einer Klasse ist?

sieht man tatsächlich manchmal bei membervariablen, ich würde jedenfalls sagen man versteht was damit gemeint ist. wenn mans schon abgrenzen will tuts aber auch ein 'm_' vor der variablen....

Habe ich ein zwiespältiges Gefühl bei ... spätestens, wenn man bedenkt, dass es auch public-Member und Memberfunktionen gibt und das sieht schon seltsam aus:

A a, b;
   b.m_x.m_s = a.m_f();

Die "Memberqualität" hat man ja mit "." schon ausreichend qualifiziert.

Und wenn man alternativ nur die private-Member derartig kennzeichnet, hat man wieder so eine "innere Logik", die einem im Nachhinein Probleme bereit (z.B. muss man bei private->public-Wechsel die Namen ändern, innerhalb einer Memberfunktion wird der Aufruf eigener public- und private-Funktionen differenziert, ....)

Gruß,

Simon2.

Habe ich ein zwiespältiges Gefühl bei ... spätestens, wenn man bedenkt, dass es auch public-Member und Memberfunktionen gibt und das sieht schon seltsam aus:

ich habe mich mit meinem beitrag ja gar nicht auf methoden bezogen...
naja und wenn eine eigenschaft unbedingt public sein muss, dann würde ich sie trotzdem mittels einer methode abfragen (stichwort: const-spezifizierer). normalerweise dürfte sie sowas aber schon bereitstellen also sieht das so aus:

A b;
b.m_s.height();
// oder besser
A b.height();
//inline size_t A::height() const { return m_s.height(); }; oder wie auch immer

Simon2 schrieb:

Und wenn man alternativ nur die private-Member derartig kennzeichnet, hat man wieder so eine "innere Logik", die einem im Nachhinein Probleme bereit

jo da wirds dann wirklich etwas schräg.

...ich habe mich mit meinem beitrag ja gar nicht auf methoden bezogen...

Aber ich sehe in dem Zusammenhang keinen Unterschied zwischen einer Memberfunktion und einem anderen Member. Spätestens hier bekommst aber Schwierigkeiten:

struct A {
   int operator()(int);
};

struct B {
   A m_a;
};

int main() {
   B b;
   b.m_a(3);
...

Funktion ? Member ? Attribut ? mit m_ oder ohne ?

_eddi schrieb:

...
naja und wenn eine eigenschaft unbedingt public sein muss, ...

Ohne public Eigenschaft sind Klassen relativ witzlos (höchstens als "Vererbungsbrocken" ...)...;)

Langer Rede kurzer Sinn:
- Will man konsequent sein, schreibt man vor fast alles m_
- will man das nicht, ist die Kennzeichnung unzuverlässig und damit wenig hilfreich oder gar irreführend (spätestens wenn ich mich nicht darauf verlassen kann, dass ein ungekennzeichnetes Ding KEIN Member ist)
=> Ich lass' es lieber.

Gruß,

Simon2.

Die einzige Ausnahme die ich mache ist bei Klassen wie Vielleicht Vector, sieht wirgendwie doof aus "v.m_x = 123" zu schreiben.

Langer Rede kurzer Sinn:

O.o Ich glaube, das ist gerade das erste Mal, dass ich diesen Ausdruck korrekt geschrieben in einem Forum gesehen habe.

Simon2 schrieb:

Langer Rede kurzer Sinn:

O.o Ich glaube, das ist gerade das erste Mal, dass ich diesen Ausdruck korrekt geschrieben in einem Forum gesehen habe.

Wie soll man den Ausdruck sonst schreiben? oO

Lange Rede garkein Sinn

Konrad Rudolph schrieb:

Simon2 schrieb:

Langer Rede kurzer Sinn:

O.o Ich glaube, das ist gerade das erste Mal, dass ich diesen Ausdruck korrekt geschrieben in einem Forum gesehen habe.

Wie soll man den Ausdruck sonst schreiben? oO

Die wohl am meisten verwendete Form scheint „Lange Rede, kurzer Sinn“ zu sein. (Womit der Sinn ein ganz anderer wäre.)

Simon2 schrieb:

Langer Rede kurzer Sinn:

O.o Ich glaube, das ist gerade das erste Mal, dass ich diesen Ausdruck korrekt geschrieben in einem Forum gesehen habe.

Es hat auch ziemlich gedauert, bis ich diese Redewendung richtig begriffen hatte - nun MUSS ich sie einfach richtig schreiben.

Gruß,

Simon2.

wie war das doch gleich mit dem Genitiv?

F: "Wessen Rede kurzer Sinn?"
A: "Langer"

naja keine Ahnung. Um ehrlich zu sein hab ich auch nur "Lange Rede kurzer Sinn" gelesen und war ein bisschen von Konrads Aussage überrascht.

[/OT]

Konsequent sein ist relativ einfach, und zwar schreibt man vor Datenmember einer Klasse m_.
Vor Funktionsmember NICHT.

Allzu konsequent finde ich das aber nicht, weil ich eigentlich keinen großen Unterschied zwischen beiden sehe (was spätestens bei einem Funktor als Datenmember offensichtlich wird) ...

Außerdem soll doch die Kennzeichnung (wenn ich recht informiert bin) eigentlich Klarheit darüber bringen, welches "Ding" genommen wird: Ist das bei Funktionsmember weniger wichtig als bei Datenmembern ?

Ich persönlich denke, es gibt in C++ sooo viele "Auflösungsmechanismen", dass eine Kennzeichnung dem eigentlich Ziel der Flexibilisierung mit so einer Kennzeichnung entgegengewirkt wird ... ebenso wie eine ständige Verwendung von "this->" oder "std::" ...
Sagen wir mal so: Wenn der Compiler weiß, welches Symbol wird, sollte ich das eigentlich auch wissen - und wenn er kein "m_" braucht, sollte ich das eigentlich auch nicht.

Gruß,

Simon2.

Ich persönlich denke, es gibt in C++ sooo viele "Auflösungsmechanismen", dass eine Kennzeichnung dem eigentlich Ziel der Flexibilisierung mit so einer Kennzeichnung entgegengewirkt wird ...

Man *braucht* die Kennzeichnung aber nunmal, um Namenskonflikte zu vermeiden (Beispiel siehe unten). Und wenn man diese Kennzeichnung für einige Datenmember hat, sollte man sie konsequenterweise für *alle* fortsetzen.

class test {
    size_type length;

public:
    size_type length() const { return length; }
};

=> Kompilierfehler.

class test {
   size_type m_length;
   int m_length;
};

Gruß,

Simon2.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Aber da geht's Dir doch gar nicht um die Unterscheidung zwischen Membern und Nicht-Membern, sondern um die Unterscheidung der Member untereinander.

Ja, natürlich. Der einzige und alleinige Zweck meiner Datenmember-Kennzeichnung ist die Auflösung von Namenskonflikten. Und solange mir da niemand einen besseren Vorschlag unterbreitet, mache ich es weiterhin so.