Codeorganisation (c/c++)



  • Ich finde, es geht hier nicht um die Geschmackssache oder Vorliebe, sondern, es geht um eine Art Phylosophie oder Strategie, bei der man vermeiden möchte, viel Zeit am Debugger zu verbringen. Was nützt einem ein kompakter Code, wenn man keine gute Stelle findet, wo man ein Breakpoint setzen könnte, oder bevor man ein Breakpoint setzt, zweimal hinschauen muss, dass man die richtige Zeile erwischt? (vielleicht werde ich alt...)
    Bei der ersten Methode finde ich sogar, dass der Programmierer mit Absicht seine Fehler im Code verstecken möchte. Bei der zweiten dagegen kostet es etwas Überwindung, sie zu benutzen, weil der Code dann "bloss gestellt ist", man sieht plötzlich alles und befürchtet vielleicht dann, dass der Reviewer etwas bemerkt - was im Prinzip gut wäre, bevor der Code freigegeben wird.



  • abc.w schrieb:

    Ich finde, es geht hier nicht um die Geschmackssache oder Vorliebe, sondern, es geht um eine Art Phylosophie oder Strategie, bei der man vermeiden möchte, viel Zeit am Debugger zu verbringen. Was nützt einem ein kompakter Code, wenn man keine gute Stelle findet, wo man ein Breakpoint setzen könnte, oder bevor man ein Breakpoint setzt, zweimal hinschauen muss, dass man die richtige Zeile erwischt? (vielleicht werde ich alt...)
    Bei der ersten Methode finde ich sogar, dass der Programmierer mit Absicht seine Fehler im Code verstecken möchte. Bei der zweiten dagegen kostet es etwas Überwindung, sie zu benutzen, weil der Code dann "bloss gestellt ist", man sieht plötzlich alles und befürchtet vielleicht dann, dass der Reviewer etwas bemerkt - was im Prinzip gut wäre, bevor der Code freigegeben wird.

    😮
    Meinst du das etwa ernst? Dein Posting ist eigentlich der Beweis dafür, dass dies reine Geschmackssache ist. Denn ich empfinde es gar nicht so wie du. Mir geht da keine Übersicht flöten, sondern ich gewinne imho Übersicht. Und erst recht verstecke ich nix. Dein Statement ist nun wirklich vollkommen subjektiv und selbst von dieser Warte völlig übertrieben.

    Tatsache ist doch, dass das Wichtigste für die Übersicht und Lesbarkeit des Codes das Einrücken ist, und das machen alle hier aufgeführten Varianten. Insofern akzeptiere ich auch alle (obgleich ich persönlich eben Variante 1 bevorzuge). Das solltest du auch tun.



  • Was haltet ihr denn vom Pico-Style?

    if (a < b)
    { x = a + b;
      y = b; }
    

    😃

    @abc.w: Ich kann ehrlich gesagt nichts von dem was du sagst nachvollziehen.



  • Tim schrieb:

    Was haltet ihr denn vom Pico-Style?

    if (a < b)
    { x = a + b;
      y = b; }
    

    schrecklich - zerschiesst jegliche vernuenftige einrueckung #gg



  • BorisDieKlinge schrieb:

    ich benutze auch immer variante 1.. wobei ich im fremden code zu 99% variante 2 sehe... d.h. 99% der Programmierer sind bettnässer?

    Diese Quote fällt bei mir zwar niedriger aus, aber in der Praxis habe ich bislang auch eher die 2te Variante gesehen (grob geschätzt: 2 70%, 1 25% und Andere Varianten 5%).

    Ich habe mehrere Stile ausprobiert und den 2ten als - für mich - am besten lesbar angesehen. Auf der Arbeit verwende ich aber eine Mischung aus 1 und 2 (Projektstil), Bei Klassen und Funktionen liegt das Äußerste Klammernpaar auf einer Höhe, ansonsten gilt Stil 1.

    cu André



  • Tim schrieb:

    Was haltet ihr denn vom Pico-Style?

    Garnichts. Zum Glück auch noch nicht in der Praxis gesehen.



  • abc.w schrieb:

    Bei der ersten Methode finde ich sogar, dass der Programmierer mit Absicht seine Fehler im Code verstecken möchte. Bei der zweiten dagegen kostet es etwas Überwindung, sie zu benutzen, weil der Code dann "bloss gestellt ist", man sieht plötzlich alles und befürchtet vielleicht dann, dass der Reviewer etwas bemerkt - was im Prinzip gut wäre, bevor der Code freigegeben wird.

    Andersrum. Ausführlicher, pseudo-übersichtlicher Code ist so langweilig, dass man beim Lesen einschläft und Fehler übersieht.



  • einschlafen ? kein kaffee da ? #gg



  • Mr Evil schrieb:

    "scriptkiddys bevorzugen variante 1 weil man so profesionalitaet und komplexitaet vortaeuschen kann - schaut halt professioneller aus...

    kann sein. sie glauben wohl, dass nur sehr erfahrene coder k&r benutzen. so'n archischen stil können nur leute, die seit den 70'er jahren in C programmieren. und wer das nachmacht, gehört zu den wahren cracks.
    btw, da geschweifte klammern von k&r-fans so stiefmütterlich behandelt werden und ihnen offenbar ein dorn im auge sind, hab' ich hier die ultimative lösung für alle k&r-fans. lasst doch die klammern einfach weg:

    if (a > b)
       mach_dies(),
       mach_das(),
       mach_jenes();
    

    ^^ vorschläge für eine namen? 'k&r reloaded' vielleicht?
    🙂



  • ~fricky schrieb:

    kann sein. sie glauben wohl, dass nur sehr erfahrene coder k&r benutzen.

    In Java verwendet man standardmäßig K&R... und Java Programmierer sind ja die craßßeßten cod3r cr4cks 3v3r!



  • Shade Of Mine schrieb:

    ~fricky schrieb:

    kann sein. sie glauben wohl, dass nur sehr erfahrene coder k&r benutzen.

    In Java verwendet man standardmäßig K&R...

    gosling und co. sind ja auch nicht mehr die jüngsten.
    🙂



  • 1TBS ftw ^^ punkt 😃

    obwohl ich auch schonmal ne zeitlang sachen wie if und schleifen allgemein mit

    if(){
     doSomething();
    }
    

    formatiert hatte und klassen und funktionen mit

    class
    {
     function()
     {
      if(){
       doSomething();
      }
     }
    }
    


  • macht ihr eigentlich unterschiede je nach sprache ?
    zb csharp so, java so und cpp wieder anders ?



  • also ich nicht 🙂

    auser ich muss VB zwangsweise was Programmieren da gibts ja keine klammern und es ist eig. vorgeschrieben wo man was hinsetzen muss 😃



  • Ich auch nicht.



  • Ich bevorzuge Variante 2 - netterweise ists bei uns auch Firmenstandard. Dazu kommen noch andere Klammersetzungsrichtlinien:

    //Funktionsaufrufe und Deklarationen ohne blank:
    foo();
    //conditionals immer mit blank:
    if (not false)
    {
      /*...*/
    }
    while (1)
    {   //Auch bei Einzeilern gleich Blockklammern
      einzeiler();
    }
    


  • pumuckl schrieb:

    Ich bevorzuge Variante 2 - netterweise ists bei uns auch Firmenstandard. Dazu kommen noch andere Klammersetzungsrichtlinien:

    //Funktionsaufrufe und Deklarationen ohne blank:
    foo();
    //conditionals immer mit blank:
    if (not false)
    {
      /*...*/
    }
    while (1)
    {   //Auch bei Einzeilern gleich Blockklammern
      einzeiler();
    }
    

    ^^finde ich gut. ich mach's nämlich genau so. nur bei den kommentaren hab' ich zwischen '//' und dem eigentlichen text auch ein leerzeichen.
    🙂



  • pumuckl schrieb:

    while (1)
    {   //Auch bei Einzeilern gleich Blockklammern
      einzeiler();
    }
    

    Das ist bei uns zwar kein Standard, ich finde es aber (für mich selbst) für die Übersicht unbedingt nötig. Denn so eine Ein-Zeilen-Verzweigung/-Schleife übersehe ich dann beim überfliegen doch eher, als einen schönen Block.



  • pumuckl schrieb:

    while (1)
    {   //Auch bei Einzeilern gleich Blockklammern
      einzeiler();
    }
    

    👍



  • _matze schrieb:

    Denn so eine Ein-Zeilen-Verzweigung/-Schleife übersehe ich dann beim überfliegen doch eher, als einen schönen Block.

    Ich finde solche Konstrukte die Hölle...

    if(a == b) return;
    

    Die Klammersezung lasse ich in der Regel auch nur noch weg wenn alle Zweige Einzeiler sind...

    if(/*Bedingung1*/)
      /*Einzeiler*/;
    else if(/*Bedingung1*/)
      /*Einzeiler*/;
    else
      /*Einzeiler*/;
    

    Ich gebe dir aber Grundsätzlich recht: Im Zweifel das eine Klammernpaar "zuviel" als zuwenig 😉


Anmelden zum Antworten