it-swarm.com.de

Warum wird es als schlechte Praxis angesehen, geschweifte Klammern wegzulassen?

Warum sagt mir jeder, dass das Schreiben von Code eine schlechte Praxis ist?

if (foo)
    Bar();

//or

for(int i = 0 i < count; i++)
    Bar(i);

Mein größtes Argument für das Weglassen der geschweiften Klammern ist, dass es manchmal doppelt so viele Zeilen mit ihnen geben kann. Im Folgenden finden Sie beispielsweise Code zum Zeichnen eines Glüheffekts für eine Beschriftung in C #.

using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
    for (int x = 0; x <= GlowAmount; x++)
    {
        for (int y = 0; y <= GlowAmount; y++)
        {
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
        }
     }
 }
 //versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
    for (int x = 0; x <= GlowAmount; x++)
        for (int y = 0; y <= GlowAmount; y++)
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));

Sie können auch den zusätzlichen Vorteil der Verkettung von usings erzielen, ohne millionenfach einrücken zu müssen.

using (Graphics g = Graphics.FromImage(bmp))
{
    using (Brush brush = new SolidBrush(backgroundColor))
    {
        using (Pen pen = new Pen(Color.FromArgb(penColor)))
        {
            //do lots of work
        }
    }
 }
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
    //do lots of work
}

Das häufigste Argument für geschweifte Klammern ist die Pflegeprogrammierung und die Probleme, die durch das Einfügen von Code zwischen der ursprünglichen if-Anweisung und dem beabsichtigten Ergebnis entstehen würden:

if (foo)
    Bar();
    Biz();

Fragen:

  1. Ist es falsch, die kompaktere Syntax zu verwenden, die die Sprache bietet? Die Leute, die diese Sprachen entwerfen, sind schlau. Ich kann mir nicht vorstellen, dass sie eine Funktion verwenden, die immer schlecht zu bedienen ist.
  2. Sollten wir oder sollten wir keinen Code schreiben, damit der kleinste gemeinsame Nenner ihn verstehen und problemlos damit arbeiten kann?
  3. Gibt es ein anderes Argument, das mir fehlt?
174
Bob

Eigentlich war das einzige Mal, dass ich wirklich gebissen wurde, als ich debuggte und bar () auskommentierte:

if(foo)
  // bar();
doSomethingElse();

Ansonsten benutze ich meistens:

if(foo) bar();

Welches kümmert sich um den oben genannten Fall.

EDIT Vielen Dank für die Klärung der Frage. Ich stimme zu, wir sollten keinen Code auf den kleinsten gemeinsamen Nenner schreiben.

180
Zachary Yates

Lesegeschwindigkeit ...

Abgesehen von dem, was bereits erwähnt wurde. Zu diesem Zeitpunkt war ich bereits dazu konditioniert, if-Anweisungen mit geschweiften Klammern und Leerzeichen zu analysieren. Also las ich:

if (condition)
{
    DoSomething();
}

DoSomethingElse();

Etwas schneller als ich gelesen habe:

if (condition) DoSomething();

DoSomethingElse();

Ich habe es etwas langsamer gelesen, wenn es so aussieht:

if (condition) DoSomething();
DoSomethingElse();

Ich habe das deutlich langsamer gelesen als vorher:

if (condition) 
    DoSomething();
DoSomethingElse();

ich kann nicht anders, als es noch einmal zu lesen und mich zu fragen, ob der Autor beabsichtigt hat:

if (condition)
{
    DoSomething();
    DoSomethingElse();
}

Im Allgemeinen bereits behandelt, aber wenn es um Lesen unten geht, werde ich mich eine Weile damit befassen, um sicherzustellen, was der Autor beabsichtigt hat. Ich kann sogar den ursprünglichen Autor suchen, um das zu bestätigen.

if (condition) 
    DoSomething();
    DoSomethingElse();
155
CrashCodes

Wenn es etwas Kleines ist, schreibe es so:

if(foo()) bar();

Wenn es lang genug ist, um zwei Zeilen zu teilen, verwenden Sie geschweifte Klammern.

54
Adam Jaskiewicz

Früher dachte ich auch, es sei besser, Zahnspangen nur dann zu verwenden, wenn sie wirklich gebraucht werden. Aber nicht mehr, der Hauptgrund, wenn Sie viel Code haben, wird er dadurch besser lesbar und Sie können den Code schneller analysieren, wenn Sie einen konsistenten Stil für geschweifte Klammern haben.

Ein weiterer guter Grund, immer geschweifte Klammern zu verwenden, ist, dass neben dem Hinzufügen einer zweiten Anweisung zum if Folgendes passieren kann:

if(a)
   if(b)
     c();
else
   d();

Ist Ihnen aufgefallen, dass es sich bei der else-Klausel tatsächlich um die "if (b)" -Klausel handelt? Sie haben es wahrscheinlich getan, aber würden Sie darauf vertrauen, dass jemand mit diesem Fall vertraut ist?

Also, wenn nur aus Gründen der Konsistenz und weil Sie nie wissen, was unerwartete Dinge passieren könnten, wenn jemand anderes (es sind immer die anderen, die dumm sind) den Code ändert, setze ich immer geschweifte Klammern, weil es den Quellcode macht lesbarer, schneller durch Ihr Gehirn zu analysieren. Nur für die einfachsten if-Anweisungen, wie zum Beispiel, wenn eine Delegation vorgenommen wird oder wie ein Schalter, bei dem Sie wissen, dass die Klausel niemals erweitert wird, würde ich die geschweiften Klammern weglassen.

46
FredV

Linien sind billig. Prozessorleistung ist billig. Entwicklerzeit ist sehr teuer.

Wenn ich keine absolut ressourcen-/geschwindigkeitskritische Anwendung entwickle, irre ich mich in der Regel immer auf der Seite, auf der ich Code schreibe

(a) Es ist für jeden anderen Entwickler einfach zu verfolgen, was ich tue

(b) Kommentieren Sie bestimmte Teile des Codes, die diesen möglicherweise benötigen

(c) Leicht zu debuggen, wenn etwas schief geht

(d) Leicht zu ändern, wenn es in Zukunft sein muss (d. h. Hinzufügen/Entfernen von Code)

Die Geschwindigkeit oder akademische Eleganz des Codes ist aus betriebswirtschaftlicher Sicht diesen Faktoren untergeordnet. Das soll nicht heißen, dass ich versucht habe, klobigen oder hässlichen Code zu schreiben, aber dies ist MEINE Prioritätsreihenfolge.

Wenn Sie in den meisten Fällen geschweifte Klammern weglassen, wird (b), (c) und (d) schwieriger (Anmerkung jedoch nicht unmöglich). Ich würde sagen, dass die Verwendung von geschweiften Klammern oder nicht keinen Einfluss auf (a) hat.

35
Jayden

Ich bevorzuge die Klarheit, die die geschweifte Klammer bietet. Sie wissen genau, was gemeint ist, und müssen nicht raten, ob jemand sie einfach vermasselt und weggelassen hat (und einen Fehler gemeldet hat). Das einzige Mal, dass ich sie auslasse, ist, wenn ich if und action in dieselbe Zeile setze. Das mache ich auch nicht sehr oft. Eigentlich bevorzuge ich das Leerzeichen, das durch das Setzen der geschweiften Klammer in eine eigene Zeile eingeführt wird, obwohl das Beenden der Zeile mit einer Klammer nach jahrelanger K & R C-ähnlicher Programmierung eine Übung ist, an der ich arbeiten muss, um zu überwinden, wenn die IDE erzwingt es nicht für mich.

if (condition) action();  // ok by me

if (condition) // normal/standard for me
{
   action();
}
35
tvanfosson

Dies wird nicht immer als schlechte Praxis angesehen. Die Mono Project Coding Guidelines empfehlen, keine geschweiften Klammern zu verwenden, wenn dies nicht erforderlich ist. Gleiches gilt für die GNU Coding Standards . Ich denke, es ist eine Frage des persönlichen Geschmacks, wie immer bei Codierungsstandards.

35
Manuel Ceron

Ich denke, es ist eine Frage der Richtlinien für das Projekt, an dem Sie arbeiten, und des persönlichen Geschmacks.

Ich lasse sie normalerweise aus, wenn sie nicht benötigt werden, mit Ausnahme einiger Fälle wie den folgenden:

if (something)
    just one statement; // i find this ugly
else
{
    // many
    // lines
    // of code
}

ich bevorzuge

if (something)
{
    just one statement; // looks better:)
}
else
{
    // many
    // lines
    // of code
}
23
Maghis

Ich denke immer genauso.

Bis eines Tages (warum gibt es immer diesen "einen Tag", der Ihr Leben für immer verändert?) Verbringen wir 24 bis 36 Stunden ohne Schlaf, um den Produktionscode zu debuggen, nur um herauszufinden, dass jemand keine geschweiften Klammern in Verbindung mit einem Suchen/Ersetzen-Wechsel gesetzt hat .

Es war so etwas.

 if( debugEnabled ) 
      println( "About to save 1 day of work to some very important place.");
 saveDayData();

Was danach kam, war

 if( debugEnabled ) 
 //     println( "About to save 1 day of work to some very important place.");
 saveDayData();

Es stellte sich heraus, dass das System täglich 500 MB an Protokollen generierte, und wir wurden gebeten, dies zu stoppen. Das Debug-Flag reichte nicht aus, so dass ein Suchen und Ersetzen von Drucken in Ordnung war.

Noch als die App in Produktion ging, war das Debug-Flag deaktiviert und das wichtige "saveDayData" wurde nie aufgerufen.

EDIT

Der einzige Ort, an dem ich keine geschweiften Klammern verwende, ist if/try construct.

if( object != null ) try { 
     object.close();
} catch( .....

Nachdem ich einem Superstar-Entwickler dabei zugesehen habe.

15
OscarRyz

Einer der Fälle, in denen dies Sie beißen kann, ist in den alten Tagen von C/C++ - Makros zurück. Ich weiß, dass dies eine C # -Frage ist, aber häufig werden Codierungsstandards ohne Angabe von Gründen übertragen, aus denen der Standard ursprünglich erstellt wurde.

Wenn Sie beim Erstellen Ihrer Makros nicht sehr vorsichtig sind, kann dies zu Problemen mit if-Anweisungen führen, bei denen das {} nicht verwendet wird.

#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)

Versteht mich nicht falsch, ich sage nicht, dass Sie immer {} tun sollten, um dieses Problem in C/C++ zu vermeiden, aber ich musste mich aus diesem Grund mit einigen sehr seltsamen Fehlern auseinandersetzen.

15
Torlack

Ich freue mich sehr über:

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

Ich persönlich verstehe nicht warum

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

ist nicht mehr lesbar.

Ja, Zeilen sind frei, aber warum sollte ich durch Seiten und Codeseiten scrollen müssen, wenn sie halb so groß sein könnten?

Wenn es einen Unterschied in der Lesbarkeit oder Wartbarkeit gibt, setzen Sie Klammern ein ... aber in diesem Fall sehe ich keinen Grund dafür.

Außerdem werde ich immer geschachtelte Klammern setzen, wenn ich andere geschachtelt habe

if (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

vs

if (condition1)
  if (condition2)
    doSomething();
else (condition2)
  doSomethingElse();

ist furchtbar verwirrend, deshalb schreibe ich es immer so:

if (condition1)
{
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();
}

Nach Möglichkeit verwende ich ternäre Operatoren, aber ich nie verschachtele sie .

14
Ozzah

Um stumpf zu sein, sehe ich es als:

Gute Programmierer programmieren defensiv, schlechte nicht.

Da es oben einige Beispiele und meine eigenen ähnlichen Erfahrungen mit Fehlern im Zusammenhang mit dem Vergessen von Zahnspangen gibt, habe ich auf die harte Tour gelernt, STETS ​​ZAHNSTREBEN ZU SETZEN.

Alles andere ist die Wahl des persönlichen Stils gegenüber der Sicherheit, und das ist eindeutig eine schlechte Programmierung.

Joel erwähnt dies sogar in Falschen Code falsch aussehen lassen

Sobald Sie durch einen Fehler aufgrund fehlender Klammern gebissen werden, stellen Sie fest, dass fehlende Klammern falsch aussehen, da Sie wissen, dass es ein potenzieller Ort für das Auftreten eines weiteren Fehlers ist.

13
gman

Ich bin beeindruckt und demütigt darüber, dass meine Kollegen auf diesem Gebiet der Computerprogrammierung (Sie sind sehr) nicht von der Aussicht auf potenzielle Fehler enttäuscht sind, wenn Sie die Klammern bei einzeiligen Blöcken überspringen.

Ich denke, das bedeutet, dass ich nicht schlau bin. Ich habe mehrere Male Fehler gemacht. Ich habe die Fehler anderer behoben. Ich habe gesehen, wie die Software aus diesem Grund mit Fehlern ausgeliefert wurde (RDP auf einem Computer, auf dem VS2002 ausgeführt wird, und die Schriftart Ihres Überwachungsfensters wird wackelig).

Wenn ich mir all die Fehler ansehe, die ich bei einer Änderung des Codierungsstils hätte vermeiden können, ist die Liste sehr lang. Wenn ich nicht in jedem dieser Fälle meinen Ansatz geändert hätte, hätte ich es wahrscheinlich nie als Programmierer geschafft. Ich glaube, ich bin nicht schlau. Um dies auszugleichen, bin ich seit langer Zeit ein überzeugter Benutzer von Klammern an einzeiligen Blöcken.

Allerdings haben sich in der Welt einige Dinge geändert, die die Regel "Du sollst Klammern an einzeiligen Blöcken verwenden" heute weniger relevant machen als zu dem Zeitpunkt, als Moses sie uns vorlegte:

  • Bei einigen gängigen Sprachen wird das Problem behoben, indem der Computer den Einzug liest, genau wie der Programmierer (z. B. Python).

  • Mein Editor formatiert automatisch für mich, daher ist die Wahrscheinlichkeit, dass ich durch Einrückung irregeführt werde, sehr gering.

  • TDD bedeutet, dass, wenn ich einen Fehler einführe, weil ich durch einen einzeiligen Block verwirrt werde, ich den Fehler viel wahrscheinlicher schnell entdecke.

  • Refactoring und Sprachausdruck bedeuten, dass meine Blöcke viel kürzer sind und einzeilige Blöcke viel häufiger vorkommen als früher. Hypothetisch könnte ich mit einer rücksichtslosen Anwendung von ExtractMethod möglicherweise nur einzeilige Blöcke in meinem gesamten Programm haben. (Ich frage mich, wie das aussehen würde?)

Tatsächlich kann es einen deutlichen Vorteil haben, wenn man rücksichtslos umgestaltet und Klammern an einzeiligen Blöcken weglässt: Wenn Sie Klammern sehen, kann in Ihrem Kopf ein kleiner Alarm ausgelöst werden, der besagt: "Komplexität hier! Achtung!". Stellen Sie sich vor, dies wäre die Norm:

if (condition) Foo();   // normal, everyday code

if (condition) 
{
    // something non-trivial hapening; pay attention!
    Foo();
    Bar();
}

Ich öffne mich für die Idee, meine Codierungskonvention in etwas zu ändern, wie "einzeilige Blöcke dürfen niemals geschweifte Klammern haben" oder "wenn Sie den Block in dieselbe Zeile wie die Bedingung setzen können und alles in 80 Zeichen passt". die geschweiften Klammern weglassen ". Wir werden sehen.

10
Jay Bazuzi

Es gibt immer Ausnahmen, aber ich würde dagegen argumentieren, Klammern nur dann wegzulassen, wenn sie in einer der folgenden Formen vorliegen:

if(x == y)
   for(/* loop */)
   {
      //200 lines
   }

//rampion's example:
for(/* loop */)
{
   for(/* loop */)
      for(/* loop */)
      {
         //several lines
      }
}

Ansonsten habe ich kein Problem damit.

10
Tom Ritter

Ich verwende gelegentlich den untersten Code (mehrere using-Anweisungen), aber ansonsten setze ich immer die geschweiften Klammern ein. Ich finde nur, dass der Code dadurch klarer wird. Es ist offensichtlich, dass eine Anweisung nicht nur ein Einzug ist, sondern Teil eines Blocks (und damit wahrscheinlich Teil eines if usw.).

Ich habe das gesehen

if (...)
    foo();
    bar();

fehler beißen mich (oder besser gesagt "ich und Kollegen" - ich habe den Fehler nicht wirklich vorgestellt) einmal. Dies trotz der Tatsache, dass unsere Kodierungsstandards zu der Zeit die Verwendung von Klammern überall empfahlen. Ich habe überraschend lange gebraucht, um zu erkennen, dass Sie sehen, was Sie sehen möchten. (Das war vor ungefähr 10 Jahren. Vielleicht würde ich es jetzt schneller finden.)

Wenn Sie "Klammer am Zeilenende" verwenden, werden die zusätzlichen Zeilen natürlich reduziert, aber ich persönlich mag diesen Stil trotzdem nicht. (Ich benutze es bei der Arbeit und fand es weniger unangenehm als ich erwartet hatte, aber es ist immer noch ein bisschen unangenehm.)

10
Jon Skeet

Ich stimme zu: "Wenn Sie klug genug sind, jemanden zum Schreiben von Code zu bewegen, sollten Sie klug genug sein, sich nicht nur auf Einrückungen zu verlassen, um den Fluss des Codes zu sehen."

Es können jedoch ... Fehler gemacht werden, und dieses Problem ist schwer zu beheben ... vor allem, wenn Sie sich den Code eines anderen ansehen.

10
chills42

Meine Philosophie ist, wenn es den Code lesbarer macht, warum nicht?

Offensichtlich muss man irgendwo die Grenze ziehen, wie zum Beispiel das glückliche Medium zwischen prägnanten und zu beschreibenden Variablennamen. Aber Klammern vermeiden wirklich Fehler und verbessern die Lesbarkeit des Codes.

Sie können argumentieren, dass Menschen, die schlau genug sind, um Programmierer zu sein, schlau genug sein werden, um Fehler zu vermeiden, die Aussagen ohne Klammern enthalten. Aber können Sie ehrlich sagen, dass Sie noch nie von etwas so Einfachem wie einem Rechtschreibfehler gestolpert sind? Minutia wie dieses kann bei großen Projekten überwältigend sein.

10
James McMahon

Aus den drei Konventionen:

if(addCurleyBraces()) bugFreeSofware.hooray();

und:

if(addCurleyBraces())
    bugFreeSofware.hooray();

und (die einen beliebigen Einrückungsstil mit einer öffnenden und einer schließenden Klammer darstellen):

if(addCurleyBraces()) {
    bugFreeSofware.hooray();
}

Ich bevorzuge den letzten als:

  • Ich finde es einfacher zu lesen, wenn alle if-Anweisungen einheitlich geschrieben sind.
  • Dadurch wird die Software möglicherweise ein bisschen robuster und fehlerfrei. Alle modernen IDEs und erweiterten Texteditoren verfügen jedoch über nette automatische Einrückungsfunktionen, die meiner Meinung nach jeder verwenden sollte, solange sie die Kommentarformatierung nicht durcheinander bringen oder gegen Teamstandards verstoßen (in vielen Fällen ist es möglich, ein benutzerdefiniertes Formatierungsschema zu erstellen und teile es mit dem Team). Mein Punkt hier ist, dass bei korrekter Einrückung das Risiko der Einführung von Fehlern ein wenig verringert wird.
  • Ich bevorzuge, dass die booleschen Ausdrücke und Anweisungen in verschiedenen Zeilen ausgeführt werden. Ich möchte in der Lage sein, eine Zeile zu Debug-Zwecken zu markieren. Selbst wenn ich eine IDE verwende, wo ich eine Anweisung markieren und dorthin gehen kann, ist dies eine interaktive Operation, und ich vergesse möglicherweise, wo ich mit dem Debuggen begonnen habe, oder es dauert zumindest ein wenig Etwas mehr Zeit, um den Code mehrmals durchzugehen (da ich die Position jedes Mal beim Debuggen manuell markieren muss).
9
user14070

Ich bin fest davon überzeugt, sauberen und präzisen Code zu schreiben, aber ich würde immer geschweifte Klammern verwenden. Ich finde, dass sie eine bequeme Möglichkeit sind, schnell zu erkennen, in welchem ​​Umfang eine bestimmte Codezeile vorhanden ist. Es gibt keine Mehrdeutigkeit, es ist nur explizit vor Ihnen dargelegt.

Einige mögen sagen, es sei ein Fall der Präferenz, aber ich finde es viel einfacher, dem logischen Ablauf eines Programms zu folgen, wenn es intern konsistent ist, und ich glaube nicht, dass es konsistent ist, eine IF-Anweisung wie diese zu schreiben.

if(x < y)
    x = y;
else
    y = x;

Und ein anderer davon;

if(x < y)
{
    x = y;
    x++;
}
else
{
    y = x;
    y++;
}

Ich ziehe es vor, nur einen allgemeinen Stil zu wählen und dabei zu bleiben :)

Ihre Hauptargumente gegen die Verwendung von geschweiften Klammern sind, dass sie zusätzliche Zeilen verwenden und zusätzliche Einrückungen erfordern.

Zeilen sind (fast) frei, daher sollte es kein Ziel sein, die Anzahl der Zeilen in Ihrem Code zu minimieren.

Die Einrückung ist unabhängig von der Verwendung von Klammern. In Ihrem Beispiel mit Kaskadierung denke ich immer noch, dass Sie sie einrücken sollten, auch wenn Sie die geschweiften Klammern weglassen.

8
Paul Mitchell

Okay, das ist eine alte Frage, die zu Tode beantwortet wurde. Ich muss noch etwas hinzufügen.

Zuerst muss ich nur USE THE BRACES sagen. Sie können nur die Lesbarkeit verbessern, und die Lesbarkeit (für Sie selbst und andere!) Sollte auf Ihrer Prioritätenliste ganz oben stehen, es sei denn, Sie schreiben Assembly. Unlesbarer Code führt immer zu Fehlern. Wenn Ihr Code in geschweiften Klammern zu viel Platz beansprucht, sind Ihre Methoden wahrscheinlich zu lang. Die meisten oder alle Methoden sollten in eine Bildschirmhöhe passen, wenn Sie es richtig machen, und Finden (F3) ist Ihr Freund.

Nun zu meinem Zusatz: Es gibt ein Problem damit:

if (foo) bar();

Versuchen Sie, einen Haltepunkt festzulegen, der nur dann erreicht wird, wenn bar () ausgeführt wird. Sie können dies in C # tun, indem Sie den Cursor auf die zweite Hälfte des Codes setzen, aber das ist nicht offensichtlich und ein bisschen mühsam. In C++ konnte man das überhaupt nicht machen. Einer unserer erfahrensten Entwickler, der an C++ - Code arbeitet, besteht aus diesem Grund darauf, "if" -Anweisungen in zwei Zeilen zu unterteilen. Und ich stimme ihm zu.

Also mach das:

if (foo)
{
    bar(); //It is easy to put a breakpoint here, and that is useful.
}
7
stone

Eines der Hauptprobleme ist, wenn Sie Regionen mit Einzeilen und Nicht-Einzeilen haben, zusammen mit der Trennung von der Kontrollanweisung (for, if, was haben Sie) und dem Ende von die Aussage.

Beispielsweise:

for (...)
{
  for (...)
    for (...) 
    {
      // a couple pages of code
    }
  // which for block is ending here?  A good text editor will tell you, 
  // but it's not obvious when you're reading the code
}
7
rampion

Früher war ich ein großer Befürworter von "geschweiften Klammern sind ein MUSS!", Aber seit ich Unit-Tests übernehme, schütze ich meine Unit-Tests vor den folgenden Szenarien:

if (foo)
    snafu();
    bar();

Bei guten Komponententests kann ich geschweifte Klammern für einfache Aussagen zur Verbesserung der Lesbarkeit getrost weglassen (ja, das kann subjektiv sein).

Alternativ würde ich für so etwas wie das obige wahrscheinlich folgendes inline schreiben:

if (foo) snafu();

Auf diese Weise kann der Entwickler, der der Bedingung einen Balken () hinzufügen muss, das Fehlen von geschweiften Klammern leichter erkennen und diese hinzufügen.

7
Liggy

Verwenden Sie ein persönliches Urteilsvermögen.

if (foo)
  bar();

ist gut für sich. Es sei denn, du machst dir wirklich Sorgen, dass Idioten später so etwas einfügen:

if (foo)
  bar();
  baz();

Wenn du dir keine Sorgen um Idioten machst, geht es dir gut (ich nicht - wenn sie die grundlegende Codesyntax nicht richtig verstehen, ist dies das geringste ihrer Probleme)>

Im Gegenzug ist es viel besser lesbar.

Der Rest der Zeit:

if (foo) {
  bar();
  baz();
}

Welches war mein Favorit, solange ich mich erinnern kann. Zusätzlich:

if (foo) {
  bar();
  baz();
} else {
  qux();
}

Funktioniert bei mir.

Der vertikale Raum an sich ist nicht besonders relevant, die Lesbarkeit jedoch. Die öffnende Klammer in einer Zeile stoppt die Konversation für ein syntaktisches Element, bis sich Ihr Auge zur nächsten Zeile bewegt. Nicht was ich mag.

7
lally

Angenommen, Sie haben Code:

if (foo)
    bar();

und dann kommt jemand anderes und fügt hinzu:

if (foo)
    snafu();
    bar();

Entsprechend der Schreibweise ist bar (); wird jetzt bedingungslos ausgeführt. Indem Sie die geschweiften Klammern einfügen, verhindern Sie diese Art von versehentlichem Fehler. Code sollte so geschrieben sein, dass solche Fehler schwierig oder unmöglich zu machen sind. Wenn ich eine Codeüberprüfung durchführen würde und die fehlenden Klammern, insbesondere über mehrere Zeilen verteilt, sehen würde, würde ich einen Defekt erzeugen. Wenn dies gerechtfertigt ist, lassen Sie es in einer Zeile, damit die Möglichkeit, einen solchen Fehler zu machen, auf ein Minimum reduziert wird.

6
Elie

Das Reduzieren von Linien ist kein gutes Argument, um Klammern fallen zu lassen. Wenn Ihre Methode zu groß ist, sollte sie wahrscheinlich in kleinere Teile zerlegt oder umstrukturiert werden. Wenn Sie dies tun, wird die Lesbarkeit zweifellos mehr verbessert als wenn Sie nur die Zahnspange herausnehmen.

6
plinth

um zu verhindern, dass der Code mit geschweiften Klammern viel Platz einnimmt, verwende ich die im Buch empfohlene Technik Code Complete :

if (...) {
    foo();
    bar();
}
else {
    ...
}
6
Nathan Prather

Ich lasse sie immer weg, wenn es angebracht ist, wie in Ihrem ersten Beispiel. Sauberer, prägnanter Code, den ich sehen und verstehen kann, ist einfacher zu warten, zu debuggen und zu verstehen als Code, durch den ich zeilenweise scrollen und lesen muss. Ich denke, die meisten Programmierer werden dem zustimmen.

Es ist leicht, aus dem Ruder zu gehen, wenn Sie mit der Mehrfachverschachtelung beginnen, if/else-Klauseln und so weiter, aber ich denke, die meisten Programmierer sollten in der Lage sein, zu bestimmen, wo sie die Grenze ziehen sollen.

Ich sehe es wie das Argument für if ( foo == 0 ) vs if ( 0 == foo ). Letzteres verhindert möglicherweise Fehler für neue Programmierer (und gelegentlich sogar für Veteranen), während Ersteres leichter zu lesen und zu verstehen ist, wenn Sie Code warten.

5

Meistens ist es als Kodierungsstandard verankert, ob für ein Unternehmen oder ein FOSS-Projekt.

Letztendlich muss jemand anderes Ihren Code untersuchen und es ist ein großer Zeitaufwand für jeden Entwickler, den spezifischen Stil des Codeabschnitts herauszufinden, an dem er arbeitet.

Stellen Sie sich außerdem vor, dass jemand mehr als einmal am Tag zwischen Python und einer Cish-Sprache wechselt ... In Python ist das Einrücken Teil der Blocksymantik der Sprache und es wäre ziemlich einfach, einen Fehler wie den, den Sie zitieren, zu machen.

4
joshperry

Err auf der Seite von mehr Sicherheit - nur ein weiterer Fehler, den Sie möglicherweise nicht beheben müssen.

Ich persönlich fühle mich sicherer, wenn alle meine Blöcke mit Locken umwickelt sind. Auch für Einzeiler sind dies einfache Notationen, die Fehler leicht verhindern. Dadurch wird der Code besser lesbar, da Sie deutlich sehen, was sich im Block befindet, um den Blockkörper nicht mit den folgenden Anweisungen außerhalb des Blocks zu verwechseln.

Wenn ich einen Einzeiler habe, formatiere ich ihn normalerweise wie folgt:

if( some_condition ) { do_some_operation; }

Wenn die Leitung einfach zu umständlich ist, verwenden Sie Folgendes:

if( some_condition )
{
    do_some_operation;
}
3
Jordan Parmer

Eine alternative Methode, die das Beste aus beiden Welten kombiniert, ist:

if(foo)
   {DoSomething();}

Dies vermeidet Verwechslungen, wenn die Zeile auskommentiert oder eine andere Zeile darunter eingefügt wird.

Außerdem verwenden wir MISRA-C als Codierungsstandard, der erfordert, dass alle Konstrukte wie dieses unter allen Umständen geschweifte Klammern verwenden.

2
Steve Melnikoff

Sie erzählen es Ihnen, weil sie immer noch alte oder generische (nicht sprachbewusste) Quellcode-Editoren verwenden. Wenn Sie einen Editor mit automatischem Einzug verwenden, werden Sie niemals einen Fehler machen, der durch die ständige Verwendung von geschweiften Klammern vermieden werden könnte.

2
Marian
  1. Whitespace ist kostenlos.
  2. Abhängig vom Einzug für zukünftige Lesbarkeit bedeutet abhängig von den Tabulatoreinstellungen, was keine gute Idee ist. Haben Sie jemals an zehn Jahre altem Code gearbeitet, der sich nicht unter Versionskontrolle befand?
  3. Ich habe die Erfahrung gemacht, dass jede Zeit, die Sie sparen, wenn Sie keine geschweiften Klammern eingeben, durch die zusätzliche Zeit, die ich brauche, um herauszufinden, was Sie gemeint haben, mehr als verloren geht.
2
kajaco

Paulus sagte:

Die Einrückung ist unabhängig von der Verwendung von Klammern.

Bei einigen Codierungsstilen ist das nicht der Fall. Wo ich arbeite, können wir nach dem Kodierungsstandard des Unternehmens auf geschweifte Klammern verzichten, wenn dies nicht unbedingt erforderlich ist. Der Kodierungsstandard bewirkt jedoch, dass wir die geschweiften Klammern und die darin enthaltenen Elemente einrücken. Daher ergibt sich Folgendes:

if (something)
  {
    for (i = 0; i < count; i++)
      {
        foo();
      }
  }

Ohne die geschweiften Klammern wird dies:

if (something
  for (i = 0; i < count; i++)
    foo();

Mit diesem Codierungsstil erhalten Sie, wenn es eine tiefe Verschachtelung gibt, zusammen mit langen Variablen- und Funktionsnamen und immer geschweiften Klammern, entweder viel Code auf der rechten Seite des Bildschirms oder viel Zeilenumbruch, beides, IMO machen den Code umständlich zu lesen oder zu debuggen. Aus diesem Grund neige ich immer dazu, die Zahnspange wegzulassen, wenn ich damit durchkomme.

Was das Setzen einer einzelnen Aussage in dieselbe Zeile wie if betrifft, so verbieten dies die Codierungsstandards einiger Unternehmen (unsere eingeschlossen), so dass dies nicht immer eine Option ist.

Wenn es meine Wahl wäre, würde ich den Kodierungsstandard der Firma ändern, damit die geschweiften Klammern mit if, for usw. übereinstimmen und die erste Zeile (oder der erste Kommentar) im Textkörper in derselben Zeile wie die öffnende geschweifte Klammer stehen.

if (something)
{ for (i = 0; i < count; i++)
  { foo();
  }
}

Ich wäre viel eher bereit (und viel wahrscheinlicher), immer geschweifte Klammern zu verwenden (und würde sogar so weit gehen, eine Regel "immer geschweifte Klammern verwenden" zu unterstützen), weil jedes Paar von Klammern nur eine zusätzliche Zeile und keine hinzufügen würde Einrückung, wodurch es fast so kompakt ist, als hätte es überhaupt keine Zahnspange.

1
RobH

Ihr Wartungsprogrammierer vergisst möglicherweise, später geschweifte Klammern einzufügen, wenn er der App Logik hinzufügt. Also passiert folgendes:

if(foo)
bar();
bar(delete);

Anstatt

if(foo) {
bar();
}
 bar(delete);
1
George Stocker
  • Schreiben Sie die geöffnete Klammer in dieselbe Zeile wie die vorherige Anweisung:
    if ( any ) {
        DoSomething();
    }
    
    • Wenn Sie denken, dass dies zu groß ist, können Sie es in einer Zeile schreiben:
      if ( any ) { DoSomething(); }
      

      Wenn du denkst, in einer Zeile ist das nicht so gut lesbar, kannst du es in zwei Zeilen schreiben:

      if ( any ) {
          DoSomething(); }
      if ( any )
          { DoSomething(); }
      
      • In Zukunft muss jemand eine Anweisung in mehrere Anweisungen ändern. Ohne Klammern ist der Wechsel komplizierter. Ja, nur ein bisschen, aber es ist besser, Fehler zu verhindern. Und das Schreiben von Klammern ist sehr einfach und kostengünstig.
  • 1
    TcKs

    Ich denke nicht, dass das Weglassen von Zahnspangen immer eine schlechte Praxis ist, aber ob dies erlaubt ist und unter welchen Umständen dies im Team vereinbart werden muss.

    Ich finde das sehr lesbar: -

    if (foo)
        bar();
    

    und das:-

    if (foo)
        bar()
    else
        snafu();
    

    Wenn eine zusätzliche Zeile hinzugefügt wird: -

    if (foo)
        bar();
        snafu();
    

    Das sieht alles falsch aus, es gibt einen eingerückten Codeblock. aber nicht verspannt.

    Ein ähnliches Argument gilt für eine for-Schleife. Jedoch, wenn ich anfange zu nisten: -

    if (foo)
        if (bar)
            snafu()
    

    Jetzt bin ich in Schwierigkeiten geraten, es sieht aus wie ein Block von Aussagen. Persönlich würde ich die Verwendung von geschweiften Klammern nur für eine Ebene überspringen, je tiefer ich würde, dass der äußere Code geschweifte Klammern verwendet:

    if (foo) {
       if (bar)
           snafu()
    }
    

    Während ich dies schreibe, sind die Antworten von 1 auf 17 gestiegen. Dies wird eindeutig eine emotionale Frage. Ich schlage vor, Sie fügen der Tag-Liste eine subjektive Frage hinzu. )).

    Das Wichtigste ist, im Team eine Einigung darüber zu erzielen, ob und wie es akzeptabel ist und dabei zu bleiben.

    1
    AnthonyWJones

    Ich habe die Zahnspange selbst gehasst. Bis eines Tages fand ich eine Verwendung für sie. Ich arbeite auf verschiedenen Plattformen und portiere die Anwendung von Plattform zu Plattform (insgesamt 6). Wenn Sie unter UNIX vim installiert haben, können Sie leicht zum Ende oder Anfang eines Codeblocks springen, indem Sie 'Shift + 5' drücken. Dies sind meistens if/else-Blöcke oder Schleifen.

    Wenn ich mir also Rampions Problem mit vim anschaue, bin ich total verloren und brauche eine Weile, um den Code vollständig zu verstehen.

    1
    fasih.rana

    Ich denke, es läuft alles auf Vorlieben und Lesbarkeit hinaus. Durch das Hinzufügen von geschweiften Klammern wird Ihr Code aufgrund des zusätzlichen Abstands zwischen den eigentlichen Codezeilen viel besser lesbar. Betrachten Sie auch dieses Beispiel (nicht absichtlich eingerückt):

    if (condition1)
    if (condition2)
    doSomething();
    else
    doSomethingElse();
    

    Wann wird doSomethingElse aufgerufen? Wenn Bedingung1 wahr ist, aber Bedingung2 falsch ist, oder wenn Bedingung1 falsch ist? Das Hinzufügen von geschweiften Klammern löst dieses Lesbarkeitsproblem schnell und vermeidet Verwirrung.

    1
    Aistina

    Ich bin immer ratlos, wenn ich sehe, dass "dieser Stil Platz spart".
    Da ich selten, wenn überhaupt, Code drucke, hat der Speicherplatzgewinn für mich keinen offensichtlichen Vorteil: Das Speichern einiger Bytes auf der Festplatte lohnt sich nicht, und ich bezahle nicht für den auf dem Bildschirm belegten Speicherplatz.
    Manche Leute finden kompakten Code besser lesbar, ich werde das nicht bestreiten (sehr subjektiv), aber als Amateurkünstler und Typograf schätze ich die Verwendung von Whitespace sehr ...

    Ich werde die obigen Argumente nicht wiederholen, aber ich werde Konsistenz hinzufügen: Ich mag keinen Code wie

    if (foo)
    {
      // Lot of code
    }
    else
      DoStuff();
    

    Trotzdem gönne ich mir manchmal keine Klammern: Unter Wachbedingungen, wenn ich vorzeitig aussteige:

    if (somethingBadHappened)
      return;
    

    Zusammenfassend lässt sich sagen, dass das Hinzufügen (fast) systematischer Klammern um signifikanten Code die Lesbarkeit verbessert (Code "atmet", ist nicht beengt), die Konsistenz verbessert und möglicherweise einige dumme Fehler vermeidet (ja, diese Art von Fehler ist offensichtlich, aber der Codierer ist menschlich) (im Allgemeinen), kann müde sein, Neuling, unter Stress ...).

    Ich habe ein Lua-Makro für SciTE erstellt, um diese Klammern mit einem einzigen Tastendruck und korrekter Einrückung um jeden Codeblock oder jede aktuelle Zeile zu setzen: Das kostet mich wirklich nichts.

    Nun, ich werde Sie nicht verklagen, wenn Sie diese Klammern weglassen. Wie bereits erwähnt, kann die eine oder andere Option in Codierungsregeln festgelegt werden. Jedem das Seine.

    0
    PhiLho

    Es handelt sich um einen Kompromiss zwischen kürzerem Code (besser lesbar) und sichererem Code (weniger fehleranfällig).

    Meine 2 Cent:

    1. Es gibt einen Grund für diese Regel. Es wurde von unzähligen Programmierern während langer Arbeitszeiten bis in die Nacht oder am nächsten Morgen entwickelt, um einen Fehler zu beheben, der durch ein wenig Versehen verursacht wurde.
    2. Sie müssen nicht selbst entscheiden, ob sich der Tradeof lohnt.
    3. Nach meiner Erfahrung bin ich einer dieser unzähligen Programmierer, die bis spät in die Nacht gearbeitet haben, um die Ursache für einen bösen Fehler zu finden. Die Ursache war, dass ich faul war.
    0
    Treb

    Ich mag auch die kompaktere Formatierung. Aus diesem Grund drücke ich ständig Strg + K und Strg + D, um eine Neuformatierung in Visual Studio durchzuführen. Ich wünschte nur, ich könnte das nach jedem Tastendruck für mich erledigen lassen.

    0
    Atario

    Einerseits lasse ich die Klammern für eine einzelne Aussage weg. Andererseits überprüfe ich den gesamten C-Code mit PC-Lint ( http://www.gimpel.com/ ), das zwei oder mehr eingerückte Zeilen nach einer if () - Anweisung als "verdächtig" kennzeichnet Vertiefung".

    Übrigens scheint es eine gute Idee zu sein, einzelne Anweisungen in dieselbe Zeile wie if () zu setzen.

    0
    mkClark

    Weil StyleCop es so sagt.

    0
    Armbrat

    Wenn Sie "manchmal" das Gefühl haben, dass es nützlich ist, geschweifte Klammern zu haben, sollten Sie immer geschweifte Klammern hinzufügen, um konsistent zu sein. Programme sollten so geschrieben sein, dass sie von Personen gelesen werden können, die keine Computer sind. Ich bevorzuge Zahnspangen wie:

    if (mybool)
    {
      doMyStuff();
    }
    else
    {
      doMyOtherStuff();
      checkStuff();
    }
    

    und nicht mögen

    if (mybool) {
      doMyStuff();
    }
    else {
      doMyOtherStuff();
      checkStuff();
    }
    

    und nicht mögen

       if (mybool)
         doMyStuff(); 
       else 
       {  
         doMyOtherStuff();
         checkStuff(); 
       }
    
    0

    Ich verwende immer geschweifte Klammern mit Ausnahme der innersten Aussage, vorausgesetzt, die innerste Aussage ist ein Einzeiler. Mein Code sieht also so aus:

    for (int i=0; i<10; i++) 
    {
        for (int x=0; x<20; x++) 
        {
            if (someBoolValue)
                DoThis(x,y);
        }
    }
    

    Die andere Ausnahme ist natürlich das Stapeln mit Anweisungen.

    Es hat absolut keinen Sinn zu schreiben

    using (Stream x = File.Open(...)) 
    {
        using (Stream y = File.Create(...)) 
        {
            ...
        }
    }
    

    wenn du schreiben kannst

    using (Stream x = File.Open(...))
    using (Stream y = File.Create(...)) 
    {
        ....
    }
    
    0
    Chris

    Wenn Sie zum Speichern von Zeilen geschweifte Klammern entfernen oder nicht verwenden, müssen Sie den Code umgestalten.

    0

    Ok, es ist mir immer so vorgekommen, als wäre das eher eine persönliche Präferenz für mich. Ich habe jedoch aus Gründen der Lesbarkeit bemerkt, dass es besser ist, {} zu haben, als sie nicht zu haben. Bei der Verwendung von ReSharper ist mir aufgefallen, dass ReSharper dazu neigt, sie zu löschen, und die meisten von Ihnen tun dies, wenn solche Anweisungen vorliegen

    if(this == yes)
          DoSomething();
    

    Aber der besseren Lesbarkeit halber mache ich das immer

    if(this == yes)
    {
     DoSomething();
    }
    

    Obwohl mit nur einer Codezeile in der "if" -Anweisung die Lesbarkeit nicht wirklich anders ist, aber wenn Sie 20-30 Codezeilen in eine if -Anweisung einfügen, ist es einfacher, mit dem {} dort zu lesen, und es lässt weniger Platz für Fehler und Fehler in Ihrem Code.

    0
    Ironsides