Programmierstil?

[ipsec]

Das mit den Kürzeln für den Typ nennt sich "Ungarische Notation" und wird von vielen (mich eingeschlossen) als veraltet und kontraproduktiv angesehen. Also lass die Kürzel weg. Nexus kann dir auch gerne nähere Gründe dafür geben.

Die Klammern sind eine reine Glaubensfrage. Beides wurde und wird vielfach angewendet und es wurden schon Kreuzzüge geführt, was denn nun besser ist. Für Variante 1 wird oft der geringere Zeilenbedarf genannt, bei Variante 2 die höhere Übersichtlichkeit. Nimm einfach das, was dir am besten gefällt. Aber, am allerwichtigsten: mische die Stile nicht, sondern wende die eine Variante dann auch überall an.

[EOutOfResources]

ipsec schrieb:

Das mit den Kürzeln für den Typ nennt sich "Ungarische Nation"

Nein. Das heisst "Ungarische Notation". Und ich bin auch dafür, dass du sie weglassen solltest.

Und mit dem Klammern-Stil würde ich dir das von volkard empfehlen. Er zeigt die Blöcke sehr schnell und deutlich.

[linux_c89]

Zum Klammerstil: Der hilft auch wenn man einen Editor mit "folding"(Wie sagt man das auf Deutsch?) benutzt. Zumindest bei vim sieht das dann so aus

int foo(int bar)
+--  5 lines: {------------

statt

+--  5 lines: int foo(int bar) {-----

Der Funktionskopf tritt also deutlicher hervor, untendrunter kann man an der Anzahl der Zeilen grob die Komplexität der Funktion abschätzen
(Kann natürlich auch demotivierend wirken, z.B. wenn man öfter mal Folgendes sieht)

int main(int argc,char **argv)
+-- 740 lines: {------------------------

[Shade Of Mine]

linux_c89 schrieb:

Der Funktionskopf tritt also deutlicher hervor, untendrunter kann man an der Anzahl der Zeilen grob die Komplexität der Funktion abschätzen

Tja, andere Editoren sind da halt besser und schreiben so unnötige Information wie +xyz zeilen nicht hin - weil man die eh als tooltip bekommt wenn man will die stelle markiert.

also ist das schon ein sehr sehr schwaches argument.

[Antoras]

Viel wichtiger als persönliche Vorlieben finde ich die Style-Guides einer Programmiersprache. Man sollte sich aus einem einfachen Grund an diese halten: Es erleichtert anderen Programmieren den Quelltext zu verstehen.

Es bringt nun einmal gerade nicht viel den Code-Style einer Programmiersprache auf eine Andere übertragen zu wollen wenn dieser nicht mit der Syntax jener Sprache vereinbar ist.

Erst wenn keine Style-Guides vorhanden oder diese schlicht unvollständig sind, sollte es es dem Entwickler überlassen sein welchen Code-Style er wählt - wobei er dabei immer darauf achten sollte ob sein Style auch tatsächlich zu einer Sprache passt.

Ich passe das Aussehen meines Codes an die Anforderungen verschiedener Programmiersprachen an. In C wähle ich z.B. folgende Notation:

type TypeName_functionName(TypeName t, type arguments)
{
  if (..) {
  }
}

In Java finde ich folgendes passender (was auch den Java-Code-Conventions entspricht):

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

Die Unterschiede resultieren aus den Aufrufmöglichkeiten der Funktionen. In C gibt es keine Namensräume - folglich muss ich diese selbst setzten. Weiterhin benötigen Funktionen in C einen zusätzlichen Parameter, nämlich den Typ auf den die Funktion angewandt werden soll. Dies kann in in einer längeren Funktionssignatur resultieren als bspw. Java weshalb ich es passend finde den Funktionskopf vom Körper stärker zu trennen (durch das Setzen einer Klammer in eine neue Zeile).

Das ist allerdings eine persönliche Vorliebe, die wie gesagt erst dann Einzug finden sollte wenn die Style-Guides dazu nichts zu sagen haben.

[asc]

Antoras schrieb:

Viel wichtiger als persönliche Vorlieben finde ich die Style-Guides einer Programmiersprache.

Also in C++ gibt es keine einheitlichen Styleguides... (Für C davon abgesehen ebenso wenig, da haben sich ein paar Stile herauskristallisiert, die tendenziell auf einer bestimmten Plattform verbreitet sind).

[linux_c89]

Tja, andere Editoren sind da halt besser und schreiben so unnötige Information wie +xyz zeilen nicht hin - weil man die eh als tooltip bekommt wenn man will die stelle markiert.

also ist das schon ein sehr sehr schwaches argument.

Für dich vielleicht, ich finde es ziemlich wichtig. Außerdem kann ja anscheinend keiner einen Vorteil der anderen Schreibweise nennen, also kann man diesen Bonus doch grade noch mitnehmen ( ob das mit den Tooltips besser ist, ist wieder ein anderes Thema)

[Glühbirne]

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?

[EOutOfResources]

Glühbirne schrieb:

Für jede "Ebene"

Naja, eher für jedes Scope.

[Shade Of Mine]

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

[EOutOfResources]

Shade Of Mine schrieb:

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

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

[Eisflamme]

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.

[Irgendwer]

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.

[Glühbirne]

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".

[linux_c89]

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)

[!rr!rr_.]

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.

[EOutOfResources]

!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--;}}}

[ipsec]

!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.

[EXDW]

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

[abc.w]

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