Variablen -> Guter Programmierstil

Simon2

_eddi schrieb:

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.

thordk

finds unsinnig, member speziell auszuzeichnen. sollte es in irgendeiner methode unklarheiten geben, kann man jederzeit nen this-> davorklatschen.

Simon2 schrieb:

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.

ronny

nebenbei sollte man bemerken,
das solche helfer-methoden, die auf member von anderen attributen zugreifen
die koppelung im programm reduzieren und deshalb recht nützlich sind

Simon2

_eddi schrieb:

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

nur das wir uns richtig verstehen: mit membern meine ich eigenschaften/attribute, nicht etwa memberfunktionen/methoden, falls ich mich da mal unverständlich ausgedrückt habe. und wenn man so ein 'm_' voranstellt, dann bezieht sich das tatsächlich immer (bei mir zumindest) auf solche attribute. die sind dann auch im private-bereich der klasse deklariert. und wie gesagt 'm_' bei methoden habe ich selbst weder je verwendet noch gesehn. stattdessen schieb ich diese attribute dann in den private-bereich und schreibe mir entsprechende get/set methoden, mit denen ich dann darauf zugrifen kann. im notfall nimm kann man stattdessen auch noch ein typedef oder ähnliches verwenden, aber ne inline-methode kommt normal besser

hustbaer

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

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

Konrad Rudolph

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.

Chris++ 0

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

Lange Rede kurzer Sinn

Lange Rede garkein Sinn

Konrad Rudolph

Chris++ schrieb:

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

Ja der gute alte Genitiv

Simon2

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.

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

Gruß,

Simon2.

Chris++ 0

[OT]

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]

Simon2

hustbaer schrieb:

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.

Konrad Rudolph

Simon2 schrieb:

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.

Simon2

Aber da geht's Dir doch gar nicht um die Unterscheidung zwischen Membern und Nicht-Membern, sondern um die Unterscheidung der Member untereinander.
Dasselbe Problem hättest Du mit

class test {
   size_type m_length;
   int m_length;
};

Gruß,

Simon2.

C++ Forumbot

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

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

Dieses Posting wurde automatisch erzeugt.

Konrad Rudolph

Simon2 schrieb:

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.

Simon2

Konrad Rudolph schrieb:

Simon2 schrieb:

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

OK, dann ist das aber eine andere Zielrichtung als die oben angesprochene.
Das bedeutet mit

class test {
    size_type length;

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

hättest Du auch keine Probleme ...

Gruß,

Simon2.

Variablen -&gt; Guter Programmierstil

Variablen -> Guter Programmierstil