Alle anderen Antworten verteidigen die Regel 3 Ihres Dozenten.
Ich möchte sagen, dass ich mit Ihnen übereinstimme: die Regel ist überflüssig und ich würde nicht dazu raten. Es ist wahr, dass es theoretisch verhindert Fehler, wenn Sie immer geschweifte Klammern hinzufügen. Andererseits, Dieses Problem ist mir im wirklichen Leben noch nie begegnet. Im Gegensatz zu dem, was andere Antworten vermuten lassen, habe ich nicht ein einziges Mal vergessen, die geschweiften Klammern hinzuzufügen, sobald sie notwendig wurden. Wenn Sie eine korrekte Einrückung verwenden, wird es sofort klar, dass Sie geschweifte Klammern hinzufügen müssen, sobald mehr als eine Anweisung eingerückt ist.
Die Antwort von Komponente 10 weist auf den einzigen denkbaren Fall hin, in dem dies wirklich zu einem Fehler führen könnte. Andererseits ist bei der Ersetzung von Code durch reguläre Ausdrücke ohnehin immer große Vorsicht geboten.
Betrachten wir nun die andere Seite der Medaille: Gibt es eine Nachteil immer geschweifte Klammern zu verwenden? Die anderen Antworten ignorieren diesen Punkt einfach. Aber es es ein Nachteil: Er nimmt viel vertikalen Platz auf dem Bildschirm ein, was wiederum dazu führen kann, dass Ihr Code unlesbar wird, weil Sie mehr als nötig scrollen müssen.
Betrachten Sie eine Funktion mit vielen Schutzklauseln am Anfang (und ja, das Folgende ist schlechter C++-Code, aber in anderen Sprachen wäre dies eine recht häufige Situation):
void some_method(obj* a, obj* b)
{
if (a == nullptr)
{
throw null_ptr_error("a");
}
if (b == nullptr)
{
throw null_ptr_error("b");
}
if (a == b)
{
throw logic_error("Cannot do method on identical objects");
}
if (not a->precondition_met())
{
throw logic_error("Precondition for a not met");
}
a->do_something_with(b);
}
Dies ist ein schrecklicher Code, und ich behaupte, dass der folgende Code wesentlich besser lesbar ist:
void some_method(obj* a, obj* b)
{
if (a == nullptr)
throw null_ptr_error("a");
if (b == nullptr)
throw null_ptr_error("b");
if (a == b)
throw logic_error("Cannot do method on identical objects");
if (not a->precondition_met())
throw logic_error("Precondition for a not met");
a->do_something_with(b);
}
Auch bei kurzen, verschachtelten Schleifen ist es von Vorteil, die geschweiften Klammern wegzulassen:
matrix operator +(matrix const& a, matrix const& b) {
matrix c(a.w(), a.h());
for (auto i = 0; i < a.w(); ++i)
for (auto j = 0; j < a.h(); ++j)
c(i, j) = a(i, j) + b(i, j);
return c;
}
Vergleiche mit:
matrix operator +(matrix const& a, matrix const& b) {
matrix c(a.w(), a.h());
for (auto i = 0; i < a.w(); ++i)
{
for (auto j = 0; j < a.h(); ++j)
{
c(i, j) = a(i, j) + b(i, j);
}
}
return c;
}
Der erste Code ist prägnant, der zweite Code ist aufgebläht.
Und ja, dies kann gemildert werden bis zu einem gewissen Grad indem Sie die öffnende geschweifte Klammer auf die vorherige Zeile setzen. Wenn Sie also auf geschweifte Klammern bestehen, setzen Sie zumindest die öffnende Klammer auf die vorherige Zeile.
Kurz gesagt: Schreiben Sie keinen unnötigen Code, der Platz auf dem Bildschirm wegnimmt.
In der Zeit, seit ich die Antwort geschrieben habe, habe ich den vorherrschenden Codestil größtenteils akzeptiert und verwende geschweifte Klammern, es sei denn, ich kann die gesamte einzelne Anweisung in die vorherige Zeile setzen. Ich bin immer noch der Meinung, dass der Verzicht auf redundante geschweifte Klammern in der Regel besser lesbar ist, und ich habe noch nie auf einen dadurch verursachten Fehler gestoßen.
