it-swarm.dev

Einzelne Anweisung, ob Klammern oder nein?

Was ist besser/allgemein anerkannt?

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 geschweiften Klammern später hinzuzufügen (oder einen Fehler zu erzeugen, indem man es vergisst), und alle Ihre if-Anweisungen macht Uniform statt einige mit Klammern und einige ohne. Der zweite ist jedoch syntaktisch korrekt und definitiv kompakter. Ich bin gespannt, was andere allgemein bevorzugen.

59
Zann Anderson

Der erste ist besser, weil der zweite fehleranfällig ist. Angenommen, Sie kommentieren vorübergehend Code aus, um etwas zu debuggen:

if(condition) 
//      statement;
otherStatement;

Oder in Eile Code hinzufügen:

if(condition) 
    statement;
    otherStatement;

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

if(condition) statement;

Dies reduziert das syntaktische Rauschen und lässt das Konstrukt so aussehen, als ob es das tut, was es tatsächlich tut, wodurch es weniger fehleranfällig wird. Vorausgesetzt, diese Syntax wird nur für sehr einfache, kurze Bedingungen und Anweisungen verwendet, finde ich sie perfekt lesbar.

131
dsimcha

Ich benutze immer Klammern, nur um sicher zu gehen.

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

44
Neil Aitken

Ich bevorzuge nach Möglichkeit die Version ohne geschweifte Klammern .

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

(Fast-) leere Zeilen sind eine Verschwendung

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

Ist das eine große Sache? Oberflächlich gesehen nein. Schließlich fügen die meisten Leute auch leere Zeilen in ihren Code ein, 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. Aber vertikal Der Platz ist immer noch sehr, sehr begrenzt (es sei denn, Sie verwenden einen aufrecht gedrehten 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 entsprechende Klammern (oder andere Blocktrennzeichen) nicht mehr als eine Bildschirmhöhe im Unterschied sein sollten damit Sie den gesamten Block sehen können, ohne zu scrollen.

Dies ist ein grundlegendes Problem: Sobald Sie nicht mehr den gesamten Block auf Ihrem Bildschirm sehen können, wird das Erfassen kompliziert.

Infolgedessen verabscheue ich redundante Leerzeilen. Wo einzelne Leerzeilen entscheidend sind, um unabhängige Blöcke abzugrenzen (sehen Sie sich nur das visuelle Erscheinungsbild dieses Textes an), sind aufeinanderfolgend Leerzeilen ein sehr Schlechter Stil in meinem Buch (und meiner Erfahrung nach sind sie normalerweise ein Zeichen für unerfahrene Programmierer).

Ebenso sollten Linien sein, die einfach eine Klammer halten und die eingespart werden könnten. Ein Block mit einer einzelnen Anweisung, der durch geschweifte Klammern begrenzt ist, verschwendet ein bis zwei Zeilen. Bei nur 50 Zeilen pro Bildschirmhöhe macht sich dies bemerkbar.

Das Weglassen von Zahnspangen schadet vielleicht nicht

Es gibt nur eins Argumente gegen das Weglassen von geschweiften Klammern: Jemand wird dem betreffenden Block später eine weitere Anweisung hinzufügen und vergessen, die geschweiften Klammern hinzuzufügen, wodurch die Semantik des Codes versehentlich geändert wird.

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

Nach meiner Erfahrung ist dies jedoch nicht der Fall. 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. Die Auflösung und das Scoping auf Blockebene sind für Programmierer ein automatischer, tief verwurzelter mentaler Prozess. 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 Klammern gesetzt zu haben: Der Programmierer erinnert sich schließlich auch daran, Einzug die neu hinzugefügte Anweisung korrekt; Der Programmierer hat also bereits mental verarbeitet, dass ein Block beteiligt ist.

Nun, Ich bin nicht und sage, dass das Weglassen von Klammern keine Fehler verursacht. Was ich sage, ist das Wir haben keine Beweise auf die eine oder andere Weise. Wir einfach weiß nicht ob es Schaden verursacht.

Bis mir jemand harte Daten zeigen kann, die aus wissenschaftlichen Experimenten stammen und zeigen, dass dies tatsächlich ein Problem in der Praxis ist, bleibt diese Theorie eine „ nur so Geschichte “: eine sehr überzeugende Hypothese, die es nie gegeben hat auf die Probe stellen, und das muss nicht als Argument verwendet werden.


1 Dieses Problem wird manchmal gelöst, indem alles - einschließlich der Klammern - in dieselbe Zeile gesetzt wird:

if (condition)
{ do_something(); }

Ich glaube jedoch, dass die meisten Leute dies verachten. Darüber hinaus hätte es die gleichen Probleme wie die Variante ohne Klammern, so dass es das Schlimmste aus beiden Welten ist.

27
Konrad Rudolph

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.

19
Steven Evers

Ich würde Folgendes verwenden (den 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 verwenden:

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

oder

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

(Dies ist kein Pseudocode ;-)

16
rubber boots

Ich benutze die Zahnspangenmethode - aus allen oben genannten Gründen plus einen weiteren.

Code wird zusammengeführt. Es ist bekannt, dass es bei Projekten passiert, an denen ich an dieser einzelnen Anweisung gearbeitet habe, wenn sie durch automatische Zusammenführungen unterbrochen wurden. Die beängstigende Sache ist die Einrückung sieht aus richtig, obwohl der Code falsch ist, so dass diese Art von Fehler schwer zu erkennen ist.

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

11
user36294

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

10
Covar

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

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

Auf der positiven Seite fügt ReSharper automatisch die geschweiften Klammern für faule Programmierer in Visual Studio hinzu, und ich gehe davon aus, dass es Addons für andere IDEs gibt, die dies ebenfalls tun.

8
shimonyk

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

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

7
Steven A. Lowe

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

Dazu sage ich "benutze keine Makros". Ich sage auch "rücke deinen verdammten Code richtig ein". In Anbetracht dessen, wie jeder für die Programmierung verwendete Texteditor/jede IDE das Einrücken 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 etwas falsch geschrieben wurde. Immer wenn Emacs anfängt, Einrückungen zu vermasseln, weiß ich normalerweise, dass ich etwas falsch gemacht habe.

In der Praxis folge ich am Ende der vor mir festgelegten Codierungskonvention. Aber diese nerven mich (und machen mich viel glücklicher, wenn ich Python und diese ganze Bracket-Katastrophe ist weg) codiere):

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, nerven mich zwei Aussagen in einer if-Aussage weit mehr als eine einzige Aussage. Meistens, weil dann Klammern erforderlich sind und es mit nur zwei Anweisungen in der if-Anweisung immer noch lustig aussieht.

5
jsternberg

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

Ich benutze dieses Formular, weil ich es lesbarer, optisch ansprechender und einfacher zu tippen finde. Ich benutze dieses Formular nur, wenn diese Bedingungen erfüllt sind. d.h. die Bedingung if 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 Anweisung if (oder über dem Kommentar, falls vorhanden) eine leere Zeile (oder eine Zeile mit nur einer Klammer) steht. Obwohl dies keine Regel ist, der ich bewusst folge, bemerke ich sie jetzt, nachdem ich diese Frage gelesen habe.

Das Einsparen von Bildschirmplatz hat für mich keine Priorität. Wenn ich mehr Platz benötige, würde ich einen größeren Monitor verwenden. Mein Bildschirm ist bereits groß genug, um alles zu lesen, worauf ich mich konzentrieren muss. 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 Verschachtelung stattfindet, dass ich ihn nicht verstehen kann, ohne mehr davon gleichzeitig anzuzeigen, müsste ich überlegen, ob die Logik durch Refactoring besser dargestellt werden könnte.

Im Folgenden finden Sie einige Beispiele, die zeigen, wie ich diese Form der Anweisung if 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 ein Fan von ihnen, weil es dem Code eine gewisse Konsistenz verleiht. Und auch, wie @dsimcha schrieb - weniger Fehlerwahrscheinlichkeit 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 diesen Fällen beim Debuggen und/oder Hinzufügen von Code wahrscheinlich ist.

3

Persönlich gehe ich mit Klammern.

Warum?

Wenn jemand vorbeikommt und Code in die if-Anweisung einfügen muss, ist 100% klar, wo sich der Bereich befindet.

Das Format von if -Anweisungen bleibt konsistent, unabhängig davon, wie viele Anweisungen sich im Block befinden.

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

2
ChrisF

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

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

Ich bevorzuge aus Gründen der Konsistenz geschweifte Klammern, verschwende aber nicht zu viel Leerraum (daher ist in meinem begrenzten Sichtfeld besser lesbarer formatierter Code). Also schreibe ich das für ausreichend kurze Zeilen:

If (cond) { statement; }
1
hotpaw2

Normalerweise benutze ich Zahnspangen, aber es gibt einige Fälle, in denen ich dies nicht tue.

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 albern, sie dort hinzuzufügen. Wenn jemand nach return eine Anweisung hinzufügt, haben wir größere Probleme als Scoping-Probleme.

Wenn für die IDE Code-Formatierung verfügbar ist, verwende ich keine geschweiften Klammern.

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

0
nimcap