wie einen pointer kennzeichen

[in]

m_ ist out.

Man macht ein _ hinter die Member-Variable.

aus m_pFoo wird pFoo_

[..]

Das kleine p mit nachfolgendem Großbuchstaben hat sich eingebürgert und hat daher hohen Erkennungswert. Also sollte man bei pFoo bleiben.

Bezüglich der Member gibt es verschiedene Systeme:

m_Foo _Foo Foo_ aFoo itsFoo

Dabei ist Foo_ zur Zeit in Mode. Manchmal ist der Underscore schwer erkennbar. Vorgestellt konkurriert er mit alten Kennzeichnungen, also bleibt nur nachgestellt.

Neue Idee: Foo~ (besser erkenbar)

getFoo()
setFoo()
ísFoo()

[volkard]

Jover schrieb:

Aber ich habe noch ne Frage: Wie soll ich ohne ungarische notation Pointer von anderen Variablen unterscheiden können?

normalerweise gar nicht!

for(Node* pos=anchor;pos!=0;pos=pos->next)
   ...

jedem ist in der liste klar, daß anchor ein ZEIGER auf den ersten knoten ist. und daß pos ein zeiger ist, bedarf auch keiner langen überlegung.

prev->pred=this;
pred->prev=this;

auch klar.

aber warum der wahn, jeden pointer mit nem p zu kennzeichnen? doch nur aus einem einzigen anfängerfehler heraus:

void sort(int* a,int* b)
{
   if(a<b)...//ups, *a<*b war gemeint!!!
}

naja, hier wäre ein p wohl gut. also mal hin damit. aber machs überall sonst weg.

Jover schrieb:

soll ich das m_ als Prefix bei Membervariablen auch weglassen?

weg.

[operator void]

memberVariable_ probiere ich in meinem aktuellen Projekt gerade aus und stolpere jedes Mal, wenn danach ein . oder -> kommt. Die Lesbarkeit ha bisher auch nicht zugenommen, das _ lese ich fast nie bewusst mit. Ich werde wohl bei m_ bleiben - selbst wenn man als treuer Verben-Fan seine Getter mit get_ präfixt (bin ich zu faul für), muss man sonst entweder seine Parameter umbenennen oder this-> verwenden. Och nö...

[volkard]

operator void schrieb:

muss man sonst entweder seine Parameter umbenennen oder this-> verwenden. Och nö...

aba nur konstruktorparameter! na, das ist doch noch verschmerzbar.

[Gast]

volkard schrieb:

operator void schrieb:

muss man sonst entweder seine Parameter umbenennen oder this-> verwenden. Och nö...

aba nur konstruktorparameter! na, das ist doch noch verschmerzbar.

Sehe ich genauso. In der Regel hat man kein Problem damit, Datenelemente ohne besondere Kennzeichnung zu erkennen.
Pointer kennzeichne ich mit p, Referenzen gar nicht (kurzer Kontext).
Getter und Setter heißen bei mir getFoo().

Die ganzen Variablenprefixe sind jetzt endgültig out :p

[rüdiger]

Pointer speziell kennzeichnen, halte ich nicht für sinnvoll. Man weiss ja, was ein Pointer ist oder was nicht (kann man ja an der Programmlogik erkennen). Ansonsten schaut man in der Doku oder im Code nach.

Member Kennzeichne ich idr. mit dem Suffix _m und getter/setter haben idr. kein get und set im Funktionsnamen

[operator void]

kingruedi schrieb:

Ansonsten schaut man in der Doku oder im Code nach.

Genau das soll ja vermieden werden... Ansonsten könnte man seine Variablen einfach nach einem Telefonbuch benennen
Dafür finde ich Überladen böse, wenn die Funktionen was völlig unterschiedliches machen. Auch wenn es praktisch gesehen nur nervt, wenn man mit bind() oder so dran binden will.

[Jover]

Danke! Ihr habt mir sehr geholfen.

Bei getter/setter bleibe ich bei get_foo/set_foo. Habs zwar auch mal ohne get_/set_ probiert, aber das lass ich doch lieber.

[Knuddlbaer]

operator void schrieb:

kingruedi schrieb:

Ansonsten schaut man in der Doku oder im Code nach.

Genau das soll ja vermieden werden... Ansonsten könnte man seine Variablen einfach nach einem Telefonbuch benennen
Dafür finde ich Überladen böse, wenn die Funktionen was völlig unterschiedliches machen. Auch wenn es praktisch gesehen nur nervt, wenn man mit bind() oder so dran binden will.

Hier mal ein Beispiel wo man nicht um die Doku (sofern vorhanden) herum kam:

http://www.c-plusplus.net/forum/viewtopic.php?t=35383&start=122

[Gast]

kingruedi schrieb:

Pointer speziell kennzeichnen, halte ich nicht für sinnvoll. Man weiss ja, was ein Pointer ist oder was nicht (kann man ja an der Programmlogik erkennen). Ansonsten schaut man in der Doku oder im Code nach.

Member Kennzeichne ich idr. mit dem Suffix _m und getter/setter haben idr. kein get und set im Funktionsnamen

Ach so, du kennzeichnest Pointer nicht, aber Datenelemente schon. Finde ich ausgesprochen sinnvoll.
In der Regel sollten Datenelemente gar nicht von außen zugänglich sein. Und innerhalb der Klasse sollte man eigentlich wissen, was man für Datenelemente hat. Udn bei Namenskonflikten kann man immer noch this verwenden.

[Jover]

Was haltet ihr davon?

http://geosoft.no/style.html

[operator void]

Naja, ob man this-> oder m_ schöner findet...

Außerdem sieht man mit konsistentem m_ sofort, wo man direkt mit den privaten Daten arbeitet. Das finde ich zumindest praktisch. In einer String-Klasse macht es einen ziemlichen Unterschied, ob man m_size = 4 oder resize(4) schreibt. Mit dem ersten kann man die Invariante verletzen, mit dem zweiten nicht.

[operator void]

Jover schrieb:

Was haltet ihr davon?

http://geosoft.no/style.html

Was bei dem alles "Common Practice" ist

Außerdem weiß ich nicht, warum Konstanten so besonders sein sollen, dass er (wie die Javaianer) die UNBEDINGT_KAPITALISIEREN_WILL. Das würde ich mir für #defines aufheben und die einfach wie normale Variablen benennen.

Und die #includes ordne ich genau andersrum an; zumindest der Header, den man in der Datei implementieren will, sollte IMHO nach oben. Dann erkennt man an den Fehlermeldungen sofort, ob man im Header alle ausreichenden weiteren Header inkludiert hat.

[DrGreenthumb]

Jover schrieb:

Was haltet ihr davon?

http://geosoft.no/style.html

Naja, sind viele persönliche Meinungen die aber auf keinen Fall das Nonplus-Ultra darstellen.

Ich schreibe doch nicht int *x; statt int* x; nur weil manche Leute die Syntax nicht können.

[Shade Of Mine]

Jover schrieb:

Was haltet ihr davon?

http://geosoft.no/style.html

Naja, ein paar sachen sind komisch

int getMaxIterations() // NOT: MAX_ITERATIONS = 25
{
return 25;
}

Was spricht gegen
int const maxIterations = 25; ?

Der Nachteil einer Funktion ist der: ich kann mich nicht darauf verlassen, dass sie immer 25 zurueckgibt. Schliesslich weiss ich ja nicht, wie sie implementiert ist (bzw. ich will es nicht wissen)

Da ist eine Konstante viel klarer.

Private class variables should have underscore suffix.

Ich bevorzuge keine Kennzeichnung.

Names representing template types should be a single uppercase letter.

Autsch. Das ist boese.
Was ist einfacher zu lesen?

template<bool condition, class Then, class Else>
struct IfThenElse
{
    typedef Then result;

};

template<class Then, class Else>
struct IfThenElse<false, Then, Else>
{
    typedef Else result;
};

//oder
template<bool C, class T, class T>
struct IfThenElse
{
    typedef T result;

};

template<class T, class E>
struct IfThenElse<false, T, E>
{
    typedef E result;
};

Namen sollen klar sein und nicht kuenstlich verkuerzt werden

Variables with a large scope should have long names, variables with a small scope can have short names.

Ich versuche einer Variable einen sinnvollen Namen zu geben, unabhaengig vom scope.
Wenn die Variable nur ein Buffer ist, dann heisst sie halt 'buf', auch wenn der scope recht gross ist.

The suffix List can be used on names representing a list of objects.

keine gute Idee.
statt
vertexList schreibe ich lieber verteces
oder statt carList schreibe ich lieber cars
Denn eine 'Collection' von mehreren Werten, muss ja keine Liste sein, kann auch eine deque, vector,.. sein.

The prefix n should be used for variables representing a number of objects.
[..]
The suffix No should be used for variables representing an entity number.

ne, ich mag keine kennzeichnung von Variablen.

Naming pointers specifically should be avoided.

Jep, dem kann ich nur beipflichten.

C++ header files should have the extension .h. Source files can have the extension .c++ (recommended), .C, .cc or .cpp.

nein.
Source Files und Header Files muessen gleich benannt werden, zB
.cpp - .hpp
.C - .H
.cxx - .hxx
aber nicht mischen

All definitions should reside in source files.

mit ausnahme von 1 zeiligen Methoden

ein

int getValue() const { return value; }
finde ich in der header datei vollkommen OK

The parts of a class must be sorted public, protected and private [2][3]. All sections must be identified explicitly. Not applicable sections should be left out.

ich verwende
public typedefs
private members
private methods
protected //wobei ich das quasi nie verwende
public

Type conversions must always be done explicitly. Never rely on implicit type conversion.

Bei float zu int OK, aber was ist bei char zu int? da finde ich es OK
char c='a';
int i=c;
zu schreiben.

C++ pointers and references should have their reference symbol next to the variable name rather than to the type name.

ich mach es umgekehrt.

The const keyword should be listed before the type name.

ich mach es umgekehrt.

do-while loops can be avoided.

Bloedsinn. manchmal muss die schleife mindestens einmal durchlaufen. und dann verwende ich do while

The form while(true) should be used for infinite loops.

Ob while(1), while(true) oder for(;;) ist egal.
man soll nur immer da selbe nehmen. die erklaerung dazu

Testing against 1 is neither necessary nor meaningful. The form for (;;) is not very readable, and it is not apparent that this actually is an infinite loop.

ist bloedsinn.
denn for(;;) wurde extra fuer endlosschleifen gemacht und 1 ist ein synonym fuer true

The conditional should be put on a separate line.

manchmal ist ein
if(error) throw autsch();
sehr gut lesbar.

Functions must always have the return value explicitly listed.
[..]
If not exlicitly listed, C++ implies int return value for functions. A programmer must never rely on this feature, since this might be confusing for programmers not aware of this artifact.

zur erklaerung kann ich wirklich nur *lol* sagen.

mit der Klammernsetzung bin ich auch nicht einverstanden
ich verwende immer

if(x)
{
  nix;
}

aber das ist geschmackssache

while (true) { // NOT: while(true) ...

ich verwende lieber
while(1) - denn ich sehe den sinn des leerzeichens hier nicht

detto hier:

case 100 : // NOT: case 100:
doSomething (currentFile); // NOT: doSomething(currentFile);

Tricky code should not be commented but rewritten!

manchmal ist tricky code aber praktisch.

[rüdiger]

http://geosoft.no/style.html

Von generellen Style Guides halte ich nicht besonders viel, da diese oft viel zu sehr auf details eingehen. Es gibt 1000 Styles und jeder hat seine Vorteile und Nachteile.

Im Endeffekt muss man sich bei Projekten eh an Style Vorgaben fremder Leute halten, selbst wenn man den (für einen persönlich) ekelhaftesten Style programmiert, den man sich nur ausdenken kann (zB. mit ungarischer Notation ;))

@Optimizer
hättest du mein Post gelesen, wüsstest du, dass ich getter und setter nicht mit get/set benenne. Nun erklär mir mal, wie ich den Namenskonflikt mit this lösen soll.

In der Regel sollten Datenelemente gar nicht von außen zugänglich sein.

und was hat das mit dem zu tun, was ich geschrieben habe? Wenn diese nach außen zugänglich wären, hätte ich es ja sicher nicht nötig getter/setter zu schreiben und bräuchte auch kein _m anhängen. Findest du nicht?

[Jover]

Letzte Frage:

Wie schreibt ihr Variablenname?
Ist isInitialised besser als is_initialised?

Sollte man alles klein, dafür einzelne Wörter mit nem Unterstrich ternnen?
Oder ist erste Wort klein und alle anderen Groß beginnen besser?

[DrGreenthumb]

hab ich grad hier geschrieben: http://www.c-plusplus.net/forum/viewtopic.php?p=411182#411182

[volkard]

DrGreenthumb schrieb:

hab ich grad hier geschrieben: http://www.c-plusplus.net/forum/viewtopic.php?p=411182#411182

und ich hab vor deine meinung scharf gewarnt.