Variablen -> Guter Programmierstil

[Simon2]

Hi,

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.

[thordk]

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

[Simon2]

thordk schrieb:

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.

[mad_martin]

Vor allem wichtig ist, konsequent zu bleiben! Nicht in der einen Klasse den einen Stil fahen und in der anderen eine völlig andere Bezeichnertaktik wählen.

[~eddi~]

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.

thordk schrieb:

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

find ich auch

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

[~eddi~]

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.

[~eddi~]

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

[tr]

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.