Verbessert Einfachheit immer die Lesbarkeit?

Vor kurzem habe ich eine Reihe von Codierungsstandards für unser Unternehmen entwickelt. (Wir sind ein neues Team, das in eine neue Sprache für das Unternehmen verzweigt.)

Bei meinem ersten Entwurf habe ich den Zweck unserer Codierungsstandards in der Verbesserung der Lesbarkeit, Wartbarkeit, Zuverlässigkeit und Leistung festgelegt. (Ich habe Beschreibbarkeit, Portabilität, Kosten, Kompatibilität mit früheren Standards usw. ignoriert.)

Eines meiner Ziele beim Schreiben dieses Dokuments war es, die Idee der Einfachheit des Codes durchzusetzen. Die Idee war, dass es nur einen Funktionsaufruf oder eine Operation pro Zeile geben sollte. Ich hatte die Hoffnung, dass dies die Lesbarkeit verbessern würde. Es ist eine Idee, die ich aus unserer vorherigen Sprache übernommen habe.

Ich habe jedoch die Annahme hinter diesem Vorstoß in Frage gestellt:

Verbessert Einfachheit immer die Lesbarkeit?

Gibt es einen Fall, in dem das Schreiben von einfacherem Code die Lesbarkeit beeinträchtigt?

Es sollte offensichtlich sein, aber mit "einfacher" meine ich nicht "einfacher zu schreiben", sondern weniger Dinge, die pro Zeile passieren.

"Einfach" ist ein überstrapaziertes Wort. "Lesbar" kann gewinnbringend als "einfach zu verstehen" definiert werden. In diesem Fall erhöht ein gewisses Maß an Einfachheit per Definition die Lesbarkeit, aber ich denke nicht, dass Sie das so meinen. Ich habe geschrieben über diese an anderer Stelle , aber in der Regel etwas kann „einfacher“ entweder aufgerufen werden , um mehr abstrakt zu sein (in diesem Fall weniger Konzepte können mehr Phänomene ausdrücken) oder konkreter zu sein (in diesem Fall ein Konzept erfordert nicht so viel Hintergrund Wissen, das man überhaupt verstehen muss). Ich argumentiere, dass ein abstrakteres Konzept, abhängig von der Perspektive, vernünftigerweise einfacher genannt werden kann als ein konkreteres Konzept oder umgekehrt . Dies, obwohl "abstrakt" und "

Ich werde als Beispiel einen Haskell-Code verwenden, den ich vor einiger Zeit geschrieben habe. Ich habe eine Frage zum Stackoverflow zur Verwendung der Listenmonade gestellt , um einen Zähler zu berechnen, bei dem jede Ziffer eine andere Basis haben könnte. Meine mögliche Lösung (ich kenne nicht viel von Haskell) sah so aus:

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Eine der Antworten reduzierte dies auf:

count = mapM (enumFromTo 0)

Welche davon "einfacher" zu verstehen (dh besser lesbar) ist, hängt ganz davon ab, wie gut sich der Leser mit (abstrakten) monadischen Operationen (und im Übrigen mit punktfreiem Code) vertraut gemacht hat. Ein Leser, der mit diesen abstrakten Konzepten sehr vertraut ist, wird es vorziehen, die (kurze) abstraktere Version zu lesen, während ein Leser, der mit diesen Operationen nicht vertraut ist, es vorziehen wird, die (lange) konkretere Version zu lesen. Es gibt keine Antwort darauf, welche Version besser lesbar ist und für jedermann gilt.

Wenn es in Ihrem Codierungsstandard um "Lesbarkeit, Wartbarkeit, Zuverlässigkeit und Leistung" geht, geben Sie dies einfach an .

Versuchen Sie nicht, festzulegen, wie diese Ziele erreicht werden sollen, da es immer Situationen gibt, in denen es ein Gegenbeispiel gibt.

Was Sie vorschreiben müssen, sind Dinge, die dazu führen, dass der Code beschädigt wird, wenn sie nicht beachtet werden. Stilmerkmale brechen den Code nicht und sollten Vorschläge sein (solange die Mehrheit des Teams der Meinung ist, dass es Lesbarkeit ist, sollte der Rest von den Entwicklern bevorzugt werden (mit Codeüberprüfung, damit der Gruppendruck die Leute daran erinnert, dass andere Leute den Code lesen müssen). .

Weniger "Zeug pro Zeile", Einfachheit und Lesbarkeit sind nicht dasselbe. Man kann einen unglaublich komplizierten undurchsichtigen undokumentierten Algorithmus nehmen und ihn mit 1 Anweisung pro Zeile anstelle von 2 codieren, und er wird nicht so viel lesbarer.

Für weniger "Zeug pro Zeile" müssen Entwickler möglicherweise auch große Monitore bereitstellen, damit sich die Codeblöcke jetzt vertikaler ausbreiten. Oder beim Lesen winzigerer Schriftarten eine Belastung für die Augen verursachen.

Die Ablesbarkeit ist eine eigene Metrik, die häufig einen Kompromiss zwischen mehreren anderen, leichter messbaren Metriken erfordert. Beschränken Sie alle anderen Metriken auf ein Minimum, und der Kompromiss wird nicht mehr möglich, was zu weniger lesbarem Code führt.

Immer? - NEIN

Ironischerweise kann es ein komplexes Unterfangen sein, das richtige Maß an Einfachheit zu erreichen. Ich denke, der Schlüssel ist in Maßen. Einfachheit kann auch im Auge des Betrachters liegen. Wenn Sie es also überdenken, lassen Sie es einfach in Ruhe oder kehren Sie zu einem späteren Zeitpunkt zurück.

Persönlich konzentriere ich mich beim Versuch, etwas zu vereinfachen, das ich geschrieben habe, auf Bereiche, in denen ich meine Meinung geändert oder ein paar Dinge ausprobiert habe, um das zu erreichen, was ich wollte. Diese Bereiche können normalerweise geglättet werden. Machen Sie dann einfach ein paar Durchgänge durch den Code, um ihn lesbarer zu machen, ohne die Dinge so weit zu verbreiten, dass Sie überall herumspringen, um herauszufinden, was bei einem Debug passiert.

Der Einfachheit halber kann ich folgenden Code schreiben:

10000000000000000000000000000000000000000000

Aber wenn ich Lesbarkeit anstrebe, dann bevorzuge ich Folgendes:

1e43

Auf der anderen Seite 1000ist es viel lesbarer und einfacher, als 1e3wenn Sie die ganze Zeit mit Zahlen in wissenschaftlicher Notation arbeiten.

Dies ist ein entartetes Beispiel für ein viel allgemeineres Muster, das Sie fast überall finden können - das Bauen von Objekten aus sehr einfachen Blöcken kann auf viele verschiedene Arten schnell unlesbar / ineffizient / schlecht werden. Das Verallgemeinern und Wiederverwenden ist auf der anderen Seite anfangs schwieriger ("wtf ist e?! Wollten sie schreiben 1343?", Könnte jemand sagen), kann aber auf lange Sicht viel helfen.

Nicht unbedingt. Wenn Sie eine komplexe Operation haben, muss diese Komplexität irgendwo hin. Wenn Sie die Anzahl der "Dinge" auf einer Zeile reduzieren, werden nur mehr Zeilen belegt, was sich nachteilig auf die Lesbarkeit des Codes auswirken kann, wenn Ihre Routine zu "groß" ist, um auf einen Bildschirm zu passen.

Klarheit + Standards + Wiederverwendung von Code + Gute Kommentare + Gutes Design können die Lesbarkeit verbessern .

Die Einfachheit liegt nicht immer in der Hand des Entwicklers, da die Art der Algorithmen und die Komplexität der Anwendungsstruktur heutzutage wichtig sind.

Nehmen Sie die einfachen Webseiten, die einfache Aufgaben ausführen. Bei einer gegebenen Sortierroutine ist es nicht möglich, die Logik zu vereinfachen, aber Sie können sie durch Kommentare, Verwendung von aussagekräftigen Variablennamen, strukturiertes Schreiben usw. klarer machen.

Verbessert Einfachheit immer die Lesbarkeit?

Nein. Ich habe viele Fälle gesehen, in denen mehrere einfachere Dinge in einer Zeile weniger komplex sind als mehrere Zeilen.

Es gibt einen Kompromiss zwischen weniger Code und einfacherem Code.

Im Allgemeinen würde ich empfehlen, einfacheren Code zu verwenden, es sei denn, Sie sind sicher, dass es besser ist, weniger Zeilen zu verwenden. Ich hätte viel lieber "zu ausführlichen" Code als "zu komplexen" Code.

"Machen Sie die Dinge so einfach wie möglich, aber nicht einfacher" - Eine häufig verwendete Umschreibung von Albert Einstein

Einfachheit verbessert alles . Natürlich aus Gründen der Einfachheit. Ist es weniger Codezeilen? Vielleicht. Ist es eine kleinere ausführbare Datei? Möglicherweise. Muss sich Ihr Team darauf einigen? Absolut .

Verbessert Einfachheit immer die Lesbarkeit? Ja. Ist eine Aussage pro Zeile immer einfacher? Nein. Nicht wenige Sprachen haben einen ternären Operator, der nach dem Erfassen einfacher und verständlicher ist als die entsprechenden if / else-Zuweisungen.

In Sprachen, in denen mehrere Variablen in einer Zeile gesetzt werden können, ist dies häufig einfacher und verständlicher als das Äquivalent.

Ein weiteres Beispiel: Reguläre Ausdrücke tun viel, normalerweise nur in einer Zeile, und das Äquivalent ohne Regex ist häufig viel schwerer zu lesen. / \ d {3} [-] \ d {3} - \ d {4} / entspricht einem Funktionsaufruf mit mindestens mehreren Kommentaren und ist leichter zu verstehen als der entsprechende Funktionskörper.

Lesbarkeit und Einfachheit sind subjektive Begriffe, die je nach Person und Kontext in der Regel aber nicht immer zusammenpassen.

Ein objektiverer Begriff ist Prägnanz - etwas, das man im Prinzip durch das Zählen von Zeichen zählen kann, obwohl dies einige Mängel aufweist. Prägnanz scheint Einfachheit und Lesbarkeit zu implizieren, aber es gibt (zumindest meiner Meinung nach) Ausnahmen.

Ein längerer (und vermutlich komplexerer) Code kann besser lesbar sein, wenn er die Absicht besser ausdrückt. Ob Ihre Definition von Einfachheit sich um Absichten kümmert, ist eine andere subjektive Sache - Sie könnten Komplexität beispielsweise in Bezug auf die syntaktische Struktur und die informationstheoretische Entropie definieren, ohne überhaupt auf Absichten Bezug zu nehmen.

Ein gut gewählter längerer Variablenname kann also ...

• Verbessern Sie die Lesbarkeit, indem Sie Ihre Absicht besser ausdrücken
• Reduzieren Sie die Prägnanz - es ist immerhin länger
• Hat keinerlei Einfluss auf die syntaktische Einfachheit - die syntaktische Struktur des Codes bleibt unverändert

Ebenso könnte ich schreiben if (some_boolean == true). Im Vergleich zur gleichwertigen Alternative if (some_boolean)...

• Reduziert die Prägnanz
• Reduziert aber die syntaktische Einfachheit
• Kann die Lesbarkeit verbessern, indem die Absicht besser zum Ausdruck gebracht wird.

Natürlich wird dies einen Massenprotest auslösen - für viele Menschen schadet dies immer auch der Lesbarkeit. Für mich hängt es stark von der Quelle des Booleschen ab - z. B. kann der Variablenname (oder Methodenname oder was auch immer) nicht eindeutig ausdrücken, dass der Wert "Wahrheitswert" ist. Klar, das ifsagt dir etwas, aber es riecht immer noch. Aber viele Leute werden mich einen Idioten nennen, weil sie das glauben.

Das ist natürlich ein weiterer Beweis für die allgemeine Subjektivität.

Ihnen allen fehlen einige grundlegende Definitionen . Einfach, vom Wurzel -Simplex , bedeutet eine Falte . Einfach bedeutet , eine Sache zu tun . Einfach, von der Wurzel leicht, bedeutet nah dran liegen . Einfach bedeutet, dass es in greifbarer Nähe ist . Die Beispiele für einfachen Code in anderen Antworten sind nicht genau das, was sie angezeigt werden.

Nehmen Sie die Anzeige von rotsor mit einem sehr großen Wert. Er sagt, das sei einfach . Ist meiner Einschätzung nach nicht einfach. Es ist einfach. Es ist ganz in der Nähe, die Anzahl der erforderlichen Nullen einzugeben.

10000000000000000000000000000000000000000000

Die lesbare Version ist einfach. Es macht eine Sache. Es drückt die Zahl aus, indem es ihre Größe in einem für diese Funktion erstellten Notationszweck beschreibt.

1e43

Könnten Sie Aidans "einfaches" Code-Snippet als eine Sache beschreiben? Es enthält 10 Codezeilen (ohne Kommentare) und mindestens 7 Blöcke (wie ich sie zählen würde). Wenn Sie den Kommentaren folgen, werden Sie sehen, dass es mindestens 4 Dinge tut!

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Eine der Empfehlungen zum Umschreiben dieses Codes war jedoch eine Aussage. Aidan gibt an, dass ein Leser mit monadischen Anweisungen, zeigerfreiem Code usw. vertraut sein muss oder werden muss. Das ist in Ordnung. Diese Konzepte sind einzigartig und unabhängig zu lernen.

count = mapM (enumFromTo 0)

Sie werden feststellen, dass wirklich einfacher Code besser lesbar ist als einfacher Code, da er nur eine Aufgabe erfüllt. Möglicherweise müssen Sie loslegen und mehr "one things" lernen, um zu verstehen den einfachen Code . Es sollte aber immer besser lesbar sein.

Verbessert Einfachheit immer die Lesbarkeit?

Ich würde sagen, vielleicht mit ein bisschen Kontroverse, absolut nicht .

Sie könnten mir eine Klasse mit 200 Member-Funktionen in ihrer öffentlichen Schnittstelle übergeben, und es könnte die am besten lesbare öffentliche Schnittstelle sein, die es gibt. Es könnte eine Freude sein, diesen Code und seine Dokumentation nur beiläufig durchzulesen. Ich würde es jedoch nicht als "einfach" bezeichnen, da ich mich trotz der Lesbarkeit mit der Interaktion all dieser Funktionen befassen und möglicherweise auf knifflige Randfälle achten müsste, die aus einem Missbrauch resultieren.

Ich würde eine Klasse mit 20 Mitgliedsfunktionen bevorzugen, die nicht so einfach zu lesen waren wie 200, weil "Lesbarkeit" für mich nicht die oberste Priorität ist, um menschliches Versagen zu verhindern und die Wartbarkeit von Code zu verbessern (die Leichtigkeit, mit der wir können es ändern, dh).

Dies hängt jedoch alles von unserer persönlichen Definition von "Einfachheit" ab. „Readability“ variiert typischerweise nicht , dass wild unter uns, es sei denn , jemand so viel Know - how und Geläufigkeit erworben hat , dass sie regex betrachten als sehr „lesbar“, zum Beispiel, zu vergessen , den Rest von uns Sterblichen.

Einfachheit

Vor langer Zeit dachte ich, "Einfachheit" bedeute "so leicht zu lesen wie möglich". Deshalb habe ich C-Code mit vielen praktischen Funktionen geschrieben, um die Syntax zu verbessern und das Lesen und Schreiben so einfach wie möglich zu gestalten.

Als Ergebnis habe ich sehr große, umfangreiche Bibliotheken auf hoher Ebene entworfen und versucht, eine Funktion für jeden natürlichen menschlichen Gedanken zu modellieren: Helfer auf Helfer auf Helfer, um den Client-Code in eine lesbarere Syntax umzuwandeln. Der Code, den ich damals geschrieben habe, war vielleicht der "lesbarste", aber auch der "nicht wartbarste" und "komplexeste".

Lispeln

Trotzdem hatte ich Mitte der 90er Jahre eine kurze Leidenschaft für LISP (Latecomer). Es hat meine ganze Vorstellung von "Einfachheit" verändert.

LISP ist nicht die am besten lesbare Sprache. Hoffentlich denkt niemand, dass das Extrahieren von CDRs und CARs beim Aufrufen einer rekursiven Funktion mit einer Schiffsladung geschachtelter Klammern sehr "lesbar" ist.

Trotzdem hat es meine Vorstellung von Einfachheit nachhaltig verändert, nachdem ich Mühe hatte, mein Gehirn mit der seltsamen Syntax und den völlig rekursiven Methoden der Sprache zu beschäftigen.

Mit dem Code, den ich in LISP geschrieben habe, habe ich festgestellt, dass ich keine subtilen Fehler mehr gemacht habe, obwohl ich durch diese trickreiche Denkweise offensichtlichere Fehler gemacht habe (aber diese sind leicht zu erkennen und zu korrigieren). Ich habe nicht missverstanden, was eine Funktion tut, und eine subtile, unerwartete Nebenwirkung übersehen. Ich hatte es einfach leichter, Änderungen vorzunehmen und korrekte Programme zu schreiben.

Nach LISP ging es für mich in der Einfachheit um Minimalismus, Symmetrie, Flexibilität, weniger Nebenwirkungen und weniger, aber flexiblere Funktionen, die auf unendlich viele Arten kombiniert werden können.

Ich lernte die Einstellung zu schätzen, dass der zuverlässigste Code überhaupt Code ist, den es nicht gibt. Obwohl es sich nur um eine grobe Metrik handelt, sehe ich das Potenzial für die Unzuverlässigkeit von Code in Abhängigkeit von seiner Menge. Das Bemühen um größtmögliche syntaktische Bequemlichkeit und Lesbarkeit führt dazu, dass sich diese Menge um einen großen Faktor erhöht.

Minimalismus

Mit der in mir eingebetteten LISP-Denkweise bevorzuge ich minimalistische APIs. Ich würde eine Bibliothek mit weniger, aber zuverlässigeren, flexibleren Funktionen bevorzugen, die weniger bequem und weniger lesbar sind als eine Bibliothek, die eine Fülle "bequemer" Helfer bietet und die den Code leicht "lesbar" macht, aber möglicherweise darüber stolpert Weitere Probleme mit Unzuverlässigkeit und Überraschungen, die sich aus Missverständnissen ergeben, was eine dieser Tausenden von Funktionen bewirkt.

Sicherheit

Eine andere Sache bei LISP war die Sicherheit. Es förderte minimale Nebenwirkungen und reine Funktionen und das war der Punkt, an dem ich keine subtilen Fehler mehr sah, obwohl die Schwierigkeit, in der Sprache zu lesen und zu schreiben, zu offensichtlichen Fehlern führte, die ich 10 Sekunden später bemerkte.

Reine Funktionen und unveränderliche Zustände wurden mir immer dann vorzuziehen, wenn ich es mir leisten konnte, auch wenn die Syntax von:

sword = sharpen(sword)

... ist etwas unkomplizierter und vom menschlichen Denken losgelöst als:

sharpen(sword)

Lesbarkeit VS. Einfachheit

Wiederum ist LISP nicht die am besten lesbare Sprache. Es kann eine Menge Logik in einen kleinen Codeabschnitt packen (möglicherweise mehr als ein menschlicher Gedanke pro Zeile). Ich bevorzuge im Idealfall einen menschlichen Gedanken pro Zeile für "Lesbarkeit", aber es ist nicht unbedingt für "Einfachheit".

Mit dieser Art der Definition von "einfach" könnte "einfach" manchmal tatsächlich etwas mit "lesbar" konkurrieren. Hierbei geht es eher um die Gestaltung der Benutzeroberfläche.

Eine einfache Benutzeroberfläche bedeutet, dass Sie viel weniger lernen müssen, um sie zu verwenden. Aufgrund ihres Minimalismus sind sie potenziell zuverlässiger und haben weniger Fallstricke. Eine umfassende Dokumentation zu diesem Thema könnte eher in eine Broschüre passen als in ein riesiges Buchvolumen. Trotzdem kann es sein, dass es mehr Arbeit erfordert und weniger lesbaren Code liefert.

"Einfach" verbessert für mich die Fähigkeit, die Funktionalität in unserem System auf einer breiten Ebene zu verstehen. "Lesbar" verbessert für mich die Fähigkeit, jede kleine Codezeile mit der natürlichen Sprache und dem natürlichen Denken zu verknüpfen, und beschleunigt möglicherweise unser Verständnis der Funktionen einer Codezeile, insbesondere wenn wir die Sprache nicht fließend beherrschen.

Regex ist ein Beispiel für das, was ich für "extrem einfach" halte. Es ist "zu einfach und zu unleserlich" für meinen persönlichen Geschmack. Es gibt für mich einen Spagat zwischen diesen Extremen, aber regex hat diese LISP-ähnliche Qualität der Einfachheit, wie ich sie definiere: Minimalismus, Symmetrie, unglaubliche Flexibilität, Zuverlässigkeit usw. Das Problem für mich bei regex ist, dass es so einfach ist, dass es so einfach ist Es ist so unlesbar geworden, dass ich nicht mehr denke, dass ich es jemals fließend beherrschen werde (mein Gehirn funktioniert einfach nicht so und ich beneide Leute, die fließend Regex-Code schreiben können).

Das ist meine Definition von "Einfachheit", und es ist völlig unabhängig von "Lesbarkeit" und kann manchmal sogar stören, was zu einem Balanceakt zwischen einer "syntaktisch bequemen" und lesbaren, aber größeren Bibliothek oder einer "syntaktisch" führt unbequeme ", weniger lesbare und dennoch kleinere Bibliothek. Ich habe immer die wahren Prioritäten "Bequemlichkeit des Verstehens" und "Wartbarkeit" gefunden, um mich an letzteren auszurichten, mit der starken Vorliebe für Minimalismus, selbst wenn die Lesbarkeit und die natürlichere menschliche Syntax darunter leiden (aber nicht bis zur Regex). . YMMV.

Immer? - JA

Das richtige Maß an Einfachheit zu erreichen, ist ein komplexes und schwieriges Unterfangen. Aber immer lohnenswert, da es die Lesbarkeit immer verbessert. Ich denke, der Schlüssel ist tiefes Verständnis. Einfachheit ist ein Absolut, gemessen an "neuen Konzepten" pro "Stück" Code. Ein paar neue Konzepte bedeuten einfacher.

Konzentrieren Sie sich auf Bereiche, in denen es eine dichte Ansammlung von Begriffen gibt, und suchen Sie nach Wegen, um "zusammenzufassen" oder "zusammenzufassen" oder "zusammenzufassen". Durchlaufen Sie den Code ein paar Mal, um ihn einfacher und besser lesbar zu machen.

Eine gute Abstraktion ist Gold wert. Eine gute Abstraktion macht dies einfacher - und damit lesbarer.

Die Fragen erinnern mich an diese Antwort auf Stack Overflow, insbesondere an dieses Zitat (einfach Qualität ersetzen):

Qualität - Sie wissen, was es ist, aber Sie wissen nicht, was es ist. Das ist aber selbst widersprüchlich. Aber manche Dinge sind besser als andere, das heißt, sie haben mehr Qualität. Aber wenn Sie versuchen zu sagen, was die Qualität ist, abgesehen von den Dingen, die sie haben, geht alles schief! Es gibt nichts zu reden. Aber wenn Sie nicht sagen können, was Qualität ist, woher wissen Sie, was es ist, oder woher wissen Sie, dass es überhaupt existiert? Wenn niemand weiß, was es ist, dann existiert es für alle praktischen Zwecke überhaupt nicht. Aber für alle praktischen Zwecke existiert es wirklich. Worauf basieren die Noten noch? Warum würden die Leute sonst für einige Dinge Vermögen bezahlen und andere in den Müll werfen? Offensichtlich sind einige Dinge besser als andere - aber was ist die "Betterness"? - So rund und rund du gehst, Geistesräder drehen und nirgendwo einen Ort finden, um Traktion zu bekommen. Was zur Hölle ist Qualität? Was ist es?

Ich denke, es ist wichtig, dass Sie bedenken, dass ein kodifizierter Kodierungsstandard für alle seine Vorteile gute Programmierer nicht aus schlechten machen wird. Ein Wort wie "einfach" kann von verschiedenen Personen unterschiedlich interpretiert werden (siehe Antwort von Aidan Cully), aber das ist vielleicht keine so schlechte Sache. Junior-Programmierer müssen ihren Code noch von erfahrenen Programmierern überprüfen lassen und erfahren, warum die Interpretation von 'einfach' durch Senior-Programmierer besser ist als ihre eigene.

Ein Funktionsaufruf pro Leitung ist einfacher? Lassen Sie uns ein Beispiel versuchen!

=== One call per line ===
x = y.getThis()
a = x.getThat()
b = a.getSomethingElse()

=== Less "simple" version ===
b = y.getThis().getThat().getSomethingElse()

Was denkst du? Ist ein Anruf pro Leitung tatsächlich einfacher?