3. Programmierstil?

Programmierstil?

  • ?

    Mir ist Lesbarkeit am wichtigsten, danach der Platz. In der Praxis sieht das so aus:

    int main()
{
    int a=3,b=5;
    for(int i=0;i<b;i++)
    {
        if(a--)
            break;
        else
        {
            a++;
            b--;
        }
    }
    return 0;
}

    Für jede "Ebene" einen Tabstopp (hier symbolisiert durch 4 Leerzeichen), keine unnötigen Leerzeichen zwischen Bezeichnern, jede Anweisung in einer Zeile, es sei denn, zwei oder mehr Anweisungen gehören eindeutig zusammen, lassen sich nicht in eine Schleife packen oder erhöhen die Lesbarkeit drastisch.

    Da fällt mir ein, ich habe meinen Stil immer als "Standard" angesehen 😮 ... was habe ich mir nur gedacht? 🙄

    0
  • E

    Glühbirne schrieb:

    Für jede "Ebene"

    Naja, eher für jedes Scope.

    0
  • S

    linux_c89 schrieb:

    Außerdem kann ja anscheinend keiner einen Vorteil der anderen Schreibweise nennen, also kann man diesen Bonus doch grade noch mitnehmen

    Nur ist es eben keiner. Es ist eine eigenheit deines Editors.

    Genauso wie alles andere: ist gibt keine sinnvollen Argumente für A oder B. Denn es ist nur der Geschmack der entscheidet. Da müssen wir nichts an den Haaren herbei ziehen.

    PS:
    http://twtpoll.com/r/0hirva

    0
  • E

    Shade Of Mine schrieb:

    http://twtpoll.com/r/0hirva

    Wow! Ich bin bei jeder Frage beim zweitgrössten Anteil.

    0
  • E

    Glühbirne schrieb:

    Mir ist Lesbarkeit am wichtigsten, danach der Platz. In der Praxis sieht das so aus:

    int main()
{
    int a=3,b=5;
    for(int i=0;i<b;i++)
    {
        if(a--)
            break;
        else
        {
            a++;
            b--;
        }
    }
    return 0;
}

    Für jede "Ebene" einen Tabstopp (hier symbolisiert durch 4 Leerzeichen), keine unnötigen Leerzeichen zwischen Bezeichnern, jede Anweisung in einer Zeile, es sei denn, zwei oder mehr Anweisungen gehören eindeutig zusammen, lassen sich nicht in eine Schleife packen oder erhöhen die Lesbarkeit drastisch.

    Da fällt mir ein, ich habe meinen Stil immer als "Standard" angesehen 😮 ... was habe ich mir nur gedacht? 🙄

    Das ist Standard, alles andere ist suboptimal und ich bin sehr tolerant. Noch Fragen? :p

    Und Argumente gibt es sehr wohl. Bei obiger Art und Weise sind { und } auf gleicher Höhe. Selbst umfangreiche Codestrukturen kann man auf diese Weise auf einen Blick erkennen. Bei so was wie:

    int main(){
    if(wurst.zustand == 'durchgebraten'){
        wurst.wuerzen(PAPRIKA | CURRY);
        wurst.abLegen(teller);
    }
}

    ist das nicht der Fall. Gewöhnung hin oder her, man erkennt Blöcke nicht so schnell. Wobei ich sagen muss, dass ich es jetzt gerade etwas weniger schlimm finde, als ich dachte, weil man auch durch die Einrückung ohne Klammern die Ebene erkennen kann.

    Mist, damit hab ich mir mein eigenes Argument zerschossen. Jetzt finde ich beide Varianten ok. Allerdings finde ich das:

    class TypeName { 
  functionName(type arguments) { 
    if (...) { 
    } 
  } 
}

    wiederum schlecht, weil zwei Zeichen für Einrückungen einfach zu wenig sind. Man erkennt die Blöcke durch die Einrückungen nicht besonders gut und die Klammern helfen einem auch nicht. Vielleicht geht das mit Übung besser, aber hier ist das Argument klar, dass ein Anfänger Einrückungen nicht unbedingt gut sieht. Bei der Variante mit allen {} auf gleicher Höhe ist das sehr viel einfacher.

    0
  • ?

    Also ich handhabe das so, dass ich bei Kontrollstruktoren (if, while, etc.) die erste Klammer auf der gleichen Zeile habe und ansonsten (Klassen, Funktionen, etc.) immer auf der nächsten.
    Also:

    if (a) {
  // ...
}

void f()
{
}

class B
{
};

    Finde ich persönlich am übersichtlichsten, weil ich so beim Lesen des Codes nicht von "Leerzeilen", die nur { enthalten gestört werde. Die abschließende Klammer auf die gleiche Zeile wie den letzten Ausdruck zu packen, finde ich hingegen wieder unübersichtlicher.

    Als erfahrener C++ler sollte man natürlich mit jedem Stil zurechtkommen.

    0
  • ?

    Eisflamme schrieb:

    Das ist Standard, alles andere ist suboptimal und ich bin sehr tolerant. Noch Fragen? :p

    Juhu, mein Programmierstil ist Standard, alles andere ist suboptimal und du bist sehr tolerant. Meine Frage: Und jetzt? 🕶

    Eisflamme schrieb:

    (...)

    Mann, dein Post hat mir aber Hunger auf Currywurst gemacht. 😋

    Irgendwer schrieb:

    Finde ich persönlich am übersichtlichsten, weil ich so beim Lesen des Codes nicht von "Leerzeilen", die nur { enthalten gestört werde. Die abschließende Klammer auf die gleiche Zeile wie den letzten Ausdruck zu packen, finde ich hingegen wieder unübersichtlicher.

    Ein Argument dagegen wäre, dass man auf meine Weise auf den ersten Blick sehen kann, zu welcher "Ebene" oder Scope der Befehl gehört. Außerdem lese ich die Klammern kaum, registriere aber die Einrückung umso mehr, daher halte ich mich an den "Standard".

    0
  • L

    Genauso wie alles andere: ist gibt keine sinnvollen Argumente für A oder B. Denn es ist nur der Geschmack der entscheidet. Da müssen wir nichts an den Haaren herbei ziehen.

    Natürlich geht es nur um den Geschmack, aber wollte der Threadersteller nicht verschiedene Meinungen zu dem Thema hören?
    (Ich wollte nicht andere Stile als minderwertig bezeichnen oder sowas, ich hoffe das ist nicht falsch rübergekommen)

    0
  • ?

    was ist daran denn verkehrt?

    int main(){
    int a = 3, b = 5;
    for( int i = 0; i < b; i++ ){
        if(a--)
            break;
        else{
            a++;
            b--; }}
    return 0; }

    die Einrückung läßt doch keinen Zweifel am Verlauf des Programmflusses, und außerdem wird kein Platz für Leerzeilen verschwendet, die nur aus { oder } bestehen.

    0
  • E

    !rr!rr_. schrieb:

    kein Platz für Leerzeilen verschwendet

    Wieso nicht gleich so etwas?

    typedef int c;
c main(){c a=3,b=5;for(c i=0;i<b;i++){if(a--)break;else{a++;b--;}}}
    0
  • I

    !rr!rr_. schrieb:

    was ist daran denn verkehrt?

    int main(){
    int a = 3, b = 5;
    for( int i = 0; i < b; i++ ){
        if(a--)
            break;
        else{
            a++;
            b--; }}
    return 0; }

    die Einrückung läßt doch keinen Zweifel am Verlauf des Programmflusses, und außerdem wird kein Platz für Leerzeilen verschwendet, die nur aus { oder } bestehen.

    Ich denke, da kann es auch leicht passieren, dass man mal ein paar Klammern vergisst und sich durch die Einrückung in falsche Sicherheit wiegt. Das kann schief gehen. In Stilen, wo man die Klammern explizit sieht, passiert das weniger. Und ist der Bildschirmplatz wirklich so bedeutend? Ich mache in meienm Code z.B. auch gerne einfach so Leerzeilen zur Übersichtlichkeit, die zusätzlichen Zeilen für die Klammern stören mich überhaupt nicht.

    0
  • E

    Ich schildere einfach mal wie das bei mir ist.

    In der Firma haben wir "Coding Style Guidlines", sei es für C++ oder C#.
    Die finde ich gut und halte ich auch ein. Ich habe zudem auch gemerkt das ich Privat selber zu diesen Style tendiere.
    Ich habe auch verschiedene Stile in verschiedenen Projekten ausprobiert, am Ende bin ich bei demselben gelandet was ich am angenehmsten zu lesen finde.

    Ich packe die { sowie } immer auf eine leere Zeile. Bei Ifs die nur ein Element beinhalten lass ich es weg.
    Ich kann auch sagen warum ich es so mach.

    1. Es ist der Selbe style den MS im .Net Code macht und den man auch auf der MSDN Seite sieht. So sehe ich überall wo ich schau denselben Style. (Das ist auch der VS Default in C#)

    2. Ich finde es angenehmer mehr "Luft" zu haben. Freiraum. Bei den Blöcken wo die { am Zeilenende sind fühle ich mich so "erschlagen" von einem Codeklumpen.

    int main()
{
    int a = 3;
    int b = 5;

    for (int i = 0; i < b; ++i)
    {
        if (a--)
            break;
        else
        {
            ++a;
            --b;
        }
    }

    return 0;
}

    public Sausage GetNewSausage()
{
    var sausage = Freezer.Dequeue();
    while (sausage.Status != SausageStates.WellDone)
        Barbecue.Broil(sausage);

    PiceRack.Flavor(sausage);

    return sausage;
}

    namespace
{
    class TypeName
    {
        FunctionName(type arguments)
        {
            if (...)
            {
            }
        }
    }
}

    Ich schreibe auch hin und wieder leere Zeilen, einfach um etwas "Ruhe" rein zu bekommen 🙂
    Der vertikale Platz geht schon nicht aus - also kann man auch verschwenderisch sein 😃

    0
  • A

    David W schrieb:

    Ich schildere einfach mal wie das bei mir ist. ...

    👍
    Mein Stil ist ähnlich, mit dem Unterschied, dass ich einen Block auch bei if mit nur einem Element mache:

    int main()
{
    int a = 3;
    int b = 5;

    for (int i = 0; i < b; ++i)
    {
        if (a--)
        {
            break;
        }
        else
        {
            ++a;
            --b;
        }
    }

    return 0;
}

    Das ist bei mir sozusagen der aktuelle "stabile" Stand nach etwa 12 Jahren mit C (:(). Früher hatte ich Phasen, das eine oder andere auszuprobieren, aber irgendwann merkt man: Das ist einfacher zu lesen, leichter zu warten und zu debuggen. Wahrscheinlich, weil man es genauso auf Papier schreiben würde 😕

    0
  • M

    abc.w schrieb:

    Wahrscheinlich, weil man es genauso auf Papier schreiben würde 😕

    Auf dem Papier gönne ich den Klammern keine eigene Zeile (wenn ich überhaupt Klammern schreibe), denn hier habe ich ein Platzproblem. In C++-Code am Bildschirm haben Klammern dagegen eine eigene Zeile.

    0
  • F

    Manche Codingstyles habe durchaus auch Praktischen nutzen.
    Ob

    void foo{
  bar();
}

    oder

    void foo
{
  bar();
}

    macht keinen unterschied. Obwohl ich das 2 für Übersichtlicher halte.
    Aber z.B. sowas

    if (foo) DoFoo();
else DoBar();

    lässt sich so weitaus besser schreiben

    if (foo)
   DoFoo();
else
   DoBar();

    Spätestens wenn man da bei komplexeren sachen mit den Debugger ran muss weiss man auch warum. Auf DoFoo() und DoBar() kann ich einen einzelnen Breakpoint sezen. Im ersten beispiel nehme ich da zwangsläufig das if mit. Was spätestens in einer Schleife sehr Nervtötent sein kann.
    Wenn man sich jetzt noch angewöhnte die {} mitzuscheiben hat man dann noch so tolle effekte wie lokale Gültigkeitsbereiche von Variablen.
    Im Endeffekt wird der Style aber eh meist vom Arbeitgeber vorgegeben. Und weil man keinen Bock hat sich dauernd umzustellen übernimmt man den dann selber.

    0
  • E

    !rr!rr_. schrieb:

    was ist daran denn verkehrt?

    int main(){
    int a = 3, b = 5;
    for( int i = 0; i < b; i++ ){
        if(a--)
            break;
        else{
            a++;
            b--; }}
    return 0; }

    die Einrückung läßt doch keinen Zweifel am Verlauf des Programmflusses, und außerdem wird kein Platz für Leerzeilen verschwendet, die nur aus { oder } bestehen.

    Ha, ich wusste doch, dass mir noch was dazu einfällt. Mein Argument mit dem Nicht-Erkennen von Blöcken fällt weg, weil man mit 4 Leerzeichen pro Tab auch so die Einrückungen erkennt.

    Problematisch sind zwei Dinge (schon angesprochen z.T.):
    - Man kann sich selbst mit den {} verwurschteln
    - Damit zusammenhängend könnten einem die Einrückungen eine Logik vorgaukeln, die den {} nicht entspricht

    int main(){
    for(std::size_t n = 0; n < 100; ++n){
        for(std::size_t m = 0; m < 100; ++m){
            std::cout << someGlobalMatrix[n][m] << ' ';
        std::cout << '\n';}} // Ups, falsch eingerückt
    std::cout << "Jetzt... Jetzt ist aus...\n";
}

    Wenn man dem Codeautor nicht traut oder Bugs vermutet, hat man also ein Problem. Dann muss man unabhängig von den Einrückungen alle Klammern überprüfen und dann hat man wirklich Spaß. Bei dieser Variante kann das nicht passieren:

    int main()
{
    for(std::size_t n = 0; n < 100; ++n)
    {
        for(std::size_t m = 0; m < 100; ++m)
        {
            std::cout << someGlobalMatrix[n][m] << ' ';
            std::cout << '\n'; // Hoppla
        }
     }
}
    0
  • V

    Eisflamme schrieb:

    - Damit zusammenhängend könnten einem die Einrückungen eine Logik vorgaukeln, die den {} nicht entspricht

    Wird mehr und mehr unwahrscheinlich, weil die IDE einrückt.

    Aber wenn ich } auf der selben Zeile hinter die Befehle hänge, kann ich die nicht mehr im Code mit wenigen Tastendrücken umsortieren. Das mache ich aber sehr oft.

    0
  • E

    Wenn Du den Code umkonvertierst, zählt für die hier vorgestellte Form natürlich die Ergebnisform. Denn ich denke nicht, dass jemand int main(){ vorstellt, wenn er nachher auf den Umkonvertierknopf drückt.

    0
  • M

    Eisflamme schrieb:

    Wenn Du den Code umkonvertierst, zählt für die hier vorgestellte Form natürlich die Ergebnisform. Denn ich denke nicht, dass jemand int main(){ vorstellt, wenn er nachher auf den Umkonvertierknopf drückt.

    War das auf volkard bezogen? Wenn ja: Wie? 😕

    0
  • V

    Ich meinte Umsortieren im Sinne von per Hand Zeilen vertauschen. Also
    [Pos1] //zu Zeilenanfang springen
    [Shift]+[CrsDown] //Zeile markieren //Hier würde } arg stören
    [Shift]+[Del] //Zeile Zwischenablage kopieren und aus Code entfernen
    n-mal{[CrsDown]} //hinspringen, wo sie landen soll
    [Shift]+[Ins] //Zeile in den Code reinkopieren

    0
Anmelden zum Antworten