Swift-style-guide: Die diskrete Verwendung von Klammern macht das Weglassen unnötiger Klammern zunichte

Erstellt am 14. Juni 2017  ·  6Kommentare  ·  Quelle: raywenderlich/swift-style-guide

Wir haben uns kürzlich entschieden, diesen Styleguide zu übernehmen, aber die folgende Aussage hat uns einige Kopfschmerzen bereitet:

In größeren Ausdrücken können optionale Klammern manchmal dazu führen, dass der Code klarer gelesen wird.

Um genau zu sein, ist _größerer Ausdruck_ sehr subjektiv, und ein Entwickler, der eher daran gewöhnt ist, bedingte Anweisungen in Klammern zu setzen, wird darauf bestehen, dass die Verwendung von Klammern die Lesbarkeit verbessert. Als Minimalist würde ich gegen jede Verwendung von Klammern argumentieren, wenn sie die Bedeutung der bedingten Anweisung nicht ändert.

Irgendwelche Gedanken?

Hilfreichster Kommentar

Ich stimme @designatednerd zu. Persönlich bevorzuge ich auch Klammern um Ausdrücke. Ich bin auch ein Minimalist, aber ich glaube, dass Code für die Leute lesbar und klar sein sollte; ansonsten ist es dem Compiler egal. So wie ich es sehe, erwarte ich nach = eine einfache Zuweisung, zB let thing = foo . Eine Klammer danach ist jedoch ein visueller Hinweis darauf, dass die Zuweisung irgendwo später stattfindet, wahrscheinlich am Ende der Zeile:

let thing = ( /* some short or long logic here, skip it */ ) ? foo : bar

Alle 6 Kommentare

Viele der Stellen, an denen ich sie als hilfreich gesehen habe, sind die Klärung, wo eine Gleichheitsprüfung als einzelner boolescher Wert verwendet wird:

let thing = thingA == thingB
// vs. 
let thing = (thingA == thingB)

Die Reihenfolge der Operationen dort macht deutlich, dass thing ein boolescher Wert ist, der den Wert "ist thingA gleich thingB , aber das visuelle Parsen dauert viel länger mit die erste Option als die zweite.

Dies ist auch bei zusammengesetzten Anweisungen hilfreich, obwohl sie manchmal auch notwendig sind, um die Reihenfolge der Operationen zu klären:

if thingC && (thingD || thingE) { ...

Im Grunde ist es meist über Scannbarkeit: Wenn es Sie dauert noch eine Sekunde länger zu analysieren , wie Sie durch sie zu lesen, dass alte , sehr kurz wird. Und wenn Nachwuchsentwickler viel länger brauchen, um über die Geschehnisse nachzudenken, kann dies die Tür zu einer Katastrophe öffnen.

Ich stimme @designatednerd zu. Persönlich bevorzuge ich auch Klammern um Ausdrücke. Ich bin auch ein Minimalist, aber ich glaube, dass Code für die Leute lesbar und klar sein sollte; ansonsten ist es dem Compiler egal. So wie ich es sehe, erwarte ich nach = eine einfache Zuweisung, zB let thing = foo . Eine Klammer danach ist jedoch ein visueller Hinweis darauf, dass die Zuweisung irgendwo später stattfindet, wahrscheinlich am Ende der Zeile:

let thing = ( /* some short or long logic here, skip it */ ) ? foo : bar

@samkim102 Wenn ich Ihre Frage richtig gelesen habe, fragen Sie nicht nach den Fällen, die in den anderen Kommentaren angesprochen wurden, sondern nach der Verwendung von Klammern um die Bedingung einer if Anweisung.

Wenn dies der Fall ist, helfen Sie mir bitte zu verstehen, wie ich deutlicher erklären kann, dass in diesem Fall keine Klammern verwendet werden sollten. Der aktuelle Wortlaut des Leitfadens erscheint mir eindeutig.

Beobachtung: Die Regel könnte dahingehend geändert werden, dass Klammern nur verwendet werden, wenn dies der Übersichtlichkeit dient. Ich glaube, die ursprüngliche Richtlinie wurde dort aufgestellt, um Folgendes zu verhindern:

// go for a Sunday drive
if (day.isSunday) {
   vehicle.drive()
}

Auf der anderen Seite, wenn Sie Klammern weglassen, weil Sie die Rangfolge der anderen beteiligten Operatoren kennen, sind Sie wahrscheinlich zu schlau für Ihr eigenes Wohl.

Das Problem, so wie ich es verstehe, ist, dass einige Leute zu denken scheinen, dass Eltern in allen Fällen aus Gründen der Klarheit erforderlich sind. Dies ist in den meisten Fällen bei if und switch Anweisungen eindeutig nicht der Fall. Die Verwendung in Zuweisungsanweisungen ist, wie andere Kommentatoren erwähnt haben, ein dunklerer Sumpf. "Fördert Klarheit" ist ein subjektives Kriterium, das hier nicht weiterhilft.

Wenn ich in der nächsten Woche nicht mehr vom ursprünglichen Autor höre, werde ich dies mangels Aktivität schließen.

Wegen fehlender Reaktion geschlossen.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

agirault picture agirault  ·  3Kommentare

xezun picture xezun  ·  6Kommentare

grosch picture grosch  ·  6Kommentare

ghost picture ghost  ·  26Kommentare

rayfix picture rayfix  ·  3Kommentare