Meistens ist dies eine persönliche Präferenz, es gibt jedoch einige Dinge zu beachten.
Mögliche Bugs
Während es kann argumentiert werden , dass durch Vergessen verursacht Bugs Klammern selten sind Add-in, von dem, was ich habe gesehen , dass sie es passieren gelegentlich (nicht das berühmte zu vergessen IOS gehe fehl Fehler). Ich denke, dies sollte ein Faktor sein, wenn Sie Ihren Codestil berücksichtigen (einige Tools warnen vor irreführenden Einrückungen , daher hängt dies auch von Ihrer Toolkette ab) .
Gültige - Code (das heißt , wie es könnte ein Fehler sein)
Auch Ihr Projekt unter der Annahme nicht von einem solchen Fehler leiden, wenn Codelese können Sie einige Code - Blöcke sehen , dass sie aussehen könnten Fehler sein - aber nicht, einige Ihrer mentalen Zyklen nehmen.
Wir beginnen mit:
if (foo)
bar();
Ein Entwickler fügt einen nützlichen Kommentar hinzu.
if (foo)
// At this point we know foo is valid.
bar();
Später erweitert ein Entwickler es.
if (foo)
// At this point we know foo is valid.
// This never fails but is too slow even for debug, so keep disabled.
// assert(is_valid(foo));
bar();
Oder fügt einen verschachtelten Block hinzu:
if (foo)
while (i--) {
bar(i);
baz(i);
}
Oder benutzt ein Makro:
if (foo)
SOME_MACRO();
"... Da Makros möglicherweise mehrere Codezeilen definieren, wird das Makro do {...} while (0)für mehrere Zeilen verwendet? Es sollte, weil es in unserem Style-Guide steht, aber ich überprüfe es besser nur für den Fall!"
Die obigen Beispiele sind alle gültiger Code. Je mehr Inhalt der Codeblock enthält, desto mehr muss gelesen werden, um sicherzustellen, dass keine Fehler vorliegen.
Vielleicht definiert Ihr Codestil, dass mehrzeilige Blöcke eine geschweifte Klammer erfordern (egal, ob sie Code sind oder nicht) , aber ich habe gesehen, dass diese Art von Kommentaren im Produktionscode hinzugefügt wurde. Wenn Sie es lesen, gibt es einen kleinen Zweifel, dass derjenige, der diese Zeilen zuletzt bearbeitet hat, vergessen hat, eine geschweifte Klammer hinzuzufügen. Manchmal habe ich das Gefühl, dass die Überprüfung wie beabsichtigt funktioniert (insbesondere, wenn ein Fehler in diesem Bereich des Codes untersucht wird) .
Diff Noise
Ein praktischer Grund für die Verwendung von geschweiften Klammern für einzelne Linien ist die Reduzierung des Diff-Rauschens .
Das heißt, ändern:
if (foo)
bar();
Zu:
if (foo) {
bar();
baz();
}
... bewirkt, dass die bedingte Zeile in einem Diff als geändert angezeigt wird. Dies fügt einen kleinen, aber unnötigen Overhead hinzu.
- Die Zeilen werden in Code-Überprüfungen als geändert angezeigt. Wenn Ihre abweichenden Tools wortbasiert sind, können Sie leicht feststellen, dass sich nur die geschweiften Klammern geändert haben. Die Überprüfung, ob sich die Zeile überhaupt nicht geändert hat, dauert jedoch länger.
Allerdings unterstützen nicht alle Werkzeuge das wortbasierte Vergleichen. Diff (svn, git, hg ... etc) wird so angezeigt, als ob sich die gesamte Zeile geändert hätte, selbst mit ausgefallenen Werkzeugen. Manchmal müssen Sie schnell über eine einfache Zeile schauen -basiertes Diff, um zu sehen, was sich geändert hat.
- Anmerkungswerkzeuge (z. B.
git blame) zeigen die Linie als geändert an, wodurch die Verfolgung des Ursprungs einer Linie mehr Schritte erfordert, um die tatsächliche Änderung zu ermitteln.
Diese sind beide klein und hängen davon ab, wie viel Zeit Sie für die Codeüberprüfung oder -verfolgung aufwenden, um geänderte Codezeilen festzuschreiben.
Eine spürbarere Schwierigkeit besteht darin, dass zusätzliche Zeilen in einem Diff geändert werden. Die höhere Wahrscheinlichkeit, dass sich der Code ändert, führt zu Konflikten, die zusammengeführt werden und manuell gelöst werden müssen .
Es gibt eine Ausnahme für Code-Basen, die {eine eigene Zeile haben - es ist kein Problem.
Das diff noise- Argument gilt nicht, wenn Sie in diesem Stil schreiben:
if (foo)
{
bar();
baz();
}
Dies ist jedoch keine so verbreitete Konvention, weshalb der Vollständigkeit halber hauptsächlich auf die Antwort verwiesen wird (es wird nicht vorgeschlagen, dass Projekte diesen Stil verwenden sollten) .
