3. Programmierstil?

Programmierstil?

  • 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
  • G

    volkard schrieb:

    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

    Wow, viele Arbeitsschritte für sowas.
    Wenn du Visual Studio nutzt, dann mach's so:
    Strg + l (kleines L)
    [zu Zeile navigieren]
    Strg + v

    0
  • V

    Das l ist zu weit weg. Die rechte Hand ist ja noch auf den Cursortasten vom Ansteuern der Zeile, weißt Du. Und meine Kombinationen gehen überall, sogar unter Linux. Geht schon recht fix.
    [Strg]+[v] ist viel schlimmer als [Shift]+[Ins], schon wieder die rechte rechte Hand.

    0
  • G

    volkard schrieb:

    Das l ist zu weit weg. Die rechte Hand ist ja noch auf den Cursortasten vom Ansteuern der Zeile, weißt Du. Und meine Kombinationen gehen überall, sogar unter Linux. Geht schon recht fix.
    [Strg]+[v] ist viel schlimmer als [Shift]+[Ins], schon wieder die rechte rechte Hand.

    Du hast entweder kleine Händer oder Wurstfinger, aber Strg+v krieg ich problemlos mit kleinem Finger auf Strg und Zeigefinger auf v gedrückt 😃 Wenn ich mich strecke, komm ich sogar an's l ran 😉
    Übrigens gibt es sowohl in vi als auch in emacs (wenn wir von Linux reden) effizientere Tastenkombos, um auszuschneiden, sich zu bewegen und wieder einzufügen. Da hat man dann eh meistens beide Hände auf den Buchstabentasten.

    Aber du legst den Fokus wohl eher auf die rechte Hand und ich auf die linke.

    0

  • GPC schrieb:

    Du hast entweder kleine Händer oder Wurstfinger, aber Strg+v krieg ich problemlos mit kleinem Finger auf Strg und Zeigefinger auf v gedrückt 😃 Wenn ich mich strecke, komm ich sogar an's l ran 😉

    Ctrl+L mit kleiner Finger + Zeigefinger? Was hast du denn für Hände? 😮
    Ich schaff das nur mit kleiner Finger + Daumen. Tut's aber auch 🙂

    0
  • E

    volkard:
    Trotzdem verstehe ich nicht, wie das mehr und mehr unwichtig wird. Wenn die IDE automatisch einrückt, wird der Stil mit { am Ende der Zeile ja quasi "nicht mehr unterstützt". Das macht ihn ja trotzdem nicht besser. Oder war deine Aussage, dass dieser Stil automatisch von der IDE auf dauer ausgerottet wird?

    0
  • O

    Die Sache ist doch so: wenn du fremden Code debugst(oder der Einrückung eines anderen programmeirers nicht traust), dann drückst du einmal die magische Tastenkombination deiner IDE und alles ist korrekt eingerückt. Dann gibt sich dein Problem gar nicht. Genauso wie man sich als progrmamier angewöhnen kann, vorm Schließen einer editierten Datei einmal die magische Tastenkombination zu benutzen. dann tritt sowas auch nicht mehr auf.

    0
  • G

    hustbaer schrieb:

    GPC schrieb:

    Du hast entweder kleine Händer oder Wurstfinger, aber Strg+v krieg ich problemlos mit kleinem Finger auf Strg und Zeigefinger auf v gedrückt 😃 Wenn ich mich strecke, komm ich sogar an's l ran 😉

    Ctrl+L mit kleiner Finger + Zeigefinger? Was hast du denn für Hände? 😮

    Hab lange, schlanke Finger und meine linke Hand ist zudem auf Spreizung trainiert, da es auch die Greifhand beim Gitarrenspielen ist 😃
    Aber ich würde die Spreizung jetzt auch über einen Tag nicht 1x pro Minute machen wollen 😉

    Eisflamme schrieb:

    Wenn die IDE automatisch einrückt, wird der Stil mit { am Ende der Zeile ja quasi "nicht mehr unterstützt".

    Kann man doch einstellen wie man will. Ich habe die { Klammer auch nicht auf einer extra Zeile. Und wie otze sagte, drück ich bei fremdem Code einmal Strg+K, Strg+D und dann ist es so formatiert, wie ich's gerne habe 🙂 VS ftw!

    0
Anmelden zum Antworten