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

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

  • ?
     

    void testFunktion( int i, int j ) 
{ 
    testFunktion( i, j ); 
}

    so is besser

    0
  • N

    So mach ich es ( return -Anweisungen in main() 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();
}
    0
  • T
     

    void DoThis(int& x, float y)
{
    // .......
}

int main()
{
    int i;

    if(Condition)
        DoThis(i, 3.2f);
    else
        DoThat();

    return 0;
}
    0
  • E

    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.

    0
  • ?

    3.84

    0
  • ?
     

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

    immer eins ausßer bei klammern 🙂

    0
  • N

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

    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!

    0
  • S

    rüdiger schrieb:

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

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

    0
  • B

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

    0

  • Dem schließe ich mich an 🙂

    0
  • C

    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

    0
  • N

    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;
    }
    0
  • S

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

    0
  • Administrator

    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 😉

    0
  • N

    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?

    0
  • ?

    Dravere schrieb:

    In Java:

    public class CMainClass {

    Wieso eigentlich das C im Klassennamen?

    0
  • N

    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.

    0
  • Administrator

    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

    0
  • N

    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.

    0
Anmelden zum Antworten