Was sind einige Beispiele, wo die Verwendung von Klammern in einem Programm die Lesbarkeit verringert?

Question

Ich dachte immer, dass Klammern die Lesbarkeit verbessern, aber in meinem Lehrbuch steht, dass die Verwendung von Klammern die Lesbarkeit eines Programms dramatisch verringert. Hat jemand Beispiele?

Answer 1

Ich kann zahlreiche Gegenbeispiele finden, bei denen das Fehlen von Klammern die Lesbarkeit verringert hat, aber das einzige Beispiel, das mir einfällt, für das der Autor möglicherweise gemeint hat, ist so etwas wie dies:

if(((a == null) || (!(a.isSomething()))) && ((b == null) || (!(b.isSomething()))))
{
   // mache etwas
}

In diesem Fall sind die ( ) um die Methodenaufrufe unnötig, und dieser Code könnte von der Auslagerung der Bedingungen in Variablen profitieren. Mit all diesen schließenden Klammern in der Mitte der Bedingung ist es schwer zu erkennen, was genau mit was gruppiert ist.

boolean aIstNichtEtwas = (a == null) || !a.isSomething(); // Klammern für die Lesbarkeit
boolean bIstNichtEtwas = (b == null) || !b.isSomething(); // dasselbe
if(aIstNichtEtwas && bIstNichtEtwas)
{
   // mache etwas
}

Ich denke, das obige Beispiel ist lesbarer, aber das ist eine persönliche Meinung. Das könnte das sein, worüber der Autor gesprochen hat.

Einige gute Verwendungen von Klammern:

• um zwischen der Reihenfolge der Operation zu unterscheiden, wenn sich das Verhalten ohne Klammern ändert
• um zwischen der Reihenfolge der Operation zu unterscheiden, wenn das Verhalten unverändert bleibt, aber jemand, der die Bindungsregeln nicht gut genug kennt, Ihren Code liest. Die Regel des guten Bürgers.
• um anzuzeigen, dass ein Ausdruck innerhalb der Klammern ausgewertet werden sollte, bevor er in einem größeren Ausdruck verwendet wird: System.out.println("Die Antwort ist " + (a + b));

Möglicherweise verwirrende Verwendung von Klammern:

• an Stellen, an denen es unmöglich eine andere Bedeutung haben kann, wie vor a.isSomething() oben. In Java ist, wenn a ein Objekt ist, !a allein ein Fehler, also muss klarerweise !a.isSomething() den Rückgabewert des Methodenaufrufs verneinen.
• um eine große Anzahl von Bedingungen oder Ausdrücken zu verknüpfen, die klarer wären, wenn sie aufgeteilt wären. Wie im obigen Codebeispiel kann das Aufteilen der großen Klammeraussage in kleinere Stücke ermöglichen, dass der Code in einem Debugger leichter durchlaufen werden kann, und wenn die Bedingungen/Werte später im Code benötigt werden, wiederholen Sie Ausdrücke nicht und führen Sie die Arbeit nicht zweimal aus. Das ist jedoch subjektiv und offensichtlich bedeutungslos, wenn Sie die Ausdrücke nur an einer Stelle verwenden und Ihr Debugger Ihnen ohnehin Zwischenauswertungen zeigt.

Answer 2

Scheinbar ist dein Lehrbuch von jemandem geschrieben, der Lisp hasst.

Wie auch immer, es ist eine Frage des Geschmacks, es gibt keine allgemeine Wahrheit für jeden.

Answer 3

Ich denke, dass Klammern keine beste Möglichkeit sind, um die Lesbarkeit Ihres Codes zu verbessern. Sie können zum Beispiel eine neue Zeile verwenden, um Bedingungen in einer if-Anweisung zu unterstreichen. Ich benutze keine Klammern, wenn sie nicht erforderlich sind.

Answer 4

Nun, betrachten Sie etwas Ähnliches:

Ergebnis = (x * y + p * q - 1) % t und

Ergebnis = (((x * y) + (p * q)) - 1) % t

Persönlich bevorzuge ich ersteres (aber das bin nur ich), weil letzteres mich glauben lässt, dass die Klammern da sind, um die tatsächliche Reihenfolge der Operationen zu ändern, wenn sie das eigentlich nicht tun. Ihr Lehrbuch könnte auch darauf verweisen, wann Sie Ihre Berechnungen in mehrere Variablen aufteilen können. Zum Beispiel werden Sie wahrscheinlich etwas Ähnliches wie dies haben, wenn Sie eine quadratische Gleichung lösen ax^2+bx+c=0:

x1 = (-b + sqrt(b*b - 4*a*c)) / (2*a)

Was irgendwie hässlich aussieht. Das hier finde ich besser:

WurzelDelta = sqrt(b*b - 4*a*c);
x1 = (-b + WurzelDelta) / (2*a);

Und das ist nur ein einfaches Beispiel, wenn Sie mit Algorithmen arbeiten, die viele Berechnungen beinhalten, können die Dinge wirklich hässlich werden, daher wird die Aufteilung der Berechnungen in mehrere Teile die Lesbarkeit mehr verbessern als Klammern.

Answer 5

Klammern reduzieren die Lesbarkeit, wenn sie offensichtlich überflüssig sind. Der Leser erwartet, dass sie aus einem Grund da sind, aber es gibt keinen Grund. Daher ein kognitiver Hüpfer.

Was meine ich mit "offensichtlich" überflüssig?

• Klammern sind überflüssig, wenn sie ohne Änderung der Bedeutung des Programms entfernt werden können.

• Klammern, die dazu dienen, Infix-Operatoren zu entwirren, sind nicht "offensichtlich überflüssig", auch wenn sie überflüssig sind, außer vielleicht im sehr speziellen Fall von Multiplikations- und Additionoperatoren. Grund: Viele Sprachen haben zwischen 10 und 15 Stufen der Präzedenz, viele Menschen arbeiten in mehreren Sprachen und niemand kann alle Regeln auswendig lernen. Oft ist es besser zu entwirren, selbst wenn Klammern überflüssig sind.

• All andere überflüssige Klammern sind offensichtlich überflüssig.

Überflüssige Klammern finden sich häufig in Code von jemandem, der eine neue Sprache lernt; vielleicht führt die Unsicherheit über die neue Syntax zu defensivem Klammern. Beseitigen Sie sie!

---

Sie haben nach Beispielen gefragt. Hier sind drei Beispiele, die ich wiederholt in ML-Code und Haskell-Code von Anfängern sehe:

• Klammern zwischen if (...) then sind immer überflüssig und ablenkend. Sie lassen den Autor wie einen C-Programmierer aussehen. Schreiben Sie einfach if ... then.

• Klammern um eine Variable herum sind albern, wie in print(x). Klammern sind nie um eine Variable notwendig; die Funktionsanwendung sollte als print x geschrieben werden.

• Klammern um eine Funktionsanwendung herum sind überflüssig, wenn diese Anwendung ein Operand in einem Infixausdruck ist. Zum Beispiel,

  (length xs) + 1

  sollte immer geschrieben werden als

  length xs + 1