Einzelaussage ob Klammer oder nein? [geschlossen]

Was ist besser / allgemeiner akzeptiert?

Diese:

if(condition)
{
  statement;
}

Oder:

if(condition)
  statement;

Ich bevorzuge eher die erste, weil ich denke, dass es einfacher ist zu erkennen, was tatsächlich in den if-Block gehört, andere davon abhält, die Klammern später einzufügen (oder einen Fehler zu erzeugen, indem sie vergessen), und alle Ihre if-Anweisungen enthält Uniform statt mit Hosenträgern und ohne. Das zweite ist jedoch syntaktisch korrekt und definitiv kompakter. Ich bin gespannt, was von anderen generell bevorzugt wird.

Das erste ist besser, weil das zweite fehleranfällig ist. Nehmen wir zum Beispiel an, Sie kommentieren Code vorübergehend aus, um etwas zu debuggen:

if(condition) 
//      statement;
otherStatement;

Oder fügen Sie schnell Code hinzu:

if(condition) 
    statement;
    otherStatement;

Das ist offensichtlich schlecht. Andererseits fühlt sich der erste manchmal zu wortreich an. Deshalb ziehe ich es vor, alles auf eine Zeile zu setzen, wenn es kurz und einfach genug ist:

if(condition) statement;

Dadurch wird das syntaktische Rauschen reduziert, während das Konstrukt so aussieht, wie es tatsächlich funktioniert, wodurch es weniger fehleranfällig wird. Sofern diese Syntax nur für sehr einfache, kurze Bedingungen und Anweisungen verwendet wird, finde ich sie perfekt lesbar.

Ich benutze immer Klammern, um sicher zu gehen.

Es ist in Ordnung, wenn Sie es schreiben, aber Sie wissen, dass in Zukunft jemand mitkommt und eine andere Aussage einfügt, ohne sie in Klammern zu setzen.

Ich bevorzuge die Version ohne Klammern wo möglich.

Die folgende Erklärung ist langwierig. Bitte bei mir tragen. Ich gebe einen zwingenden Grund für mich, diesen Stil zu bevorzugen. Ich werde auch erklären, warum ich denke, dass das übliche Gegenargument nicht zutrifft.

(Fast-) Leerzeilen sind Verschwendung

Der Grund dafür ist, dass die schließende Klammer eine zusätzliche Codezeile erfordert - und je nach Stil auch die öffnende Klammer. ¹

Ist das eine große Sache? Oberflächlich gesehen nein. Schließlich setzen die meisten Leute auch Leerzeilen in ihren Code, um logisch leicht unabhängige Blöcke zu trennen, was die Lesbarkeit erheblich verbessert.

Ich hasse es jedoch, vertikalen Raum zu verschwenden. Moderne Monitore haben tatsächlich viel horizontalen Raum. Der vertikale Raum ist jedoch immer noch sehr, sehr begrenzt (es sei denn, Sie verwenden einen aufrechten Monitor, was nicht ungewöhnlich ist). Dieser begrenzte vertikale Raum ist ein Problem: Es ist allgemein anerkannt, dass einzelne Methoden so kurz wie möglich sein sollten und dass die entsprechenden Klammern (oder andere Blockbegrenzer) nicht höher als eine Bildschirmhöhe sein sollten, damit Sie den gesamten Block ohne Klammern sehen können Scrollen.

Dies ist ein grundlegendes Problem: Sobald Sie nicht mehr den gesamten Block auf Ihrem Bildschirm sehen können, wird es schwierig, ihn zu erfassen.

Infolgedessen verabscheue ich redundante Leerzeilen. Während einzelne Leerzeilen für die Abgrenzung unabhängiger Blöcke von entscheidender Bedeutung sind (sehen Sie sich nur das Erscheinungsbild dieses Textes an), sind aufeinanderfolgende Leerzeilen in meinem Buch ein sehr schlechter Stil (und meiner Erfahrung nach sind sie in der Regel ein Zeichen für unerfahrene Programmierer).

Ebenso sollten Leitungen, die einfach eine Klammer halten und die eingespart werden könnten, sein. Ein Block mit einer Anweisung, der durch geschweifte Klammern begrenzt ist, verschwendet ein bis zwei Zeilen. Bei nur 50 Zeilen pro Bildschirmhöhe fällt dies auf.

Klammern wegzulassen schadet vielleicht nicht

Es gibt nur ein Argument gegen das Weglassen von geschweiften Klammern: Jemand wird später eine weitere Anweisung zum betreffenden Block hinzufügen und das Hinzufügen der geschweiften Klammern vergessen, wodurch die Semantik des Codes versehentlich geändert wird.

Dies wäre in der Tat eine große Sache.

Aber meiner Erfahrung nach ist es nicht. Ich bin ein schlampiger Programmierer. und doch kann ich in meinem Jahrzehnt der Programmiererfahrung ehrlich sagen, dass ich nicht einmal vergessen habe, die geschweiften Klammern hinzuzufügen, wenn ich einem Singleton-Block eine zusätzliche Anweisung hinzufüge.

Ich finde es sogar unplausibel, dass dies ein häufiger Fehler sein sollte: Blöcke sind ein grundlegender Bestandteil der Programmierung. Block Level Resolution und Scoping ist ein automatischer, tief verwurzelter mentaler Prozess für Programmierer. Das Gehirn tut es einfach (ansonsten wäre es viel schwieriger, über das Programmieren nachzudenken). Es ist keine zusätzliche mentale Anstrengung erforderlich, um sich daran zu erinnern, die geschweiften Klammern gesetzt zu haben: Der Programmierer erinnert sich auch, die neu hinzugefügte Anweisung schließlich korrekt eingerückt zu haben ; der programmierer hat also schon mental verarbeitet, dass es sich um einen block handelt.

Jetzt sage ich nicht , dass das Weglassen von Klammern keine Fehler verursacht. Was ich sage ist, dass wir auf die eine oder andere Weise keine Beweise haben. Wir wissen einfach nicht, ob es Schaden anrichtet.

Solange mir also niemand aussagekräftige Daten zeigen kann, die aus wissenschaftlichen Experimenten stammen und zeigen, dass dies tatsächlich ein Problem in der Praxis ist, bleibt diese Theorie eine „ einfache Geschichte “: eine sehr überzeugende Hypothese, die noch nie auf den Prüfstand gestellt wurde darf nicht als Argument verwendet werden.

¹ Dieses Problem wird manchmal gelöst, indem Sie alles - einschließlich der geschweiften Klammern - in dieselbe Zeile setzen:

if (condition)
{ do_something(); }

Ich glaube jedoch, es ist sicher zu sagen, dass die meisten Menschen dies verachten. Darüber hinaus hätte es die gleichen Probleme wie die Variante ohne Zahnspange, so dass es das Schlimmste von beiden Welten ist.

Ich gehe mit dem zweiten. Es ist prägnanter und weniger ausführlich.

Ich versuche, nicht auf den kleinsten gemeinsamen Nenner zu schreiben, daher erwarte ich, dass andere Entwickler wissen, wie man eine der häufigsten Kontrollflussstrukturen in der heutigen Programmierung schreibt.

Ich würde folgendes verwenden (der Konsens hier):

if (condition) {
    any_number_of_statements;
}

Auch möglich:

if(condition) single_compact_statement;

Nicht so gut, besonders in C / C ++ ähnlichen Sprachen:

if(condition) 
    single_compact_statement;

(Keine Wahl hier in Python ;-)

In Perl würden Sie Folgendes verwenden:

$C = $A**3 if $A != $B;

oder

$C = $A**3 unless $A == $B;

(Dies ist kein Pseudocode ;-)

Ich benutze die Methode der Zahnspange - aus allen oben genannten Gründen plus einer weiteren.

Code wird zusammengeführt. Es ist bekannt, dass es bei Projekten passiert, bei denen ich an einer einzigen Anweisung gearbeitet habe, wenn durch automatische Zusammenführungen Fehler aufgetreten sind. Das Beängstigende ist, dass die Einrückung richtig aussieht , obwohl der Code falsch ist, so dass diese Art von Fehler schwer zu erkennen ist.

Also gehe ich mit Zahnspangen - auf eigene Faust. Es ist einfacher, die Ebenen auf diese Weise zu erkennen. Ja, es verschwendet vertikale Bildschirme und das ist ein echter Nachteil. Alles in allem denke ich, dass es sich lohnt.

Keine geschweiften Klammern. Wenn ein anderer Programmierer meinem Code eine zweite Anweisung hinzufügt, ist das nicht mehr meine Schuld, als wenn ich jemanden mein Auto fahren lasse und er über eine Klippe fährt.

Wir haben dieses Argument mehr als einmal hier gehabt, und der allgemeine Konsens ist, immer geschweifte Klammern zu verwenden. Die Hauptgründe sind über Lesbarkeit / Wartbarkeit.

Wenn Sie dem ifBlock Code hinzufügen müssen , müssen Sie sich keine geschweiften Klammern merken / suchen. Wenn zukünftige Programmierer den Code lesen, sind die Klammern immer eindeutig.

Auf der positiven Seite, ReSharper automatisch die Zahnspange für faule Programmierer in Visual Studio hinzufügen, und ich nehme an, es gibt Addons für andere IDEs , die auch tun wird.

Ich verwende fast ausnahmslos die erste Syntax. Weil es nicht falsch interpretiert werden kann .

"Lass mich nicht nachdenken" gilt nicht nur für Benutzeroberflächen ;-)

Ich persönlich bevorzuge die zweite. Der erste sieht hässlich und umständlich aus und verschwendet horizontalen Raum. Die Hauptprobleme mit dem zweiten sind Makros und Leute, die Ihren Code zu einem späteren Zeitpunkt modifizieren.

Dazu sage ich "keine Makros verwenden". Ich sage auch "Deinen verdammten Code richtig einrücken". In Anbetracht dessen, wie jeder Texteditor / jede IDE, die für die Programmierung verwendet wird, die Einrückung automatisch ausführt, sollte dies nicht so schwierig sein. Beim Schreiben von Code in Emacs würde ich den automatischen Einzug verwenden, um festzustellen, ob in einer vorherigen Zeile ein Fehler aufgetreten ist. Immer wenn Emacs anfängt, Einrückungen zu verfälschen, weiß ich normalerweise, dass ich etwas falsch gemacht habe.

In der Praxis befolge ich letztendlich die Kodierungskonvention, die vor mir festgelegt wurde. Aber diese nerven mich (und machen mich viel glücklicher, wenn ich in Python programmiere und das gesamte Bracket-Desaster weg ist):

if (condition) {
    statement;
} // stupid extra brace looks ugly

Dann

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

Obwohl ehrlich gesagt, stören mich zwei Aussagen in einer if-Aussage weit mehr als eine einzige Aussage. Meist sind da dann eckige Klammern erforderlich und es sieht trotzdem lustig aus mit nur zwei Anweisungen in der if-Anweisung.

Ich benutze die zweizeilige Version ohne geschweifte Klammern (2. Form), aber nicht um Platz zu sparen.

Ich benutze dieses Formular, weil es lesbarer, optisch ansprechender und einfacher zu tippen ist. Ich benutze dieses Formular nur, wenn diese Bedingungen erfüllt sind. dh die ifBedingung muss gut in eine einzelne Zeile passen, und die entsprechende Anweisung muss gut in die folgende Zeile passen. Wenn dies nicht der Fall ist, verwende ich geschweifte Klammern, um die Lesbarkeit zu verbessern.

Wenn ich dieses Formular verwende, stelle ich sicher, dass vor und nach der ifAnweisung (oder über dem Kommentar, falls vorhanden) eine leere Zeile (oder eine Zeile, die nur eine geschweifte Klammer enthält ) steht. Dies ist zwar keine Regel, die ich bewusst befolge, aber ich merke es jetzt, nachdem ich diese Frage gelesen habe.

Die Schonung des Bildschirmplatzes hat für mich keine Priorität. Wenn ich mehr Platz brauchte, würde ich einen größeren Monitor verwenden. Mein Bildschirm ist bereits groß genug, um alles zu lesen, auf das ich meine Aufmerksamkeit richten kann. Es ist unwahrscheinlich, dass ich mich auf so viele Codezeilen gleichzeitig konzentrieren muss, dass sie meinen gesamten Bildschirm einnehmen. Wenn mit einem Codeabschnitt so viel geschachtelt wird, dass ich ihn nicht verstehen kann, ohne ihn auf einmal erneut anzuzeigen, müsste ich überlegen, ob die Logik besser durch Refactoring dargestellt werden könnte.

Im Folgenden sind einige Beispiele aufgeführt, die veranschaulichen, wie ich diese Form der ifAnweisung verwende.

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

Hosenträger. Immer. Ich bin eine Art Fan von ihnen, weil es dem Code eine gewisse Konsistenz verleiht. Und wie @dsimcha schrieb - weniger Fehler beim Hinzufügen zusätzlicher Codezeilen.

"Hässlichkeit" von geschweiften Klammern um eine einzelne Codezeile ist weniger schädlich als zusätzliche Arbeit, die in solchen Fällen mit dem Debuggen und / oder Hinzufügen von Code wahrscheinlich ist.

Persönlich gehe ich mit Klammern.

Warum?

Nun, wenn irgendjemand vorbeikommt und Code in die if-Anweisung einfügen muss, ist zu 100% klar, wo der Gültigkeitsbereich liegt.

Es hält das Format von ifAnweisungen konsistent, unabhängig davon, wie viele Anweisungen sich im Block befinden.

Wenn Sie jedoch auf den Projektstil verzichten möchten, bleiben Sie dabei.

Ich benutze fast immer die Klammern, um auf der sicheren Seite zu sein. Manchmal jedoch, wenn der Inhalt des Blocks wirklich kurz ist, lasse ich ihn weg und mache ihn zu einem Einzeiler wie folgt:

if (x==5) Console.WriteLine("It's a five!");

Ich bevorzuge geschweifte Klammern, um die Konsistenz zu gewährleisten, aber nicht zu viel Leerraum zu verschwenden (so dass lesbarer formatierter Code in meinem begrenzten Sichtfeld liegt). Also schreibe ich das für ausreichend kurze Zeilen:

If (cond) { statement; }

Ich benutze normalerweise Zahnspangen, aber es gibt Fälle, in denen ich keine habe.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

Für mich wäre es einfach dumm, sie dort hinzuzufügen. Wenn jemand nach dem eine Aussage hinzufügt return, haben wir größere Probleme als Scoping-Probleme.

Wenn die IDE über eine verfügbare Code-Formatierung verfügt, verwende ich keine geschweiften Klammern.

Wenn Code in anderen Editoren bearbeitet werden kann, die keine automatische Formatierung unterstützen, ist es jedoch gefährlich, keine geschweiften Klammern zu setzen, wie in anderen Beiträgen erwähnt. Aber ich bevorzuge es trotzdem, keine Zahnspange zu verwenden, und das war für mich kein Problem.