Obligatorische Verwendung von Zahnspangen

Question

Im Rahmen eines Code -Standarddokuments, das ich vor einiger Zeit geschrieben habe, erzwinge ich "Sie müssen immer Klammern für Schleifen und/oder bedingte Codeblöcke verwenden (insbesondere), wenn sie nur eine Zeile sind."

Beispiel:

// this is wrong
if (foo) 
    //bar
else 
    //baz
while (stuff)
    //things

// This is right.
if (foo) {
    // bar
} else {
    // baz
}
while (things) {
    // stuff
}

Wenn Sie keine Single-Line-Zeile einräumen und dann jemand es kommentiert, sind Sie in Schwierigkeiten. Wenn Sie keine einzelne Leitung vornehmen und die Eindrücke nicht dasselbe auf der Maschine eines anderen anzeigt ... Sie sind in Schwierigkeiten.

Also, Frage: Gibt es gute Gründe, warum dies ein falscher oder anderweitiger unangemessener Standard wäre? Es gab einige Diskussionen darüber, aber niemand kann mir ein besseres Gegenargument bieten als "es fühlt sich hässlich" an.

Answer 1

Ich erzwinge dies bis zu einem gewissen Punkt mit geringfügigen Ausnahmen für IF -Anweisungen, die entweder zurückkehren oder eine Schleife fortsetzen.

Dies ist also nach meinem Standard korrekt:

if(true) continue;

Wie das ist das

if(true) return;

Die Regel ist jedoch, dass es sich entweder um eine Rückkehr oder eine Weitergabe handelt und alles in derselben Zeile. Ansonsten Zahnspangen für alles.

Die Argumentation dient sowohl dafür, dass Sie eine Standardmethode haben, als auch um das von Ihnen erwähnte Kommentarproblem zu vermeiden.

Answer 2

Das beste Gegenargument, das ich anbieten kann, ist, dass die zusätzlichen Zeilen, die vom Raum aufgenommen werden, die Menge an Code reduziert, die Sie zu einer Zeit sehen können, und die Menge an Code, die Sie einmal sehen können Es ist, Fehler zu erkennen. Ich stimme den Gründen zu, die Sie für die Einbeziehung von Zahnspangen gegeben haben, aber in vielen Jahren von C ++ kann ich nur einmal an eine Gelegenheit denken, wenn ich einen Fehler gemacht habe, und es war an einem Ort, an dem ich keinen guten Grund für das Überspringen der Klammern hatte ohnehin. Leider konnte ich Ihnen nicht sagen, ob diese zusätzlichen Codezeilen jemals in der Praxis geholfen haben oder nicht.

Ich bin vielleicht voreingenommener, weil ich die Symmetrie von Matching -Klammern auf derselben Einklammerung mag (und die implizite Gruppierung der enthaltenen Aussagen als Ausführungsblock) - was bedeutet, dass das Hinzufügen von Zahnspangen hinzugefügt wird alle Die Zeit fügt dem Projekt viele Zeilen hinzu.

Answer 3

Ich sehe diese Regel als Overkill. Drakonische Standards machen keine guten Programmierer, sie verringern nur die Chancen, dass ein Slob ein Chaos schaffen wird.

Die Beispiele, die Sie geben, sind gültig, haben jedoch bessere Lösungen als die Erzwingung von Klammern:

Wenn Sie keine Single-Line-Zeile einräumen und dann jemand es kommentiert, sind Sie in Schwierigkeiten.

Zwei Praktiken lösen dies besser, wählen Sie einen aus:

1) kommentieren Sie die if, while, usw. Vor dem Einzeiler mit dem Einzeiler. Dh behandelt

if(foo)
    bar();

Wie bei jeder anderen Multi-Line-Anweisung (z. B. eine Zuordnung mit mehreren Zeilen oder einen Funktionsaufruf mit mehreren Zeilen):

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

2) Präfix der Präfix // mit einer ;:

if(foo)
;//    bar();

Wenn Sie keine einzelne Leitung vornehmen und die Eindrücke nicht dasselbe auf der Maschine eines anderen anzeigt ... Sie sind in Schwierigkeiten.

Nein, du bist nicht; Der Code funktioniert gleich, aber es ist schwieriger zu lesen. Beheben Sie Ihre Eindrücke. Wählen Sie Registerkarten oder Leerzeichen und bleiben Sie dabei. Mischen Sie keine Registerkarten und Räume für die Eindrückung. Viele Textredakteure werden dies automatisch für Sie beheben.

Schreiben Sie einen Python -Code. Das wird zumindest einige schlechte Eindringgewohnheiten beheben.

Auch Strukturen mögen } else { Sieh aus wie eine Nethack -Version eines Tie -Kämpfers für mich.

Gibt es gute Gründe, warum dies ein falscher oder anderweitiger unangemessener Standard wäre? Es gab einige Diskussionen darüber, aber niemand kann mir ein besseres Gegenargument bieten als "es fühlt sich hässlich" an.

Redundante Zahnspangen (und Klammern) sind visuelle Unordnung. Visuelle Unordnung macht Code schwerer zu lesen. Der härtere Code ist zu lesen, desto einfacher ist es, Fehler zu verbergen.

int x = 0;
while(x < 10);
{
    printf("Count: %d\n", ++x);
}

Das Erzwingen von Klammern hilft nicht dabei, den Fehler im obigen Code zu finden.

PS Ich bin ein Abonnent der "jede Regel sollte sagen, warum" Schule oder wie der Dalai Lama es ausdrückte: "Kennen Sie die Regeln, damit Sie sie richtig brechen können."

Answer 4

Ich habe noch keinen guten Grund, nicht immer lockige Zahnspangen zu verwenden.

Die Vorteile übertreffen weit über jeden "hässlichen" Grund, den ich gehört habe.

Das Codierungsstandard gibt es, um den Code leichter zu lesen und Fehler zu reduzieren.

Dies ist ein Standard, der sich wirklich auszahlt.

Answer 5

Es fällt mir schwer, mit Codierungsstandards zu streiten, die Fehler reduzieren und den Code lesbarer machen. Es mag sich zuerst für manche Menschen hässlich anfühlen, aber ich denke, es ist eine vollkommen gültige Regel.

Answer 6

Ich stehe auf dem Boden, dass Zahnspangen nach Einrückung übereinstimmen.

// This is right.
if (foo) 
{
    // bar
}
else 
{
    // baz
}

while (things) 
{
    // stuff
}

In Bezug auf Ihre beiden Beispiele würde ich Ihre etwas weniger lesbar betrachten, da das Finden der übereinstimmenden Schließklammern schwierig sein kann, aber in Fällen, in denen die Eindrücke falsch ist, und gleichzeitig die Logik leichter eingefügt werden kann. Es ist kein großer Unterschied.

Auch wenn die Eindrücke falsch ist, wird die IF -Anweisung den nächsten Befehl ausführen, unabhängig davon, ob sie in der nächsten Zeile ist oder nicht. Der einzige Grund, nicht beide Befehle in die gleiche Zeile zu setzen, ist die Unterstützung von Debugger.

Answer 7

Der einzige große Vorteil, den ich sehe, ist, dass es einfacher ist, Bedingungen und Schleifen, die versportet sind, mehr Aussagen hinzuzufügen, und es braucht nicht viele zusätzliche Tastenanschläge, um die Zahnspangen zu Beginn zu erstellen.

Answer 8

Meine persönliche Regel ist, ob es sehr kurz ist, wenn es sich um eine Zeile handelt:

if(!something) doSomethingElse();

Im Allgemeinen benutze ich dies nur, wenn es ein paar solche IFs in Folge gibt.

if(something == a) doSomething(a);
if(something == b) doSomething(b);
if(something == b) doSomething(c);

Diese Situation entsteht jedoch nicht sehr oft, also benutze ich immer Klammern.

Answer 9

Gegenwärtig arbeite ich mit einem Team zusammen, das nach diesem Standard lebt, und obwohl ich dagegen resistent bin, nehme ich um die Einheitlichkeits willen.

Ich objektiere ich aus dem gleichen Grund, den ich gegen Teams einwehte, die die Verwendung von Ausnahmen oder Vorlagen oder Makros verbieten: Wenn Sie eine Sprache verwenden, verwenden Sie die gesamte Sprache. Wenn die Zahnspangen in C und C ++ und Java optional sind, zeigt das Aufschreiben durch Konvention eine gewisse Angst vor der Sprache selbst.

Ich verstehe die in anderen Antworten hier beschriebenen Gefahren und ich verstehe die Sehnsucht nach Einheitlichkeit, aber ich bin nicht sympathisch mit Sprachunterbrechung Abgesehen von einem strengen Technischer Grund, wie der einzige Compiler für einige Umgebungen, die keine Vorlagen aufnehmen oder mit dem C -Code eine breite Verwendung von Ausnahmen ausschließen.

Ein Großteil meines Tages besteht aus der Überprüfung von Änderungen, die von Junior -Programmierern eingereicht wurden, und die gemeinsamen Probleme, die auftreten, haben nichts mit der Platzierung oder Aussagen, die am falschen Ort auftreten. Die Gefahr ist überbewertet. Ich würde lieber meine Zeit damit verbringen, mehr materielle Probleme zu konzentrieren, als nach Verstößen gegen das zu suchen, was der Compiler gerne akzeptieren würde.

Answer 10

Die einzige Möglichkeit, die Codierungsstandards zu kodieren, kann von einer Gruppe von Programmierern gut befolgt werden, besteht darin, die Anzahl der Regeln auf ein Minimum zu halten.

Bildern Sie den Nutzen gegen die Kosten (jede zusätzliche Regel verwirrt und verwirrt Programmierer und verringert nach einem bestimmten Schwellenwert tatsächlich die Chance, dass Programmierer eine der Regeln einhalten).

Also, um einen Codierungsstandard zu erstellen:

• Stellen Sie sicher, dass Sie jede Regel mit klaren Beweisen rechtfertigen können, dass sie besser ist als die Alternativen.

• Schauen Sie sich Alternativen zur Regel an - wird es wirklich benötigt? Wenn alle Ihre Programmierer Whitespace (leere Zeilen und Eindringlinge) verwenden, ist eine IF -Anweisung sehr einfach zu lesen, und es gibt keine Möglichkeit, dass selbst ein Anfängerprogrammierer eine Aussage in einer "wenn" für eine eigenständige Aussage verwechseln kann. Wenn Sie viele Fehler im Zusammenhang mit der If-SCOPING erhalten, ist die Grundursache wahrscheinlich, dass Sie einen schlechten Whitepsace/-Verbindungsstil haben, der Code unnötig schwer zu lesen macht.

• Priorisieren Sie Ihre Regeln nach ihrem messbaren Effekt auf die Codequalität. Wie viele Fehler können Sie vermeiden, indem Sie eine Regel durchsetzen (z. B. "Immer auf Null überprüfen", "immer Parameter mit einem Assert validieren", "schreiben Sie immer einen Unit -Test" versus "Fügen Sie immer einige Klammern hinzu, auch wenn sie nicht benötigt werden"). . Die früheren Regeln sparen Ihnen Tausende von Bugs pro Jahr. Die Klammerregel kann Ihnen eine retten. Vielleicht.

• Behalten Sie die effektivsten Regeln und verwerfen Sie die Spreu. Chaff ist mindestens jede Regel, die Sie mehr implementiert, als alle Fehler, die durch die Ignoration der Regel auftreten könnten. Aber wahrscheinlich, wenn Sie mehr als 30 Schlüsselregeln haben, werden Ihre Programmierer viele von ihnen ignorieren und Ihre guten Absichten als Staub sein.

• Feuern Sie jeden Programmierer, der zufällige Code-Teile aussieht, ohne ihn zu lesen :-)

PS meine Haltung zur Verbreitung lautet: Wenn die Anweisung "if" oder der Inhalt beide eine einzelne Zeile sind, können Sie die Klammern weglassen. Das heißt, wenn Sie einen If-enthalten, der einen einzeiligen Kommentar und eine einzelne Codezeile enthält, sind die Inhalte zwei Zeilen und daher sind Klammern erforderlich. Wenn sich die IF -Bedingung über zwei Zeilen umfasst (auch wenn der Inhalt eine einzelne Linie ist), benötigen Sie Zahnspangen. Dies bedeutet, dass Sie nur Klammern in trivialen, einfachen, leicht zu lesenden Fällen weglassen, in denen in der Praxis nie Fehler gemacht werden. (Wenn eine Aussage leer ist, verwende ich keine Zahnspangen, aber ich habe immer einen Kommentar eingestellt, in dem es darum geht, dass sie leer ist, und absichtlich. Ein Umfang, der eher leer als das Telefon klingelte, und Sie haben vergessen, den Code zu beenden)

Answer 11

Viele Sprachen haben eine Syntax für einen solchen Liner (ich denke an Perl), um mit solch einer "Hässlichkeit" umzugehen. Also so etwas wie:

if (foo)     
//bar
else     
//baz

kann mit dem ternären Operator als ternärische Ternär geschrieben werden:

foo ? bar : baz

und

while (something is true)
{
blah 
}

kann geschrieben werden als:

blah while(something is true)

In Sprachen, die diesen "Zucker" nicht haben, würde ich definitiv die Zahnspangen einbeziehen. Wie Sie sagten, verhindert es unnötige Fehler, sich einzuschleichen und macht die Absicht des Programmierers klarer.

Answer 12

Ich sage nicht, dass es unangemessen ist, aber in mehr als 15 Jahren des Codierens mit C-ähnlichen Sprachen habe ich kein einziges Problem beim Auslassen der Zahnspangen gehabt. Das Auslernen einer Niederlassung klingt in der Theorie nach einem echten Problem - ich habe es einfach nie in der Praxis gesehen.

Answer 13

Ein weiterer Vorteil der Verwendung von Klammern besteht darin, dass Such- und Wiederherstellungen und ähnliche automatisierte Vorgänge erleichtert werden.

Zum Beispiel: Angenommen, ich bemerke das functionB wird normalerweise unmittelbar danach aufgerufen functionA, mit einem ähnlichen Argumentenmuster, und so möchte ich den Code in ein neues umrüsten combined_function. Ein Regex könnte dieses Refactoring leicht bewältigen, wenn Sie kein leistungsstarkes Refactoring -Tool haben (^\s+functionA.*?;\n\s+functionB.*?;) Aber ohne Zahnspangen könnte ein einfacher Regex -Ansatz scheitern:

if (x)
  functionA(x);
else
  functionA(y);
functionB();

würde werden

if (x)
  functionA(x);
else
  combined_function(y);

Kompliziertere Regexes würden in diesem speziellen Fall funktionieren, aber ich habe es sehr praktisch, dass sie in der Lage sein würde, Regex-basierte Such- und Replace, einmalige Perl-Skripte und ähnliche automatisierte Code-Wartung zu verwenden. Daher bevorzuge ich einen Codierungsstil Das macht das nicht unnötig kompliziert.

Answer 14

Ich kaufe mich nicht in dein Argument ein. Persönlich kenne ich niemanden, der jemals "versehentlich" eine zweite Zeile unter einem hinzugefügt hat if. Ich würde verstehen, das zu sagen verschachtelt if Aussagen sollten Zahnspangen haben, um ein baumelnder sonst zu vermeiden, aber als ich sehe, dass Sie einen Stil durchsetzen, weil sie befürchten, dass IMO verlegt ist.

Answer 15

Hier sind die ungeschriebenen Regeln (bis jetzt), die ich gehe. Ich glaube, es bietet Lesbarkeit, ohne die Korrektheit zu beeinträchtigen. Es basiert auf der Überzeugung, dass die Kurzform in einigen Fällen lesbarer ist als die lange Form.

• Verwenden Sie immer Zahnspangen, wenn irgendein Block der if/else if/else Die Aussage hat mehr als eine Zeile. Kommentare zählen, was bedeutet, dass ein Kommentar überall in den bedingten Mitteln alle Abschnitte der bedingten Get -Zahnspangen ist.
• Optional verwenden Klammern, wenn alle Blöcke der Anweisung sind genau eine Zeile.
• Platzieren Sie niemals die bedingte Aussage auf die gleiche Zeile wie die Bedingung. Die Zeile nach der IF -Anweisung wird immer bedingt ausgeführt.

• Wenn die bedingte Aussage selbst die erforderliche Aktion ausführt, ist das Formular:

  for (init; term; totalCount++)
  {
      // Intentionally left blank
  }
  

Sie müssen dies nicht ausführlich standardisieren, wenn Sie einfach Folgendes sagen können:

Lassen Sie niemals die Zahnspangen auf Kosten der Lesbarkeit aus. Wenn Sie Zweifel haben, wählen Sie Klammern.

Answer 16

Ich denke, das Wichtigste an Zahnspangen ist, dass sie definitiv die Absicht des Programmierers ausdrücken. Sie sollten nicht die Absicht aus der Einklingung schließen müssen.

Trotzdem mag ich die Einzellinienrenditen und fährt fort, die von Gus vorgeschlagen wurde. Die Absicht ist offensichtlich und es ist sauberer und leichter zu lesen.

Answer 17

Wenn Sie die Zeit haben, all dies zu lesen, haben Sie die Zeit, zusätzliche Zahnspangen hinzuzufügen.

Answer 18

Ich ziehe es vor, Klammern zu Einsatzbedingungen für Wartbarkeit hinzuzufügen, aber ich kann sehen, wie es ohne Zahnspangen sauberer aussieht. Es stört mich nicht, aber einige Leute könnten durch das zusätzliche visuelle Rauschen ausgeschaltet werden.

Ich kann auch kein besseres Gegenargument anbieten. Es tut uns leid! ;))

Answer 19

Für solche Dinge würde ich empfehlen, nur eine Konfigurationsvorlage für die autoFormatter Ihrer IDE zu finden. Wenn Ihre Benutzer dann auf Alt-Shift-F klicken (oder was auch immer der Tastenanschlag in Ihrer Ide-Wahl ist), werden die Zahnspangen automatisch hinzugefügt. Sagen Sie dann einfach allen: "Gehen Sie voran und ändern Sie Ihre Schriftartung, PMD-Einstellungen oder was auch immer. Bitte ändern Sie jedoch nicht die Regeln für Einrückungen oder automatische Braten."

Dies nutzt die uns zur Verfügung stehenden Werkzeuge, um nicht über etwas zu streiten, das den Sauerstoff wirklich nicht wert ist, der normalerweise dafür aufgewendet wird.

Answer 20

Abhängig auf der Sprache, Es ist nicht obligatorisch, Zahnspangen für eine einköpfige bedingte Aussage oder Schleifenerklärung zu haben. Tatsächlich würde ich sie entfernen, um weniger Codezeilen zu haben.

C ++:

Version 1:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 ) throw InvalidOperation();
   return a/b;
}

Version 2:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 )
   { 
      throw InvalidOperation();
   }
   return a/b;
}

C#:

Version 1:

foreach(string s in myList)
   Console.WriteLine(s);

Version 2:

foreach(string s in myList)
{
   Console.WriteLine(s);
}

Abhängig von Ihrer Perspektive ist Version 1 oder Version 2 lesbarer. Die Antwort ist eher subjektiv.

Answer 21

Wow. NIEMAND ist sich der bewusst sonst ein Problem baumeln? Dies ist im Wesentlichen DAS Grund für immer mit Zahnspangen.

Kurz gesagt, Sie können eine böse mehrdeutige Logik mit anderen Aussagen haben, insbesondere wenn sie verschachtelt sind. Verschiedene Compiler lösen die Mehrdeutigkeit auf ihre eigene Weise auf. Es kann ein großes Problem sein, die Zahnspangen zu lassen, wenn Sie nicht wissen, was Sie tun.

Ästhetik und Lesbarkeit haben nichts zu tun.