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

Warum sagt mir jeder, dass das Schreiben von Code wie diesem 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. Hier ist beispielsweise ein Code zum Zeichnen eines Glow-Effekts für ein Etikett 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 einer Verkettung nutzen, usingsohne 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 dreht sich um die Wartungsprogrammierung 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 verwenden zu wollen, die die Sprache bietet? Die Leute, die diese Sprachen entwerfen, sind schlau. Ich kann mir nicht vorstellen, dass sie eine Funktion einsetzen würden, deren Verwendung immer schlecht ist.
2. Sollten wir oder sollten wir nicht Code schreiben, damit der kleinste gemeinsame Nenner ihn verstehen kann und keine Probleme damit hat?
3. Gibt es ein anderes Argument, das mir fehlt?

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

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

Davon abgesehen neige ich dazu:

if(foo) bar();

Welches kümmert sich um den oben genannten Fall.

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

Lesegeschwindigkeit ...

Abgesehen von dem, was bereits erwähnt wurde. Zu diesem Zeitpunkt war ich bereits darauf 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 lese es etwas langsamer, wenn es so aussieht:

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

Ich habe das deutlich langsamer gelesen als vorher:

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

Weil ich nicht anders kann, als es für alle Fälle noch einmal zu lesen und mich zu fragen, ob der Autor es beabsichtigt hat:

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

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

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

Wenn es etwas Kleines ist, schreibe es so:

if(foo()) bar();

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

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, macht es ihn lesbarer und Sie können den Code schneller analysieren, wenn Sie einen konsistenten Klammerstil haben.

Ein weiterer guter Grund für die Verwendung von geschweiften Klammern neben der Hinzufügung einer zweiten Anweisung zum if ist, dass so etwas passieren könnte:

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

Haben Sie bemerkt, dass die else-Klausel tatsächlich die des "if (b)" ist? Sie haben es wahrscheinlich getan, aber würden Sie darauf vertrauen, dass jemand mit dieser Gotcha vertraut ist?

Wenn also nur aus Gründen der Konsistenz und weil Sie nie wissen, welche unerwarteten Dinge passieren können, wenn jemand anderes (es sind immer die anderen, die dumm sind) den Code ändert, setze ich immer geschweifte Klammern, weil dadurch der Quellcode lesbarer und schneller zu analysieren ist dein Gehirn. Nur für die einfachsten if-Anweisungen, z. B. wenn eine Delegierung vorgenommen wird oder switch-artig ist und Sie wissen, dass die Klausel niemals erweitert wird, würde ich die geschweiften Klammern weglassen.

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.

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

In der Regel würde ich mich immer auf die Seite des Schreibens von Code irren, es sei denn, ich entwickle eine absolut ressourcen- / geschwindigkeitskritische Anwendung

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

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

(c) Einfach zu debuggen, wenn etwas schief geht

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

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

Durch das Weglassen von geschweiften Klammern in den meisten Fällen wird es für mich (b), (c) und (d) schwieriger (Anmerkung jedoch nicht unmöglich). Ich würde sagen, dass die Verwendung von geschweiften Klammern oder nicht keine Auswirkung auf (a) hat.

Ich bevorzuge die Klarheit, die die geschweifte Klammer bietet. Sie wissen genau, was gemeint ist und müssen nicht raten, ob jemand sie nur vermasselt und weggelassen hat (und einen Fehler eingeführt hat). Das einzige Mal, wenn ich sie weglasse, ist, wenn ich das if und die Aktion in dieselbe Zeile setze. Das mache ich auch nicht sehr oft. Eigentlich bevorzuge ich das Leerzeichen, das eingeführt wird, indem die geschweifte Klammer auf eine eigene Linie gesetzt wird. Nach Jahren der K & R C-ähnlichen Programmierung muss ich jedoch daran arbeiten, die Linie mit einer Klammer zu beenden, wenn die IDE dies nicht erzwingt mich.

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

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

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 weg, wenn sie nicht benötigt werden, außer in einigen Fällen 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
}

Einer der Fälle, in denen dies Sie beißen kann, ist in den alten Tagen der C / C ++ - Makros. Ich weiß, dass dies eine C # -Frage ist, aber Codierungsstandards werden häufig ohne die Gründe übertragen, warum der Standard überhaupt erstellt wurde.

Wenn Sie beim Erstellen Ihrer Makros nicht sehr vorsichtig sind, können Probleme mit if-Anweisungen auftreten, die das {} nicht verwenden.

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

if (myCondition) BADLY_MADE_MACRO(myValue)

Versteh mich nicht falsch, ich sage nicht, dass du immer {} tun solltest, um dieses Problem in C / C ++ zu vermeiden, aber ich musste mich aus diesem Grund mit einigen sehr seltsamen Fehlern befassen.

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-Debugging des Produktionscodes, nur um herauszufinden, dass jemand keine geschweiften Klammern mit einer Such- / Ersetzungsänderung kombiniert 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 Protokolle generierte und wir aufgefordert wurden, es zu stoppen. Das Debug-Flag reichte nicht aus, sodass ein Such- und Ersetzungsdruck angebracht war.

Als die App in Produktion ging, war das Debug-Flag deaktiviert und die wichtigen "saveDayData" wurden nie aufgerufen.

BEARBEITEN

Jetzt ist der einzige Ort, an dem ich die geschweiften Klammern nicht benutze, das if / try-Konstrukt.

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

Nachdem ich einem Superstar-Entwickler dabei zugesehen habe.

Ich bin sehr glücklich:

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

return false;

Persönlich verstehe ich 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 natürlich Klammern ein ... aber in diesem Fall sehe ich keinen Grund dafür.

Außerdem werde ich immer geschachtelte Klammern für verschachtelte if setzen, wo ich andere verschachtelt 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 als:

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

Wann immer möglich, verwende ich ternäre Operatoren, aber ich verschachtele sie nie .

Um ehrlich zu sein, sehe ich es als:

Gute Programmierer programmieren defensiv, schlechte Programmierer nicht.

Da es oben einige Beispiele gibt und meine eigenen ähnlichen Erfahrungen mit Fehlern im Zusammenhang mit dem Vergessen von Zahnspangen, habe ich auf die harte Tour gelernt, IMMER STREBEN 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 Making Wrong Code Look Wrong

Sobald Sie wegen fehlender Klammern von einem Fehler gebissen werden, stellen Sie fest, dass fehlende Klammern falsch aussehen, weil Sie wissen, dass möglicherweise ein weiterer Fehler auftritt.

Ich stimme zu: "Wenn Sie klug genug sind, jemanden dazu zu bringen, Sie für das Schreiben von Code zu bezahlen, sollten Sie klug genug sein, sich nicht nur auf Einrückungen zu verlassen, um den Codefluss zu sehen."

Es können jedoch ... Fehler gemacht werden, und dieser Fehler ist schwierig zu beheben ... insbesondere, wenn Sie sich den Code eines anderen ansehen.

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

Offensichtlich muss man irgendwo die Grenze ziehen, wie das Finden dieses glücklichen Mediums zwischen prägnanten und übermäßig beschreibenden Variablennamen. Klammern vermeiden jedoch Fehler und verbessern die Lesbarkeit des Codes.

Sie können argumentieren, dass Leute, die klug genug sind, um Programmierer zu sein, klug genug sind, um Fehler zu vermeiden, die klammerlose Aussagen enthalten. Aber können Sie ehrlich sagen, dass Sie noch nie von etwas so Einfachem wie einem Rechtschreibfehler gestolpert sind? Minutien wie diese können bei großen Projekten überwältigend sein.

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.

Ich verwende gelegentlich den untersten Code (mehrere using-Anweisungen), aber ansonsten setze ich immer die geschweiften Klammern ein. Ich finde nur, dass dies den Code klarer macht. Aus mehr als nur Einrückungen geht hervor, dass eine Anweisung Teil eines Blocks ist (und somit wahrscheinlich Teil eines if usw.).

Ich habe das gesehen

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

Fehler beißen mich (oder besser "ich und Kollegen" - ich habe den Fehler nicht wirklich eingeführt) einmal . Dies trotz der Tatsache, dass unsere damaligen Codierungsstandards die Verwendung von Klammern überall empfahlen. Ich habe überraschend lange gebraucht, um zu erkennen - weil 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 Ende der Linie" verwenden, werden natürlich die zusätzlichen Linien reduziert, aber ich persönlich mag diesen Stil sowieso nicht. (Ich benutze es bei der Arbeit und habe es weniger unangenehm gefunden als erwartet, aber es ist immer noch etwas unangenehm.)

Ich bin beeindruckt und demütigt darüber, dass meine Kollegen auf diesem Gebiet der Computerprogrammierung (Sie viel) nicht von der Aussicht auf mögliche Fehler entmutigt sind, wenn Sie die Klammern in einzeiligen Blöcken überspringen.

Ich denke, das bedeutet, dass ich nicht schlau bin. Ich habe diesbezüglich mehrfach Fehler gemacht. Ich habe die Fehler anderer in dieser Hinsicht getestet. Ich habe gesehen, wie 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 gemacht habe und die mit einer Änderung des Codierungsstils hätten vermieden werden 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. Auch hier bin ich wohl nicht schlau. Um dies zu kompensieren, bin ich seit langer Zeit ein überzeugter Benutzer von Klammern auf einzeiligen Blöcken.

Trotzdem haben sich einige Dinge in der Welt geändert, die die Regel "Du sollst Klammern für einzeilige Blöcke 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 die Einrückung liest, genau wie der Programmierer (z. B. Python).

• Mein Editor formatiert automatisch für mich, sodass die Wahrscheinlichkeit, dass ich durch Einrückungen irregeführt werde, erheblich verringert wird.

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

• Refactoring und Ausdruckskraft der Sprache 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, rücksichtslos umzugestalten und Klammern in einzeiligen Blöcken wegzulassen: Wenn Sie Klammern sehen, kann in Ihrem Kopf ein kleiner Alarm ausgelöst werden, der besagt: "Komplexität hier! Vorsicht!". 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 der Idee, meine Codierungskonvention so zu ändern, dass "einzeilige Blöcke möglicherweise niemals geschweifte Klammern haben" oder "wenn Sie den Block in dieselbe Zeile wie die Bedingung setzen können und alles in 80 Zeichen passt". Klammern weglassen ". Wir werden sehen.

Aus den drei Konventionen:

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

und:

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

und (die einen 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.
• Dies kann die Software ein wenig robuster und fehlerfreier machen. Alle modernen IDEs und erweiterten Texteditoren verfügen jedoch über nette Funktionen zum automatischen Einrücken, die meiner Meinung nach jeder verwenden sollte, solange die Formatierung von Kommentaren nicht durcheinander gebracht wird oder gegen Teamstandards verstößt (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 einer Fehlereinführung etwas verringert wird.
• Ich bevorzuge, dass der boolesche Ausdruck und die Anweisung (en) in verschiedenen Zeilen ausgeführt werden. Ich möchte in der Lage sein, eine Zeile für Debugging-Zwecke zu markieren. Selbst wenn ich eine IDE verwende, in der ich eine Anweisung markieren und darauf zugreifen kann, handelt es sich um eine interaktive Operation, und ich vergesse möglicherweise, wo ich mit dem Debuggen begonnen habe, oder es dauert zumindest ein bisschen länger, bis ich den Code mehrere Schritte durchlaufen habe Zeiten (da ich die Position jedes Mal während des Debuggens manuell markieren muss).

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, die Minimierung der Anzahl der Zeilen in Ihrem Code sollte kein Ziel sein.

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

Ich bin fest davon überzeugt, ordentlichen und prägnanten Code zu schreiben, aber ich würde immer geschweifte Klammern verwenden. Ich finde, dass sie eine bequeme Möglichkeit sind, schnell den Umfang zu erkennen, in dem eine bestimmte Codezeile existiert. Es gibt keine Mehrdeutigkeit, es wird nur explizit vor Ihnen dargelegt.

Einige mögen sagen, es sei ein Präferenzfall, aber ich finde den logischen Ablauf eines Programms viel einfacher zu verfolgen, 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 noch so einer;

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

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

Eine der wichtigsten Fragen ist , wenn Sie Regionen Einzeiler und nicht-Einzeiler, zusammen mit der Trennung von der Steuer statment ( for, if, was Sie hat) und das Ende des statment.

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
}

Früher war ich ein großer Befürworter von "geschweiften Klammern sind ein MUSS!", Aber seit ich Unit-Tests eingeführt habe, finde ich, dass meine Unit-Tests braceless-Aussagen vor folgenden Szenarien schützen:

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

Bei guten Unit-Tests kann ich geschweifte Klammern für einfache Aussagen weglassen, um die Lesbarkeit zu verbessern (ja, das kann subjektiv sein).

Alternativ würde ich für so etwas wie das wahrscheinlich inline setzen, dass es so aussieht:

if (foo) snafu();

Auf diese Weise kann der Entwickler, der der Bedingung bar () hinzufügen muss, den Mangel an geschweiften Klammern besser erkennen und hinzufügen.

Verwenden Sie ein persönliches Urteilsvermögen.

if (foo)
  bar();

ist in Ordnung für sich. Es sei denn, Sie sind wirklich besorgt darüber, dass Idioten später so etwas einbauen:

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

Wenn Sie sich keine Sorgen um Idioten machen, geht es Ihnen 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 selbst stoppt nur die Konversation für ein syntaktisches Element, bis Ihr Auge zur nächsten Zeile wechselt. Nicht was ich mag.

Okay, das ist eine alte Frage, die zu Tode beantwortet wurde. Ich habe etwas hinzuzufügen.

Zuerst muss ich nur USE THE BRACES sagen. Sie können nur zur besseren Lesbarkeit beitragen, und die Lesbarkeit (für Sie und andere!) Sollte auf Ihrer Prioritätenliste ganz oben stehen, es sei denn, Sie schreiben eine Baugruppe. Unlesbarer Code führt immer zu Fehlern. Wenn Sie feststellen, dass Ihr Code durch geschweifte 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 Find (F3) ist Ihr Freund.

Nun zu meinem Zusatz: Es gibt ein Problem damit:

if (foo) bar();

Versuchen Sie, einen Haltepunkt festzulegen, der nur 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 schmerzhaft. 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 aufzuteilen. Und ich stimme ihm zu.

Also mach das:

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

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

if (...) {
    foo();
    bar();
}
else {
    ...
}

Angenommen, Sie haben einen Code:

if (foo)
    bar();

und dann kommt jemand anderes und fügt hinzu:

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

Entsprechend der Art und Weise, wie es geschrieben ist, bar (); wird jetzt bedingungslos ausgeführt. Indem Sie die geschweiften Klammern einschließen, 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 und die fehlenden geschweiften Klammern sehen würde, insbesondere über mehrere Zeilen verteilt, würde ich einen Fehler verursachen. In Fällen, in denen dies gerechtfertigt ist, halten Sie es in einer Zeile, damit die Wahrscheinlichkeit eines solchen Fehlers erneut auf ein Minimum beschränkt wird.

Das Reduzieren von Linien ist kein gutes Argument, um geschweifte Klammern fallen zu lassen. Wenn Ihre Methode zu groß ist, sollte sie wahrscheinlich in kleinere Teile umgestaltet oder umstrukturiert werden. Dies erhöht zweifellos die Lesbarkeit mehr als das einfache Herausnehmen von Zahnspangen.

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

Es ist leicht außer Kontrolle zu geraten, wenn Sie mehrere Verschachtelungen, if / else-Klauseln usw. durchführen, aber ich denke, die meisten Programmierer sollten in der Lage sein, zu sagen, wo sie die Grenze ziehen sollen.

Ich sehe es ein bisschen wie das Argument für if ( foo == 0 )vs if ( 0 == foo ). Letzteres kann Fehler für neue Programmierer (und möglicherweise sogar gelegentlich für Veteranen) verhindern, während Ersteres beim Verwalten von Code leichter schnell zu lesen und zu verstehen ist.

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

Letztendlich muss jemand anderes Ihren Code bearbeiten 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 recht einfach, einen Fehler wie den von Ihnen zitierten zu machen.

Err auf der Seite der 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 in Locken gewickelt sind. Selbst für Einzeiler sind dies einfache Notationen, die Fehler leicht verhindern. Dies macht den Code in dem Sinne lesbarer, dass Sie deutlich sehen, was sich im Block befindet, um den Körper des Blocks 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;
}