Lasst ihr beim einrücken 3 oder 4 Plätze frei

[helferlein]

if (!(x > 0))
{
    //
}

immer eins ausßer bei klammern

[Nexus]

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();
    }
}

[rüdiger]

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!

[sothis_]

rüdiger schrieb:

P.S. Wer das anders macht ist vom Teufel besessen!

wenn dem so ist, bin ich äusserst gerne vom teufel besessen

[Blue-Tiger]

Tabs, auf Laenge 4 eingestellt. Geschweifte Klammern in einer eigenen Zeile (obwohl ich z. Z. ueberlege, das umzustellen).

[It0101]

Dem schließe ich mich an

[ceplusplus*loggedoff]

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

[Nexus]

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;
    }

[sothis_]

wo wir gerade dabei sind, wer setzt eigentlich runde klammern um den return wert?

[Dravere]

Forum:

#include <iostream>

bool foo() { return true; };

int main(int, char*)
{
  // Zwei Leerzeichen!

  if(foo())
  { std::cout << "hello" << std::endl; }

  return 0;
}

In der IDE:

#include <iostream>

bool foo() { return true; };

int main(int, char*)
{
    // Tabulator (welcher ich im Forum nicht darstellen kann ^^)

    if(foo())
    { std::cout << "Hello" << std::endl; }

    return 0;
}

In Java:

public class CMainClass {

    // Tabulator (welcher ich im Forum nicht darstellen kann ...)

    public static boolean foo() { return true; };

    public static void main(String[] Arguments) {

        if(foo())
        { System.println("Hello"); }
    }
}

Und ja, ich bin vom Teufel bessesen. Schaut ruhig in mein Profil:
Interessen: Computer, Programmierung, Drachen, Mystisches, Rollenspiel

Grüssli

[Nexus]

Dravere schrieb:

bool foo() { return true; };

Wieso eigentlich das Semikolon am Schluss?

Deinen Stil finde ich übrigens gerade noch akzeptabel (obwohl ich es selber lieber übersichtlicher, sprich { und } auf eigenen Zeilen, habe, siehe oben)

Aber wieso schreiben eigentlich soviele return 0; und die main() -Parameter auf, wenn man sie gar nicht benötigt?

[Hungarian?]

Dravere schrieb:

In Java:

public class CMainClass {

Wieso eigentlich das C im Klassennamen?

[Nexus]

Hungarian? schrieb:

Wieso eigentlich das C im Klassennamen?

Wohl, dass man es gerade als Klasse erkennt und schreiben kann:

CMainClass MainClass;

sothis_ schrieb:

wo wir gerade dabei sind, wer setzt eigentlich runde klammern um den return wert?

Das mach ich höchstens bei sehr langen Ausdrücken, aber auch da eher nicht (ich bin diesbezüglich nicht ganz konsequent). Wenn, dann lasse ich aber immer Abstand zwischen return und der öffnenden Klammer. return(x); finde ich hässlich, sieht auch wie ein Funktionsaufruf aus.

[Dravere]

sothis_ schrieb:

wo wir gerade dabei sind, wer setzt eigentlich runde klammern um den return wert?

Nur wenn ich klar hervorheben will, dass zuerst irgendwelche Operationen durchgeführt werden, vor dem return.
Meistens baue ich die Sache aber so, dass dieses klare hervorheben gar nicht nötig ist, denn das sieht meistens scheisse aus ^^

Nexus schrieb:

Wieso eigentlich das Semikolon am Schluss?

Mehr Angewohntheit als Sinn. Ich finde es irgendwie gut, wenn die Einzeiler schön abgeschlossen sind. Semikolon ist ja so ein wenig der absolute Stop der Zeile in C++

Nexus schrieb:

Aber wieso schreiben eigentlich soviele return 0; und die main() -Parameter auf, wenn man sie gar nicht benötigt?

Ich habe es so gelernt und mache es seither immer so. Ich dachte sogar, dass es offziell heisst, dass man es hinschreiben sollte, aber bin mir nicht mehr sicher. Aber wieso weglassen? So ist klar, dass 0 zurückgegeben wird, schliesslich kann man ja auch etwas anderes zurückgeben
Edit: Noch grad gesehen, die main Parameter schreib ich normalerweise nicht auf, das habe ich nur gemacht, damit man sieht, wie ich die Abstände bei Parametern setze

Hungarian? schrieb:

Wieso eigentlich das C im Klassennamen?

Weil ich es LIEBE das folgende schreiben zu können:

class CShip { /* ... */ };

// Irgendwo:
CShip Ship;

Grüssli

[Nexus]

Dravere schrieb:

Nexus schrieb:

Wieso eigentlich das Semikolon am Schluss?

Mehr Angewohntheit als Sinn. Ich finde es irgendwie gut, wenn die Einzeiler schön abgeschlossen sind. Semikolon ist ja so ein wenig der absolute Stop der Zeile in C++

Ok, durchaus verständlich. Aber konsequenterweise müsstest du dann nach jedem Block ein ; schreiben :p

Dravere schrieb:

Nexus schrieb:

Aber wieso schreiben eigentlich soviele return 0; und die main() -Parameter auf, wenn man sie gar nicht benötigt?

Ich habe es so gelernt und mache es seither immer so. Ich dachte sogar, dass es offziell heisst, dass man es hinschreiben sollte, aber bin mir nicht mehr sicher. Aber wieso weglassen? So ist klar, dass 0 zurückgegeben wird, schliesslich kann man ja auch etwas anderes zurückgeben

Ja, aber nicht, wenn das Ende von main() erreicht wird. Bezüglich des Standards bin ich mir selber nicht sicher, aber ich schreib eben nicht so gern überflüssigen Code
Das finde ich etwa gleich unnötig wie das void bei int Function(void); . Eben solche Überbleibsel von C.

[Shade Of Mine]

Dravere schrieb:

Weil ich es LIEBE das folgende schreiben zu können:

class CShip { /* ... */ };

// Irgendwo:
CShip Ship;

deshalb finde ich es zB toll dass meistens folgende Regeln eingehalten werden:

Klassen Namen sind CamelCase.
Variablen beginnen klein: entwederSo oder_so.
Funktionsnamen sind oft unterschiedlich, ich mag es soAmLiebsten aber_auch_so oder GrossAmAnfang ist ok.

Diese Gross-Klein Regeln ermoeglichen einen enorm viel infos ueber den code zu erkennen ohne ihn lesen zu muessen.

Wenn ich zB irgendwo "Foo" sehe, weiss ich was es ist: ein Typ.
Wenn ich "foo" sehe, weiss ich, dass es eine Variable ist.

unheimlich praktisch. und man verschmutzt keine namen. denn das C ist zwar tragbar, aber nur solange man nicht ein I fuer interfaces einfuehrt. Dann wird es haesslich. aber ich verschmutze mir deshalb nie namen wenn es nicht sein muss. denn die namen sind alles was ich habe um meinen code schoen lesbar zu machen.

furchtbar ist deshalb ja auch das design der c++ standard library, aber da muss man halt durch

[Dravere]

Nexus schrieb:

Ok, durchaus verständlich. Aber konsequenterweise müsstest du dann nach jedem Block ein ; schreiben :p

Ja ich weiss, irgendwann gewöhn ich mich noch um ... irgendwann ... Aber das ist ja nicht so schlimm, daher ... SOON (tm)

Dravere schrieb:

..., aber ich schreib eben nicht so gern überflüssigen Code

Da bin ich anderer Meinung. Ich schreib oft gern überflüssigen Code. Denn alles was nicht vorhanden ist, ist im ersten Moment nicht klar. Beim Schreiben von Code ist es viel wichtiger, dass man ihn später wieder schnell versteht, als dass man den Code schnell schreiben kann. Die meiste Zeit verbringt man ja sowieso mit rumdenken, daher ist das egal ein bisschen mehr zu schreiben. Mit der Zeit hat man das auch so verinnerlicht, das geht voll automatisch.
Klar gilt es auch ein wenig sinnvoll zu unterscheiden. Ein void als leerer Übergabeparameter schreib ich auch nicht, da ich es sogar verwirrender finde. Wenn nichts übergeben werden soll, dann soll auch nichts stehen dort stehen

@Shade Of Mine,
Mein Problem bei diesem Stil ist die schlechte Unterscheidung zwischen Funktion und Objekt! Deshalb muss ich ausweichen auf grossgeschriebene Variablen und habe am Ende nichts mehr für die Klassen und muss daher das C einführen:

foo <- Objekt oder Funktion?

Bei mir:
foo <- Funktion!
Foo <- Objekt!
CFoo <- Typ!

I benutze ich nicht, nur ein S für structs, obwohl ich schon länger überlege, ob ich dieses nicht durch ein C ersetzen soll.

Grüssli

[Shade Of Mine]

Dravere schrieb:

Mein Problem bei diesem Stil ist die schlechte Unterscheidung zwischen Funktion und Objekt!

Weil es keinen unterschied gibt.
funktionen _sind_ objekte.
um genau zu sein: funktionen sind konstante functors.
deshalb mag ich es wenn objekte und funktionen gleich benannt werden.

template<typename F>
F foo(F f) {
  f();
  return f;
}

ist f jetzt eine funktion oder ein functor? man weiss es nicht, aber es ist egal. weil eine funktion nur ein spezialfall eines functors ist, mehr nicht.

[drakon]

Nexus schrieb:

Ja, aber nicht, wenn das Ende von main() erreicht wird. Bezüglich des Standards bin ich mir selber nicht sicher, aber ich schreib eben nicht so gern überflüssigen Code

Der Standard schreibt vor, dass die main Funktion, wenn kei Rückgabewert vorhanden ist das gleiche bedeutet, wie return 0;

Sonstige Diskussion:
Mir ist vorhin durch den Kopf, dass es bei der Schreibweise wirklich enorm viel einfacher wäre, wenn es "verbindliche" Regeln geben würde, so, dass man einen Stil hat, der möglichst perfekt ist und vielen passt. Wäre für alle einfacher, da könnte man dann fremden Code lese, als wäre es der eigene und muss nicht zuerst noch überlegen, wie jetzt dem seine Benennung wohl aussieht.

[Nexus]

Da ich meistens nur eigene und eher kleinere Hobby-Projekte habe, wende ich CamelCase fast überall an, weil ich es ästhetisch finde.
Sowas wie anyFunction gefällt mir nicht so. any_function bin ich mir von der Standardbibliothek gewöhnt und finde ich auch vertretbar, wende es selber aber nicht an. Deshalb AnyFunction

Dravere schrieb:

Ja ich weiss, irgendwann gewöhn ich mich noch um ... irgendwann ... Aber das ist ja nicht so schlimm, daher ... SOON (tm)

Ja, schlimm ist es wirklich nicht, und ich denke, das kannst du auch ruhig beibehalten

Dravere schrieb:

Da bin ich anderer Meinung. Ich schreib oft gern überflüssigen Code. Denn alles was nicht vorhanden ist, ist im ersten Moment nicht klar. Beim Schreiben von Code ist es viel wichtiger, dass man ihn später wieder schnell versteht, als dass man den Code schnell schreiben kann. Die meiste Zeit verbringt man ja sowieso mit rumdenken, daher ist das egal ein bisschen mehr zu schreiben. Mit der Zeit hat man das auch so verinnerlicht, das geht voll automatisch.

Vielleicht hab ich mich ein wenig unglücklich ausgedrückt. Code, der das Verständnis erleichtert, schreib ich natürlich auch lieber mehr. Aber return 0; und int argc, char** argv gehören meiner Ansicht nach nicht dazu.

Ich kommentiere beispielsweise relativ oft, und versuche, wenn möglich, komplexe Ausdrücke auf mehrere Zeilen zu verteilen. Ein ++ in einem Ausdruck mit anderen Operatoren findet man bei mir zum Beispiel kaum.

drakon schrieb:

Sonstige Diskussion:
Mir ist vorhin durch den Kopf, dass es bei der Schreibweise wirklich enorm viel einfacher wäre, wenn es "verbindliche" Regeln geben würde, so, dass man einen Stil hat, der möglichst perfekt ist und vielen passt. Wäre für alle einfacher, da könnte man dann fremden Code lese, als wäre es der eigene und muss nicht zuerst noch überlegen, wie jetzt dem seine Benennung wohl aussieht.

Ja, im Grunde genommen kein schlechter Ansatz, aber mir scheint das ein wenig utopisch. Erstens ist es nicht so einfach, einen Stil zu finden, der den meisten passt und zweitens würden sich wohl trotzdem nicht alle dran halten. Oder meinst du ein in der Sprache verankertes Gebot? Also Compilerfehlermeldungen bei falschem Bezeichner?

Ich finde es ehrlich gesagt gut, dass man seinen Stil frei wählen kann. Denn bei einer allgemeingültigen Konvention wäre die Wahrscheinlichkeit gross, dass mir der Stil nicht passt