Bezeichnungen - Euer stil

finix schrieb:

Falsch: foo (bar)
Richtig: foo(bar)

Falsch: if(foo)
Richtig: if (foo)

Falsch: Finix
Richtig: finix

Wieso? Was hast du an meinem if( foo ) auszusetzen? Irgendwann habe ich mal erkannt, dass die Klammern beim Lesen einfach nur stören, wenn sie am Ausdruck angrenzen, insbesondere, wenn im Ausdruck selber Klammern vorkommen. Ein

if( myCar->isDamaged() )

ist bestimmt nicht schlechter lesbar als

if (myCar->isDamaged())

Man könnte ja auch mal ein

if (something  >  x * (y + getValue()))

haben. Jetzt kann mir keiner mehr erzählen, dass das nicht ugly ist.
Du magst auch deine Gründe haben, aber von "richtig" und "falsch" zu sprechen halte ich für gewagt.

net schrieb:

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

Die sind für mich gestorben. Die wollen mir mein if anders vorschreiben als ich es mag. Außerdem kann ich

Note: if statements always use braces {}. Avoid the following error-prone form:
if (condition) //AVOID! THIS OMITS THE BRACES {}!
    statement;

definitiv nicht zustimmen. Unnötige Klammern sind hässlich und unübersichtlich. Zwar ist es wahrscheinlich nicht so schlimm, wenn man die öffnende noch auf der selben Zeile beginnt. Aber andererseits habe ich noch nie einen Fehler wegen einem if ohne { } gemacht.

Die Namensgebung laut Java-Konvention finde ich allerdings wieder gut. Die beinhaltet dann auch so Sachen, die volkard schon angesprochen hat, z.B. dass Methoden Verben sein sollten.

volkard

otze schrieb:

Nun ist es aber so, dass die eigenen Code Conventionen dahin gehen zb getBegin() zu schreiben, oder das Iterator Typedef Iterator und ConstIterator zu nennen. Sollte man sich nun der Stl wiedersetzen, und seine Code Konvention durchsetzen, oder sollte man sich der Einheitlichkeit zuliebe anpassen?

wenn du die stl auch benutzen willst, anpassen.
ich wende mich von ihr ganz ab und darf machen, was ich will.

finix

Optimizer schrieb:

finix schrieb:

Falsch: foo (bar)
Richtig: foo(bar)

Falsch: if(foo)
Richtig: if (foo)

Falsch: Finix
Richtig: finix

Wieso? Was hast du an meinem if( foo ) auszusetzen? Irgendwann habe ich mal erkannt, dass die Klammern beim Lesen einfach nur stören, wenn sie am Ausdruck angrenzen, insbesondere, wenn im Ausdruck selber Klammern vorkommen. Ein
if( myCar->isDamaged() )
ist bestimmt nicht schlechter lesbar als
if (myCar->isDamaged())
Man könnte ja auch mal ein
if (something  >  x * (y + getValue()))
haben. Jetzt kann mir keiner mehr erzählen, dass das nicht ugly ist.
Du magst auch deine Gründe haben, aber von "richtig" und "falsch" zu sprechen halte ich für gewagt.

Jetzt hast du 2 Dinge unzulässig verquickt. Mir ging es allein um das Leerzeichen zwischen if und (, nicht um ( und expression.

Bezüglich "richtig" und "falsch": ich habe in beiden Posts von 'Glaubensfragen' geschrieben, oder?
(Obwohl in der Tat ersteres - in meinen Augen - in der Tat & offensichtlich schlechter zu lesen ist.)

User-- schrieb:

Das Thema kommt mir sehr gelegen, denn ich musste feststellen, dass fast jeder die camel notation verwendet (ich selbst auch), jedoch habe ich in letzter Zeit auch ein wenig mit der underscore notation, wie sie ja die standard lib verwendet, geliebäugelt und in einem aktuellen (kleineren) Projekt mal eingesetzt und irgendwie sagt mir diese sogar sehr zu.

Aber was mich interressiert ist, wieso sie so gut wie niemand verwendet, obwohl sie der standard zB. hat

ISO/IEC 9899:1999 schrieb:

7.1.3 Reserved identifiers
1 Each header declares or defines all identifiers listed in its associated subclause, and
optionally declares or defines identifiers listed in its associated future library directions
subclause and identifiers which are always reserved either for any use or for use as file
scope identifiers.
— All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.

Brutus

Es ging um so etwas:

void my_sex_machine();
// statt
void mySexMachine();

und nicht um sowas:

__sex_machine bla;

ISO/IEC 9899:1999 schrieb:

7.1.3 Reserved identifiers
1 Each header declares or defines all identifiers listed in its associated subclause, and
optionally declares or defines identifiers listed in its associated future library directions
subclause and identifiers which are always reserved either for any use or for use as file
scope identifiers.
— All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.

Ist das nicht a) die falsche Pappe? Dies ist doch hier C++, und nucht C, und da gilt ja wohl ISO/IEC 14882-1998 respektive 2003, und da ist sind Bezeichner mit einem Unterstrich gefolgt von kleinem Buchstaben nicht reserved (wenn auch nicht empfohlen) und b) da auf stl werwiesen wurde, geht es hier wohl eher um Unterstriche innerhalb von Identifiern und nicht zu Beginn, also weiss ich gerade garnicht womit das was zu tun haben soll?

pumuckl

otze schrieb:

Nun ist es aber so, dass die eigenen Code Conventionen dahin gehen zb getBegin() zu schreiben, oder das Iterator Typedef Iterator und ConstIterator zu nennen. Sollte man sich nun der Stl wiedersetzen, und seine Code Konvention durchsetzen, oder sollte man sich der Einheitlichkeit zuliebe anpassen?

Kommt ganzd rauf an. Wenn du nicht vorhast, deine Schnittstellen (und typedefs etc.) großartig weiterzuverteilen, dann dürfte deine eigene Konvention genügen. Wenn du allerdings eindeutig an die STL angepasste Klassen schreibst (z.B. um mit irgendwelchem Kram aus <algorithm> drauf zu arbeiten etc.), dann kommst du nicht umhin, deine Schnittstellen STL-konform zu machen, und falls du deine Klassen in Form von libs o.ä. weiterverbreitest und sie größtenteils STL-ähnlich sind, wäre es bestimmt eine Überlegung wert, deine Schnittstellen vollständig STL-konform zu machen, um der Bequemlichkeit der User genüge zu tun (User hassen es wenn sie für alles eine Wrapperklasse schreiben müssen ). Dann solltest du allerdings alles so liefern, wie es in der STL geliefert wird und nicht nur teilweise.

Schlimmstenfalls besteht ja auch problemlos die Möglichkeit, beides anzubieten, auch wenn das eine unnötig vergrößerte Schnittstelle bedeutet:

typedef /*was auch immer dein iterator ist*/ ConstIterator;
typedef ConstIterator const_iterator; //für STL-konformität

//...

ConstIterator getBegin();
const_iterator begin() { return getBegin(); }; //für STL-konformität

rüdiger

Verwundert schrieb:

ISO/IEC 9899:1999 schrieb:

7.1.3 Reserved identifiers
1 Each header declares or defines all identifiers listed in its associated subclause, and
optionally declares or defines identifiers listed in its associated future library directions
subclause and identifiers which are always reserved either for any use or for use as file
scope identifiers.
— All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.

Ist das nicht a) die falsche Pappe? Dies ist doch hier C++, und nucht C, und da gilt ja wohl ISO/IEC 14882-1998 respektive 2003, und da ist sind Bezeichner mit einem Unterstrich gefolgt von kleinem Buchstaben nicht reserved (wenn auch nicht empfohlen) und b) da auf stl werwiesen wurde, geht es hier wohl eher um Unterstriche innerhalb von Identifiern und nicht zu Beginn, also weiss ich gerade garnicht womit das was zu tun haben soll?

http://www.c-plusplus.net/forum/viewtopic-var-t-is-39461.html schrieb:

17.4.3.1.2 Global names
1 Certain sets of names and function signatures are always reserved to the implementation:

* — Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase
letter (2.11) is reserved to the implementation for any use.
* — Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.165)

Ich benutz übrigend den STL Stil. Ich find das irgend wie lesbarer, wenn das einheitlich ist, als so ein gewurschtel. Ob CamelCase so viel lesbarer ist waage ich auch mal zu bezweifeln.

Wobei Großbuchstaben am Klassenanfang sind praktisch, da es zu oft vorkommt, dass die sinnvollste Bezeichnung für ein Objekt die gleiche Bezeichnung ist wie der Klassename

Also ich bin auch schwer dafür Typen groß beginnen zu lassen, namespaces dagegen klein, ebenso variablen und methoden, globale Funktionen schreib ich jedoch groß am Anfang.

Ich mag camel case zu nem gewissen Grad, aber manchmal wider es mich auch einfach an und underscore ist zZ zwar mal ne Abwechslung aber auch nicht die Lösung.

Aber das einzig wirklich wichtige ist ja, dass man ein Projekt einheitlich formatiert.