Codeorganisation (c/c++)



  • So macht man das:

    #define begin {
    #define end }
    
    if (a < b)
    begin
    //...
    end
    

    🤡



  • _matze schrieb:

    shuriko schrieb:

    Ich favorisiere auch die 1. Version. Aber die andere Kollegen bestehen hartnäckig auf der 2. Variante. Sie meinen, dass es überichtlicher ist... 🙄

    Genau! Lass dir nix einreden. Variante 1 rules!

    Ich verwende seit Jahren schon den vim-Editor, nun kann man bei dem zwischen den Klammern springen:

    shift+%

    und da habe ich meine Übersichtlichkeit immer! 🕶 Mich stören aber diese Krücken mit:

    {
    
     ...
    
    }
    

    Ich bin leider allein (1 gegen 20) in diesem Bereich. Kann ich unter unix im vim die ganze "übersichtliche" Formatierung in eine normale umwandeln?

    Danke.



  • Tachyon schrieb:

    So macht man das:

    #define begin {
    #define end }
    
    if (a < b)
    begin
    //...
    end
    

    🤡

    👎



  • shuriko schrieb:

    if (a < b) {
      
      ...
    
    }
    

    die einsame klammer am ende sieht doch völlig hirnamputiert aus. warum nicht gleich so:

    if (a < b) { ... }
    

    ?
    🙂



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

Anmelden zum Antworten