Variablen -> Guter Programmierstil

Hallo,

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:

int var_ = ...;
int _var = ...;
int __var = ...;

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

p_shift = ...;
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

CStoll

Ob das guter Stil ist, muß jeder für sich selber entscheiden - sowas endet normalerweise in einer Glaubensdiskussion zwischen UN-Anhängern und - Gegnern

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

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.

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.

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]

Variablen -&gt; Guter Programmierstil

Variablen -> Guter Programmierstil