Lasst ihr beim einrücken 3 oder 4 Plätze frei
-
Tabs, auf 4 Leerzeichen eingestellt.
-
Meine geschweiften Klammern setze ich direkt hinter die Funktion/Klassendeklaration.
Ein Tab für jeden weiteren block.bool f(){ return true; } int main(){ if(f()){ std::cout << "Hello World!" << std::endl; } return 0; }Und ich weiss nicht wieso,aber sowas:
int main() { return 0; }finde ich ziemlich hässlig.
-
- Tab mit 4 Zeichen
- immer Extrazeile für geschweifte Klammern
- links und rechts ein Leerzeichen bei runden Klammernvoid TestFunktion ( int i, int j ) { TestFunktion ( i, j ); }
-
It0101 schrieb:
- Tab mit 4 Zeichen
- immer Extrazeile für geschweifte Klammern
- links und rechts ein Leerzeichen bei runden Klammern
-
It0101 schrieb:
- Tab mit 4 Zeichen
- immer Extrazeile für geschweifte Klammern
- links und rechts ein Leerzeichen bei runden Klammernvoid TestFunktion ( int i, int j ) { TestFunktion ( i, j ); }dito.
mfg,
julian
-
außer wenn in der Klammer nur eine Sache steht!
getint( lol ) finde ich hässlich
getint(lol) ist da besser
-
int name (int bla) { if (bla > 2) return (bla + name (bla-1)); else return 2; }das rockt viel mehr ;P
bb
-
void testFunktion( int i, int j ) { testFunktion( i, j ); }so is besser
-
So mach ich es (
return-Anweisungen inmain()lass ich grundsätzlich weg, weil überflüssig):void DoThis(int& x, float y) { // ....... } int main() { int i; if (Condition) DoThis(i, 3.2f); else DoThat(); }
-
void DoThis(int& x, float y) { // ....... } int main() { int i; if(Condition) DoThis(i, 3.2f); else DoThat(); return 0; }
-
Beim Einrücken lasse ich entweder 4 oder bei hoher Schachteltiefe 2 Plätze frei. Einen finde ich zu wenig sichtbar und 3 wäre einfach nur ungewohnt. Mehr als 4 wirkt wieder zu weit auseinander gerissen.
Bei den geschweiften Klammern finde ich die zeilenverschwendende Variante übersichtlicher und schöner.
Was die runden Klammern angeht, habe ich bisher keinen optimalen Stil gefunden.
Da gibt es:if(!(x>0)){... if( !(x>0) ){... if (!(x>0)) {... if ( !( x>0 ) ) {...Keines gefällt mir richtig.
-
3.84
-
if (!(x > 0)) { // }immer eins ausßer bei klammern

-
Zwischen Operatoren mit niedriger Priorität wie &&, || sowie den Vergleichsoperatoren <, >, <=, >=, ==, != lasse ich immer Abstände (bei langen If-Bedingungen sogar zwei). Bei sehr langen If-Abfragen, bei denen viele Bedingungen per || oder && verknüpft sind, verteile ich die einzelnen Bedingungen auf mehrere Zeilen und schreibe am Zeilenanfang den Operator (&& oder ||). Bei Additionen und Subtraktionen meistens auch einen Abstand, ausser wenn es in der Indexklammer steht, dann finde ich es hässlich. Wenn im gleichen Ausdruck noch Multiplikationen oder Divisionen vorkommen, schreib ich diese näher aneinander, um die Priorität zu betonen.
Zudem schreib ich meistens bei Funktionsdefinitionen (auch von Methoden) vorher eine Zeile Kommentar, die beschreibt, was die Funktion macht. Das sieht man dann schön im IntelliSense.
Bei Klassen rücke ich die Zugriffsspezifizierer auch ein, weil ich das übersichtlicher finde, und "zugriffsneutrale" Anweisungen wie Friend-Deklarationen auf der gleichen Zeile schreiben kann. Oft trenne ich Variablen und Methoden noch zusätzlich durch eine Zeile, bei vielen Methoden trenne ich diese auch nach Aufgabenbereichen.
bool TestExpr(bool Expression); // Klasse für Demonstrationszwecke class MyClass { // Friend-Deklarationen friend bool TestExpr(bool Expr1, bool Expr2, bool Expr3); public: // Öffentliche Funktionen void DoThis(int& x, float y); // Statische Konstanten static const float Value; enum Type { T1, // so ein Typ T2, // ein anderer Typ T3 // ein ganz spezieller Typ }; private: // Private Member int Var; double AnotherVar; // Private Methoden void DoSomethingInternally(); bool VerySecretMethod(); }; // -- Hier beginnt normalerweise die CPP-Datei -- // Definition statische Variablen const float MyClass::Value = 245.42f; // Weist x den Member Var zu und macht mit y eine sinnlose Berechnung. void MyClass::DoThis(int& x, float y) { x = Var; static_cast<int>(x + 27*y)/x - 40; } // Überprüft die drei Bedingungen und gibt einen entsprechenden boolschen Ausdruck zurück. bool TestExpr(bool Expr1, bool Expr2, bool Expr3) { return (Expr1 || !(Expr2 && !Expr1) || (Expr3 != Expr1)) && Expr3; // ich weiss, das ist nicht logisch, es geht ja nur um die Darstellung. // Klammern setzte ich zur besseren Übersichtlichkeit, obwohl einige überflüssig sind. } int main() { int Number; bool x = true; bool y = false; bool z = true; MyClass A; // Überprüft das Verhältnis von x, y, z und bearbeitet A dementsprechend. if (TestExpr(x, y, z)) { A.DoThis(Number, 3.2f); } else { A.DoThis(Number, 4.6f); A.DoThat(); } }
-
Einrücken sind bei mir 2 Spaces und geschwungene Klammern nicht in eine neue Zeile!
int foo() { return 100; }P.S. Wer das anders macht ist vom Teufel besessen!
-
rüdiger schrieb:
P.S. Wer das anders macht ist vom Teufel besessen!
wenn dem so ist, bin ich äusserst gerne vom teufel besessen

-
Tabs, auf Laenge 4 eingestellt. Geschweifte Klammern in einer eigenen Zeile (obwohl ich z. Z. ueberlege, das umzustellen).
-
Dem schließe ich mich an

-
Labutator schrieb:
Meine geschweiften Klammern setze ich direkt hinter die Funktion/Klassendeklaration.
bool f(){ return true; } int main(){ if(f()){ std::cout << "Hello World!" << std::endl; } return 0; }BRRRRRR GRRRRRR SDFJASDÖKLFJAÖSKLDF!
Boa ist das hässlich
Ehrlich, dann doch gleich so:bool f(){ return true; } int main(){ if(f()){ std::cout << "Hello World!" << std::endl; } return 0; }Noch unübersichtlicher! Juhu!
Jaja, so unterschiedlich sind wir
MfG
-
Ich finde öffnende geschweifte Klammern auf der selben Zeile nicht nur unübersichtlich, sondern auch unschön, aber das ist natürlich Geschmackssache.
Ausnahme: Bei sehr kurzen Funktionen (evtl. inline) kann es legitim sein, obwoh ich das selber eigentlich nicht mache:
int Function() { return 21452; }Was ich aber wirklich hässlich finde, ist das (einschliesslich den fehlenden Abständen bei Operationen):
int Function() { int x=2242; x*=2 return x; }