Codeorganisation (c/c++)



  • if(){
     blubb
    }
    


  • PRIEST schrieb:

    if(){
     blubb
    }
    

    na, geht doch 👍
    🙂



  • ~fricky schrieb:

    na, geht doch

    ^^ quatsch. die letzte klammer steht immer noch ganz allein da.
    🙂



  • ^^?

    if(){
     blubb
    }else{}
    

    xD jetzt hast was dran kleben 😃



  • Variant 2! Weil Variante 1 ist so ne Java-Erfindung. 😃



  • TSO schrieb:

    Weil Variante 1 ist so ne Java-Erfindung.

    nein, das haben die urväter von C verbrochen. dafür sollte man sie heute noch ohrfeigen.
    🙂



  • ~fricky schrieb:

    TSO schrieb:

    Weil Variante 1 ist so ne Java-Erfindung.

    nein, das haben die urväter von C verbrochen. dafür sollte man sie heute noch ohrfeigen.
    🙂

    Naja, ich bleibe Persönlich (trotz des drößeren Platzbedarfes bei Variante 2. Der Grund dafür ist folgender:

    // Bei mehreren Anweisung finde ich es fast egal,...
      if(a<b) {
        blubb();
        blubb();
        blubb();
      }
    
      // ...wenn man die Klammern aber bei Einzelanweisungen weglässt,...
      if(a<b)
        blubb();
    
      // ...übersieht man leichter eine Klammer die Ausversehen "rumsteht".
      if(a<b)
        blubb();
      }
    

    Ich habe es lieber auf einer Ebene da auch das Auge beim Lesen weniger springen muss.

    Aber wie gesagt alles Geschmackssache, und für meinen Fall passe ich mich den Projektgegebenheiten an. Hauptsache man rückt ein. Selbst die Varianten mit eigeschobenen Klammern auf Höhe des untergeordneten Codes akzeptiere ich, sofern man sich daran konsequent hält.

    Davon abgesehen Programmiert nicht jeder auf einen 1-Zeilen Monitor 😉 Was interessiert mich die eine Zeile mehr oder weniger?



  • asc schrieb:

    Ich habe es lieber auf einer Ebene da auch das Auge beim Lesen weniger springen muss.

    Das Auge springt aber bei Variante 1 weniger. Da es weniger Zeichen scannen muss. Bei Variante 2 muss es die beiden Klammern matchen (müssen nicht, aber da die Klammern so dominant sind, realisiert das Auge sie auch - obwohl eigentlich unnötig), bei Variante 1 lebt es nur vom Einzug (da es die öffnende Klammer garnicht wahrnimmt).



  • Shade Of Mine schrieb:

    ...bei Variante 1 lebt es nur vom Einzug (da es die öffnende Klammer garnicht wahrnimmt).

    das ist ja das blöde daran. man sieht kaum falsch gesetzten klammern

    if (a < b)
       mach_was(); {
       mach_anderes();
       und_das();
    }
    

    ^^ sieht schön eingerückt aus, aber ob's so sein soll?

    btw, mich wundert's nur, warum die k&r-freaks funktionsaufrufe nicht auch so schreiben:

    k_and_r_sucks (
       123,
       "hello"
    );
    

    das wäre doch wenigstens konsequent.
    🙂



  • ~fricky schrieb:

    das wäre doch wenigstens konsequent.
    🙂

    wer_das_liest_ist_doof
    (
       123,
       "hello"
    );
    

    🙂



  • Bashar schrieb:

    ~fricky schrieb:

    das wäre doch wenigstens konsequent.

    wer_das_liest_ist_doof
    (
       123,
       "hello"
    );
    

    ^^nene, die allman-style code sind da flexibler.
    übrigens, wer c-programmierer mit herz und seele ist, der verwendet den stil der code-beispiele aus dem c-standard.
    🙂



  • Welche Beispiele? Wer C-Standard-Leser mit Herz und Seele ist, blendet den nicht-normativen Teil gedanklich aus.



  • also ich bevorzuge die zweite variante
    allein aus dem grund weil man meiner meinung nach viel schneller sieht welche bloecke wo zusammengehoeren
    in unserer firma ist das auch der interne coding standard

    internal void bla()
    {
        int fasel = 1;
        .
        .
        .
        if(fasel == 1)
        {
            CallSomething(fasel);
            SpuckNicht();
            using(allesNurNichtNextGen)
            {
                der da hinten is haesslich
                .
                .
                .
                der daneben aber auch
            }
        }
    }
    


  • internal void bla() { 
        int fasel = 1; 
        . 
        . 
        . 
    	if(fasel == 1) { 
            CallSomething(fasel); 
            SpuckNicht(); 
    		using(allesNurNichtNextGen) { 
                der da hinten is haesslich 
                . 
                . 
                . 
                der daneben aber auch 
            } 
        } 
    }
    

    Krankheit... 👎 🤡



  • Mr Evil schrieb:

    allein aus dem grund weil man meiner meinung nach viel schneller sieht welche bloecke wo zusammengehoeren

    Ansichtssache. Ich sehe keinen Unterschied, egal ob nun ein if oder eine öffnende Klammer auf derselben Ebene steht wie die schließende Klammer. Ist für mich qualitativ gleichwertig, nur das ich bei ersterem eine Zeile spare (und beim else nochmal zwei!). Aber na ja, diese Diskussion ist wohl so alt wie die Programmiererei an sich... 🙂



  • 😛 hab mir Variante 3 angewöhnt

    void foo()
      {
      bar();
      }
    


  • JustAnotherNoob schrieb:

    😛 hab mir Variante 3 angewöhnt

    void foo()
      {
      bar();
      }
    

    Dein Glück, dass es keinen Würge-Smiley gibt! 😃



  • Warum kann man eigentlich nicht schon lange die Editoren so einstellen, dass sie die Quellcodeformatierung unabhängig von der gespeicherten anzeigen? Dann könnte es jeder so anzeigen lassen wie er will.



  • ~fricky schrieb:

    btw, mich wundert's nur, warum die k&r-freaks funktionsaufrufe nicht auch so schreiben:

    k_and_r_sucks (
       123,
       "hello"
    );
    

    das wäre doch wenigstens konsequent.
    🙂

    Ist doch in jeder Sprache gang und gaebe und zwar im k&r style.
    natuerlich nur bei funktionen die zu lange parameterlisten haben - aber egal welchen stil die leute verwenden, da gehen sie ploetzlich wieder auf k&r.

    aber wie bashar gezeigt hat, mit ( in einer eigenen zeile sieht das ja auch selten daemlich aus.



  • die java c++ flamewars sind eindeutig besser, als die klammersetzungs flamewars


Anmelden zum Antworten