Bezeichnungen - Euer stil

wie bezeichnet ihr variablen, klassen, zeiger, referenzen, klassenelemente, etc.? Da ich noch am lernen bin und mir zugleich auch einen programmierstil aneignen möchte, wollte ich euch fragen ob ihr meinen folgenden ok findet oder was ihr anderst machen würdet? ich mache das bisher so:

Klassen
class CExample

Funktionen
Ohne prefix jedoch immer in grossschrift geginnend.

Variablen
Immer mit grossschrift beginnend und:
int iExample
char cExample
string strExample

Klassenelemente
Genau wie bei "Variablen" jedoch immer mit dem prefix m_ (steht für member)

Zeiger
*pExample

Referenzen
&rExample

hab ich was vergessen?

Caipi

Hallo,
Sorry, aber mir sagt dein Stil garnicht zu. Ich würde die Typ-präfixe bei den Bezeichnern weglassen.
Ansonsten kannst du auch mal bei google nach Code-Konventionen oder C++-Konventionen suchen. Dort findest du sicherlich Anregungen zur Namensgebung etc.

Mein Stil der Namensgebung:
Funktionen/Objekte/Variablen/Zeiger/Referenzen: klein und ohne typ-präfix.
Konstanten: groß
Klassen: mit beginnendem Großbuchstaben (z.B. class Vector)
Element-Variablen: klein und ohne das m_.
Präprozessor-Direktiven: groß.

Caipi

net 0

ich finde das am besten: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

Mal grundsätzlich zu Groß-/Kleinschreibung:

PascalCase
Typen

camelCase
Methoden, Funktionen, Variablen (auch Member),

nur groß
Konstante, #defines

nur klein
Namespaces

Benennung:

Allgemein ohne Präfixe (kein i,f,d,str für Variablen; kein m_ für Member; kein C für Klassen; etc ..) und möglichst dem Sinn entsprechend.

Konstanten, #defines
Da sie nur groß sind, wird 'Underscore' (_) als Trenner benutzt.
Beispiel: MAX_WIDTH

Methoden, Funktionen
beginnen mit einem Verb
Beispiel: repairCar(), House::rent()

getter und setter:
Allgemein werden sie entsprechend nach dem Wert der zu setzen, bzw zu lesen ist benannt. Wenn dieser Wert jetzt Value heißt, heißen die entsprechenden getter und setter getValue und setValue. Eine Außnahme wird gemacht, wenn Value vom Typ bool ist. Dann heißen die getter und setter isValue und setValue.

Namespaces
Die haben bei mir immer einen so kurzen Namen, das sie gar keinen Trenner benötigen.
Beispiel: lib::gui::Button

Zu dem Thema Präfix ja/nein kannich immer wieder nur sagen, dass es einfach nicht zeitgemäß ist mit dem Editor oder ähnlichem zu programmieren. Bei jeder halbwegs guten IDE muss ich nur den Cursor auf die gewünschte Variable, Klasse, etc.. setzen und es erscheint eine Art ToolTip, welches mir alles anzeigt was ich wissen will. Wozu also so hässliche Bezeichner wählen ..

grüße

Btw. während dem Schreiben hab ich bemerkt, dass auf die Java Conventions verlinkt wurde. Sind klarerweise auch meine 'Inspiration'.

wieso findet ihr die präfixe nicht gut? so erkennt man im code schnell zu welchem typ die variable gehört und ob sie zu einer klasse gehört etc. hmm

z.b. erkennt man so CBaseExample das dies ein klassen objekt ist. BaseExample (ohne ein C) kann von sonst was sein. ok, das ist jetzt nicht gerade zwingend nötig da man spätestens beim compilieren merkt das etwas nicht stimmt, sofern man etwas falsches mit dem/der objekt/variable anstellen wil. desweiteren finde ich die namensvergebung bei zeigern, das beginnen mit einem kleinen p recht nützlich. so weis man gleich das es sich eben um einen pointer handelt.

elise

mir ist dieses C zu sehr mfc
es reicht mir der erste buchstabe groß bei einem selbstdefinierten datentyp.

Caipi

Tekko schrieb:

z.b. erkennt man so CBaseExample das dies ein klassen objekt ist. BaseExample (ohne ein C) kann von sonst was sein. ok, das ist jetzt nicht gerade zwingend nötig da man spätestens beim compilieren merkt das etwas nicht stimmt, sofern man etwas falsches mit dem/der objekt/variable anstellen wil. desweiteren finde ich die namensvergebung bei zeigern, das beginnen mit einem kleinen p recht nützlich. so weis man gleich das es sich eben um einen pointer handelt.

Du wolltest doch Anregungen zu deinem Stil haben. Die hast du bekommen. Jetzt musst du selbst entscheiden, was du für richtig und falsch hälst.
Zu den präfixen gibt es unterschiedliche Meinungen.

Da fragst du wie mans besser machen kann und ignorierst es sowieso wieder.
Wofür fragst du also? Nehm also einfach mal an, dass du ein Troll bist ..

ich hab mit "wieso findet ihr die präfixe nicht gut? " eine frage gestellt und anshcliessend nochmals geäussert warum ich es gut finde. also bitte... und ausserdem musst die nicht das gleiche sagen was Caipi schon abgegeben hat.

volkard

Tekko schrieb:

wie bezeichnet ihr variablen, klassen, zeiger, referenzen, klassenelemente, etc.?

es fehlen template-parameter in der frage.

Da ich noch am lernen bin und mir zugleich auch einen programmierstil aneignen möchte, wollte ich euch fragen ob ihr meinen folgenden ok findet oder was ihr anderst machen würdet?

ich mache es ganz anders. da du am lernen bist, und anregungen suchst, lege ich dir das ein wenig auseinander. ich will dich zu nichts zwingen. das geibt nur glaibenskriege.

Klassen
class CExample

nee. klassen einfach groß beginnend und mit großbuchsaben als worttrenner.

class FileReader{
...
};

das C davor steht für "ich bin von microsoft" und das T davor steht für "ich bin von borland". man machte das damals, um die namensräume des benutzers nicht zu verschmutzen. willste deinen namensraum davon trennen, nimmste konsequenterweise U für user. dann kannste in der gleichen datei TFile, CFile und UFile benutzen. microsoft, mit dem ich viel arbeite, hat so viele schöne namen für sich belegt, daß ich im namensraum, der mit C beginnt, ständig kollisionen hätte. außerdem ist mit der einführung vom schlüsstelwort namespace der prfix als namensraumtrenner überholt.

Funktionen
Ohne prefix jedoch immer in grossschrift geginnend.

nee. die lasse ich alle kleine beginnen.

void raiseAssertError(char const* cond,char const* file,int line);

Zum Zwcke des Trennens von Klassen und Funktionen.

Baum baum;

Ich habe ja keinen namensraum-präfix. da ist diese trennung schon gut.

Variablen
Immer mit grossschrift beginnend und:
int iExample
char cExample
string strExample

nee. wie funktionen. typ-prafixe haben den gravierenden nachteil, daß man sie ändern müßte, wenn man den typ ändert, daß man sie nicht schreiben kann bei templates, und wo weil templates die hälfte des code ausmachen, wäre man ganz gleich durcheiander wie nur was. typ-präfixe sind, wie ich seit 10 jahren (bereits damals, als hier die deutliche mehrheit dafür war) erzähle, mist.

Klassenelemente
Genau wie bei "Variablen" jedoch immer mit dem prefix m_ (steht für member)

nee. genau wie variablen. kein präfix. wenn ich dort ein präfixnehmen würde, dann nur ein _. aber ich nehmen den präfix _ in den wirklich selten fällen, wo ein funktionsparameter mit einem attribut kollidiert für den parameter.

Zeiger
*pExample

nee. kein präfix.

Referenzen
&rExample

nee. kein präfix.

hab ich was vergessen?

ja. wie nennste template-parameter? ich nenne sie seit kurzem wie attribute. auch kompilezeitkonstanten seit kurzem wie variablen.

makros nenne ich durchgehen gross.
naja, außer assert, each2 und each3 und ich habe sonst keine makros zur zeit. ach, ist das peinlich.

wie nennste die dateien und was schreibse rein? stofst du klassen immer in eine Klasse.h oder in eine klasse.h oder eine CKlasse.h? unterscheidest du groß-kleinschrift in dateinamen?

wie lang machste bezeichner?
int findFirstBitTrue(int x)
oder
int ffbt(int x)?

fals globale funktionen nur für die main() da sind, machste immer prototypen und schreibst die definitionen unter die main()?

sind die parameter in den prototypen mit namen versehen?

wieviele zeilen haben deine funktionen so?

wieviele methoden haben deine klassen so?

verbietest du kopieren, wo es geht?

welche bezeichner machste auf deutsch und welche auf englisch?

wo machste kommentare und für wen?

benutzt du assert, isses getuned?

zum speichermanagement und der fehlerbehandlung gäbe es noch einiges.

Tekko schrieb:

ich hab mit "wieso findet ihr die präfixe nicht gut? " eine frage gestellt und anshcliessend nochmals geäussert warum ich es gut finde. also bitte... und ausserdem musst die nicht das gleiche sagen was Caipi schon abgegeben hat.

Und auf die Frage hab ich dir in weiser Voraussicht doch auch bereits geantwortet.

blabla .. schrieb:

Zu dem Thema Präfix ja/nein kannich immer wieder nur sagen, dass es einfach nicht zeitgemäß ist mit dem Editor oder ähnlichem zu programmieren. Bei jeder halbwegs guten IDE muss ich nur den Cursor auf die gewünschte Variable, Klasse, etc.. setzen und es erscheint eine Art ToolTip, welches mir alles anzeigt was ich wissen will. Wozu also so hässliche Bezeichner wählen ..

Außerdem wenn du Präfixe schon durchziehst, dann aber bitte vollständig. Zum Beispiel würd mich doch bei einem Zeiger auch interessieren, welchen Typ er hat.
also machen wir schonmal aus einem pExample zum Beispiel ein piExample. Was machst du bei eigenen Datentypen? Was für Prefixe nimmst du da? Beziehungsweise mich würden doch auch Template-Parameter interessieren, eventuell auch Template-Template-Parameter. Auch nicht schlecht, wär noch dazu die Datei in der es definiert wird (z.B: bei globalen Variablen oder Konstanten). Hmm .. die Basisklassen könnten auch sehr hilfreich sein, kommt also auch irgendwie als Präfix dazu. Ist das jetzt eine abstrakte Klasse, wirklich rein abstrakt im Sinne eines Interfaces oder mit ein paar definierten Methoden auch? Klarerweise müssen wir natürlich auch definieren ob die Methoden jetzt normal, virtual oder abstrakt sind. ....

Kapiert was ich meine? All das sollte mir eine gute IDE anzeigen, da haben Präfixe doch nicht den Hauch einer Chance ..

Blue-Tiger

Tekko schrieb:

z.b. erkennt man so CBaseExample das dies ein klassen objekt ist. BaseExample (ohne ein C) kann von sonst was sein. ok, das ist jetzt nicht gerade zwingend nötig da man spätestens beim compilieren merkt das etwas nicht stimmt, sofern man etwas falsches mit dem/der objekt/variable anstellen wil. desweiteren finde ich die namensvergebung bei zeigern, das beginnen mit einem kleinen p recht nützlich. so weis man gleich das es sich eben um einen pointer handelt.

Wenn man Klassennamen immer mit Grossbuchstaben beginnen laesst, erkennt man das auch:

BaseExample myExample;

BaseExample ist eine Klasse, weils mit Grossbuchstaben anfaengt, myExample ist eine Variable, weil sie camelCase ist

Das Problem mit Prefixen:
stell dir vor, du schreibst ein Programm, indem du iCounter als Counter benutzt. Und irgendwann bemerkst du, dass der Counter doch bis 60.000 zaehlen soll und daher ein Integer nicht ausreicht. Und damit du aus "iCounter" einen long-Wert machen kannst, musst du ueberall dort, wo du bisher "iCounter" geschrieben hast, jetzt auf einmal "lCounter" schreiben. Umstaendlich, oder?

Reyx

@Tekko
In großen Teilen würde ich sagen ist dein Stil kein eigener Stil sondern ein leicht abgewandter Abklatsch der ungarischen Notation. Zumindest finde mich in meinem Quellcode immer gut intuitiv zurecht, und wenn mal etwas nicht ganz klar ist, gibt es immer noch die guten alten /* Kommentare */.

Am ende müsste dann ja ständig nachdenken, welcher Typ war denn das jetzt, und welche Klasse und... außerdem gibt es verdammt viele aliase (typedef's) und eigene Datentypenklassen, da ist dein Stil sofort über den Haufen geworfen... oder du endest bei sowas:

unsigned int uiMyInt;
signed int siMyInt;
unsigned long ulMyLong;
signed Ling slMyLong;
char cMyChar;
char* cpMyChar
// usw.

Du kannst mir nicht erinsthaft weismachen, dass das die Übersichtlichkeit fördert!?

volkard

Reyx schrieb:

@Tekko
In großen Teilen würde ich sagen ist dein Stil kein eigener Stil sondern ein leicht abgewandter Abklatsch der ungarischen Notation. Zumindest finde mich in meinem Quellcode immer gut intuitiv zurecht, und wenn mal etwas nicht ganz klar ist, gibt es immer noch die guten alten /* Kommentare */.

kommetiere besser nur mit //.
denn /* / ist perfekt zum auskommetieren von code-bereichen zwecks debugging. insbesondere wenn man einen ziffernblock hat, da liegen / und * so nebeneinander, daß man / / sehr fein tippen kann. leider sind kommetare mit / / überhaup nicht verschachtelbar, womit du die auskommentierung zu debug-zwecken verunmöglichst, wenn du im normalen code / */ zum erläutern benutzt.

Reyx

volkard schrieb:

kommetiere besser nur mit //.
denn /* / ist perfekt zum auskommetieren von code-bereichen zwecks debugging. insbesondere wenn man einen ziffernblock hat, da liegen / und * so nebeneinander, daß man / / sehr fein tippen kann. leider sind kommetare mit / / überhaup nicht verschachtelbar, womit du die auskommentierung zu debug-zwecken verunmöglichst, wenn du im normalen code / */ zum erläutern benutzt.

Außer man ist so'n verkappter Borländer wie ich, und schaltet in seinen Compiler-Optionen verschachtelte Kommentare ein
Ne, schon klar, dass war nur um das Wort demonstrativ "einzuschließen"; In der Praxis verwende ich natürlich //

finix

volkard schrieb:

Klassenelemente
Genau wie bei "Variablen" jedoch immer mit dem prefix m_ (steht für member)

nee. genau wie variablen. kein präfix. wenn ich dort ein präfixnehmen würde, dann nur ein _. aber ich nehmen den präfix _ in den wirklich selten fällen, wo ein funktionsparameter mit einem attribut kollidiert für den parameter.

Wäre es nicht konsistenter entweder jedem Attribut ein Prä- oder Suffix zu spendieren oder für die Fälle der Überdeckung die Attribute via this anzusprechen?
Machst du das schon länger? Irgendwelche "Probleme" damit aufgetaucht bisher? (Durch neue Methoden etc.)

volkard schrieb:

hab ich was vergessen?

ja. wie nennste template-parameter? ich nenne sie seit kurzem wie attribute. auch kompilezeitkonstanten seit kurzem wie variablen.

Du meinst Template-Parameter wie Klassen? Oder wirklich wie Attribute?
Gibt's für die lowerCaseKonstanten eine Begründung?

Für volkards Katalog der Glaubensfragen:
- welchen Bracing-Style verwendest du?
- die Klammern zu if/for/while wie bei Funktionen?
- oder gar ein space zwischen Funktionsname und Klammern?

Dazu noch eine ernsthafte Frage:
- Ist dein Coding-Style dokumentiert? (Selber aufgeschrieben, geklaut, etc)

p.s. Die - offensichtlich - einzig richtige Variante Headerdateien zu benennen ist natürlich Case-Sensitive, genau wie die Klasse: Klasse.hpp

volkard

finix schrieb:

volkard schrieb:

nee. genau wie variablen. kein präfix. wenn ich dort ein präfixnehmen würde, dann nur ein _. aber ich nehmen den präfix _ in den wirklich selten fällen, wo ein funktionsparameter mit einem attribut kollidiert für den parameter.

Wäre es nicht konsistenter entweder jedem Attribut ein Prä- oder Suffix zu spendieren

ja, wäre konsistenter. aber ich mag mir auch keinen wolf tippen. und vor allem mag ich kein augenkrebs bekommen.
ich schrieb gestern

Size const size=256;
        char buffer[size];
        DWORD len=FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM,0,error,0,buffer,size,0);
        if(len==0)
            out<<"SystemError "<<error;
        out<<buffer;

während ich das so lese ist es (und sollte es sein!) mir wurstegal, ob error ein attribut ist oder ein parameter. die herkunft der variablen ist schlicht unwichtig, der code selber muss korrekt sein, egal woher sie kommt. außerdem ist ein herkunftsprefix doch auch nur eine verletzung des "der name soll den inhalt beschreiben, nicht den typ"-gebotes, das neuerdings als UN-gegenargument fluktuiert.

oder für die Fälle der Überdeckung die Attribute via this anzusprechen?

die fälle sind normalerweise irrelevant.

SystemError(DWORD _error){
        error=_error;
    }

habe mich da ans _ gewöhnt und habe auch keine probleme. es kommt auch nur in konstruktoren vor. außer neulich. da war was. mal suchen...
jo, hier:

template<typename T,Size size=0,bool onHeap=size==0>
class Vector{
...
    friend void* operator new(Size _size,Vector& v){
        assert(_size==sizeof(T));
        assert(v.end!=v.data.getEnd());
        return v.end++;
    }

da ich template-argumente nicht mehr GROSS schreibe, hat's hier einen warnungsfehler gegeben, weil der funktiopns-parameter den template-parameter überdeckt hat. im moment tue ich diesen fall als unwichtig ab. aber er hat mir schon weh getan, weil ich _ sonst nur in konstruktoren benutze. mal schauen, ob's schlimmer wird mit den kollisionen.

Machst du das schon länger? Irgendwelche "Probleme" damit aufgetaucht bisher? (Durch neue Methoden etc.)

mindestens seit dem 23.08.02. keine probleme bisher. ob es zu problemen kommt bei kleingeschiebenen template-parametern, muß ich noch sehen.

volkard schrieb:

ja. wie nennste template-parameter? ich nenne sie seit kurzem wie attribute. auch kompilezeitkonstanten seit kurzem wie variablen.

Du meinst Template-Parameter wie Klassen? Oder wirklich wie Attribute?
Gibt's für die lowerCaseKonstanten eine Begründung?

ups. statt "wie variablen" soll da stehen "wie variablen bzw. klassen". also

template<typename T,Size size,bool onHeap>
class Array{
...

also nicht mehr GROSS. bis vor kurzem waren template-parameter und andere compilezeitkonstanten GROSS, so als seien sie wie ein makro. aber ich denke, das stört. muß ja eigentlich egal sein, woher ein wert oder ein typ kommt.

pumuckl

Bei mir siehts folgendermaßen aus:
Prefixes: garnicht, höchstens mal bei Templateparametern ein T vorweg udn selten mal ein p bei Pointern. Ungarische Notation bzw. Prefixes, die einen Typen angeben, sollten eigentlich nicht nötig sein, da der Typ jeder Variablen schließlich irgendwo deklariert worden ist.
Schreibweisen:
- Klassen, structs und andere Typen (z.B. typedefs): beginnend mit Großbuchstaben und Worttrennungen mit Großbuchstaben. z.B. MyClass, FreakyExampleClass
- Membervariablen: beginnend mit einen Unterstrich, dann klein und Worttrennungen mit Großbuchstaben, z.B. _xPosition, _totalSize
- andere Variablen: genauso, nur ohne den Unterstrich.
- Funktionen u. Methoden: klein anfangen, Worttrennungen mit Unterstrich, z.B.:
my_tiny_function()

zwischen Variablen und referenzen mach ich keine Unterschiede...

volkard

ich hab mei mir noch was wichtiges vergessen.
funktionsnamen sind immer verben. also getBegin() heißt eindeutig, daß ein anfangsding irgendwie geholt wird und begin() heißt eindeutig, daß was anfangen soll.