wie einen pointer kennzeichen

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.

kingruedi schrieb:

@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?

Verstehe dein Problem nicht. Bei Namenskonflikten denke ich an Situationen wie:

class Point
{
    int x, y;

    void setX(int x) // Natürlich kann man auch andere Namen wählen, soll nur ein Beispiel sein
    {
        this->x = x;
    }
}

Wo hast du bitte sonst Namenskonflikte? Wo das m_ was bringen soll?

DrGreenthumb schrieb:

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

Du sollst aus einem anderen Grund int *x schreiben:

int* x, y;   // Was jetzt?!

Aber ok, da sind nicht alle meiner Meinung. Ich weiß, dass ihr das sehr Typbezogen seht, hat ja auch seine Berechtigung.
Will nur mal zum nachdenken anregen

DrGreenthumb

Optimizer schrieb:

DrGreenthumb schrieb:

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

Du sollst aus einem anderen Grund int *x schreiben:
int* x, y;   // Was jetzt?!

Schon klar, das meine ich. Wenn jemand bei der Zeile denkt y wäre auch ein Pointer, hat er Probleme mit der Syntax Wobei das hier natürlich sehr undeutlich ist. Aber sowas schreib ich auch nicht. In so einem Fall bekommt y eine eigene Zeile.

DrGreenthumb

Kingruedi meint eher Namenskonflikte wie die:

class Point
{
private:
  int x;

public:
  int x() const;
};

DrGreenthumb schrieb:

Kingruedi meint eher Namenskonflikte wie die:
class Point
{
private:
  int x;

public:
  int x() const;
};

Ok, ok. Deshalb meine persönliche Konvention:
getX(), setX()

Ich sehe für m_ nach wie vor keinen Grund.

operator void

Wenn du getX() ausschließlich deshalb verwendest, hast du dir das "m_" gespart und musst dafür öfter "get" schreiben. Andersrum könnte ich sagen, dass es keinen Grund für "get" gibt, weil durch "m_" doch schon alles eindeutig ist...