Verbessert Einfachheit immer die Lesbarkeit?

32

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.

Richard
quelle
16
Wenn die Alternative "kluger" Code ist, dann ja ...
Oded
2
ja - pro Ockhams Rasiermesser - en.wikipedia.org/wiki/Occam%27s_razor
aggietech
17
Vermeiden Sie es, so starre Begriffe wie immer und niemals zu verwenden. Dies soll vermeiden, sich auf Randfälle zu konzentrieren, und sich stattdessen auf die häufigsten Probleme konzentrieren, mit denen wir konfrontiert sind. Darum geht es bei Best Practices.
P.Brian.Mackey
Eigentlich möchten Sie 2 Funktionen / Operationen pro Zeile. a = bist eine Operation, b + cist eine Sekunde, was bedeutet, a = b + c2 Operationen. Das Verketten von 2 Funktionen / Operatoren ist weiterhin lesbar:, foo(bar())oder a = foo().
zzzzBov
2
Sorgen Sie sich auch nicht zu viel. Wenn Sie versuchen, jedes bisschen Subjektivität aus Ihren Erklärungen zu streichen, genau wie wenn Sie versuchen, jedes mögliche Detail des Codierungsstils in einer Million oder mehr Regeln anzugeben, werden Ihre Standards überkomplex, unleserlich, ignoriert und daher sinnlos.
Steve314

Antworten:

47

"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.

Aidan Cully
quelle
11
Einige Entwickler werden Fortschritte machen, bis sie den Einzeiler verstehen und bevorzugen. Kaum vorstellbar, dass ein Entwickler, der den Einzeiler versteht, die Langversion bevorzugt. Daher ist IMO der Einzeiler deutlich besser.
Kevin Cline
7
@kevincline - vorausgesetzt, der Entwickler arbeitet isoliert, stimme ich zu, die kürzere Version ist (wahrscheinlich) besser. Wenn sie als Teil eines Teams arbeitet und das Team nicht auf dem Niveau ist, auf dem sie den Einzeiler verstehen und bevorzugen, und sie alle in der Lage sein müssen, den Code zu pflegen, ist die Langversion unter diesen Umständen (wahrscheinlich) besser .
Aidan Cully
6
Als Kontrapunkt: Da Sie ein erfahrener Haskeller sind, können Sie die zweite Version auf einen Blick lesen. Die erste Version würde andererseits das Lesen und Verstehen von wesentlich mehr Code erfordern; Sie konnten es nicht auf einen Blick tun. Ich denke, das macht die zweite Version einfacher.
Tikhon Jelvis
6
@ Steve314: mapMist ziemlich idiomatisch und enumFromTomacht genau das, was es verspricht . Im Allgemeinen finde ich, dass es tatsächlich einfacher ist , einzelne Fehler zu machen, wenn Sie den Code erweitern - es gibt einfach mehr Code, um einen Fehler zu machen. Dies ist besonders deutlich bei Dingen wie for-Schleifen im Vergleich zu Prozeduren höherer Ordnung in anderen Sprachen , aber ich finde es ein allgemeines Prinzip.
Tikhon Jelvis
1
@Tikhon - aber das bedeutet nicht unbedingt, dass man so viel Code liest, und der Code ist genau dort. Das heißt, es kann Kompromisse geben. Normalerweise stark einseitig, um vorhandene Funktionen zu nutzen, anstatt das Rad neu zu erfinden, aber es gibt Ausnahmen. Dies wird in C ++ mit einigen der trivialeren "Algorithmen" in der Standardbibliothek sehr deutlich - ihre Verwendung kann gelegentlich ausführlicher und weniger klar sein als das direkte Schreiben des Codes.
Steve314
13

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). .

Martin York
quelle
Das war das Ziel, das ich anstrebte, und das war das erklärte Ziel. Die Einfachheit (oder vielmehr die eine Funktion / Operation pro Zeile) schien natürlich aus diesem Ziel zu folgen. Ich versuche festzustellen, ob mein Verständnis ungültig war. Wenn Sie Codierungsstandards erstellen, ist das Festlegen von Regeln und Richtlinien der gesamte Punkt der Übung. Zu vage Regeln und Richtlinien festzulegen, ist nutzlos. Daher hilft diese Antwort nicht wirklich.
Richard
5
Mein Argument ist, dass das Setzen von zu strengen Regeln schlimmer als nutzlos und tatsächlich schädlich ist. Das Festlegen von Regeln wie eine Anweisung pro Zeile ist stilistisch. Dies ist das, was definitiv NICHT in den Code-Richtlinien enthalten sein sollte. Es bietet keinen tatsächlichen Nutzen und kann die Lesbarkeit und Wartbarkeit beeinträchtigen, wenn es unüberlegt angewendet wird.
Martin York
3
+1 (weil ich nicht +10 kann) Ein häufiger Fehler, den ich bei neuen Programmmanagern sehe, ist, dass sie versuchen, jedes Detail zu kodieren. Die besten Codierungsstandards sind eher Glückskekse als Rezepte.
JohnFx
"Codierungsstile und -standards" war der Name des Dokuments. Offensichtlich ist dies kein Standard (wie in "Never use GoTo" oder "Never use short ints"), sondern ein Stil. Die Vereinheitlichung des Stils ist wichtig für die Lesbarkeit und Wartbarkeit.
Richard
1
Style Guide: "Dieses Projekt verwendet Tabulatoren / Leerzeichen (wählen Sie eines aus). Dieses Projekt verwendet den Klammerstil K & R / Allman / BSD / GNU (wählen Sie eines aus). Bitte fügen Sie keine Leerzeichen am Zeilenende hinzu Code ordentlich und lesbar. Alles wird von zwei Teammitgliedern und Ihnen selbst überprüft: Für Lesbarkeit / Wartbarkeit benötigen Sie eine Mehrheit von 2/3, um den Code einzuchecken. Für Zuverlässigkeit und Leistung benötigen Sie 3/3 Weitere Regeln werden hinzugefügt, wenn diese missbraucht werden :-) "Fertig.
Martin York
7

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.

hotpaw2
quelle
5

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.

DKnight
quelle
5

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.

Rotsor
quelle
Ihr Argument, dass "1e3" weniger lesbar ist als "100", ist gut formuliert. Tatsächlich ist dies ein hervorragendes Beispiel dafür, wie die kognitive Belastung die Lesbarkeit beeinflusst. "1e3" erfordert das Lesen von 3 Zeichen UND das Übersetzen der Potenzierung. Das Lesen von "100" erfordert das Lesen von 3 Zeichen und keine weitere Auswertung.
Stephen Gross
Stephen, eigentlich muss man beim Lesen einer dreistelligen Zahl 100zwei Multiplikationen und zwei Additionen durchführen ( 0+10*(0+10*1)). Wenn Sie sich an diese Schreibweise gewöhnt haben, merken Sie das nicht einmal. Dies zeigt erneut, wie subjektiv der Begriff der Einfachheit sein kann.
Rotsor
Interessant. Genau genommen erfordert "100" zwei Multiplikationen (1 * 100, 0 * 10) und zwei Additionsoperationen. "1e3" erfordert eine Multiplikationsoperation. Ohne kognitiven Kontext ist "100" schwerer zu lesen als "1e3". Aber! Wenn Sie die kontextabhängige kognitive Belastung mit einbeziehen, ist die Berechnung anders. Da wir normalerweise ganze Zahlen in nicht wissenschaftlicher Form lesen, ist "100" einfacher. Wenn wir jedoch eine technische App schreiben, in der alle Zahlen in wissenschaftlicher Notation ausgedrückt werden, ist die Form "1e3" einfacher!
Stephen Gross
2

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.

Mason Wheeler
quelle
Komplexität ist nicht irreduzibel. Wir haben "Abstraktion" und "Chunking" und "Organisation", um zu versuchen, die Komplexität zu managen. Ich würde denken, dass eine komplexe Operation in einer Reihe von einfacheren Schritten beschrieben werden kann. Es funktioniert für viele reale physikalische Prozesse: Zusammenfassungen, Übersichten usw.
S.Lott
1
@S.Lott: Richtig, aber genügend Scrollen und Strg-Klick können die Verfolgung eines "vereinfachten" Prozesses erschweren. Ich habe es ein- oder zweimal gesehen (es ist nicht üblich, aber es kann sehr frustrierend sein, damit zu arbeiten, wenn es zu weit geht).
FrustratedWithFormsDesigner
3
@S.Lott - es gibt noch Grenzen, wie weit Komplexität reduziert werden kann. Sie können unnötige Komplexität eliminieren, aber Sie können nur die erforderliche Komplexität verwalten (nicht eliminieren) - die Komplexität, die den Anforderungen inhärent ist. Möglicherweise erhöhen die Mechanismen zur Steuerung der Komplexität auch die Komplexität - eine zusätzliche Komplexität führt dazu, dass irrelevante Komplexität aus dem Weg geräumt wird, um die relevanten Details für einen bestimmten Aspekt / ein bestimmtes Problem / ein bestimmtes Konstrukt besser aufzudecken.
Steve314
1
@ S.Lott - Nun, es ist sicher richtig, dass Sie jede gewünschte Anforderung mit einer (vollständig leeren) Quelldatei mit null Komplexität darstellen können. Da Sie jedoch eine sehr spezifische Sprache benötigen, um Ihre Anforderungen zu erfüllen, müssen Sie Ihre Anforderungen nur in die Sprachspezifikation verschieben.
Steve314
1
@S.Lott - Wenn Sie behaupten, Sie könnten die Position von Jupiter am Weihnachtstag nur mit Verstand vorhersagen G=0, denke ich, dass Sie verrückt sind. Wenn nicht, verpasst du meinen Standpunkt. Sie können zwar irrelevante Details abstrahieren, aber es ist nicht irrelevant, wenn Ihre Anforderungen dies für relevant halten. Wenn Sie zurücklesen, habe ich nie behauptet, dass alle Komplexität notwendig ist - nur, dass einige Komplexität den Anforderungen inhärent ist und nicht beseitigt werden kann.
Steve314
2

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.

Keine Chance
quelle
2

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.

Tom Squires
quelle
1

"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 .

Jesse C. Slicer
quelle
+1 für das Zitat, aber verbessert die Einfachheit die Lesbarkeit?
Richard
"Machen Sie die Dinge so einfach wie möglich und vereinfachen Sie sie dann" ist eine bessere Umschreibung, da SW-Ingenieure dazu neigen, über das Engineering hinauszugehen.
Mattnz
1
Ich wünschte, die Leute würden aufhören zu sagen "Mach die Dinge so einfach wie möglich, aber nicht einfacher". Können wir nicht zumindest auf MakeAsGoodAsPossibleButNoMoreSo <Thing, Attribute> verallgemeinern, wenn wir uns dem unnütz allgemeinen Engineering-Tipp zuwenden? (Entschuldigung @Jesse C. Slicer, Sie sind bei weitem nicht die einzige Person, die dies zitiert. Sie verdienen den Mini-Rant also nicht mehr als jeder andere).
PSR
1

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.

jmoreno
quelle
1

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.

Steve314
quelle
1

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.

Anthony Mastrean
quelle
1

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.


quelle
0

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.

S.Lott
quelle
Ich kann nicht anders, als zu denken, dass Ihre Angstzitate da sind, weil Sie sich bewusst sind, dass "Konzept" und "Chunk" selbst subjektiv sind. Ein einziges Konzept einer Person ist eine Mischung aus drei unterschiedlichen Ideen einer anderen Person. Es ist schwer, ein absolutes und objektives Maß für subjektive Dinge zu haben.
Steve314
@ Steve314: Zitate erschrecken? Nr en.wikipedia.org/wiki/Chunking alle scheinen ähnlich zu sein, dass sie eine Vereinfachung durch Chunking beschreiben. (Mit Ausnahme der Gitarrentechnik scheint das anders zu sein.) Die Anführungszeichen sind da, weil es so viele alternative Begriffe für Abstraktion, Chunking, Zusammenfassung usw. gibt. Die Zitate sollen betonen, dass dies irgendwie umstritten ist. Noch. Es ist eindeutig die ganze Zeit getan und scheint eine natürliche menschliche Tendenz zu sein.
S.Lott
Was ich nicht leugne - Chunking wird die ganze Zeit durchgeführt und ist eine gute Idee. Was ich leugne - dass es eine definitive objektive Regel dafür gibt, wo die Grenzen zwischen Stücken sein sollten. Meine Argumente mögen eher umständlich als hilfreich sein, aber ich bezweifle immer noch, dass "immer" in "immer die Lesbarkeit verbessert".
Steve314
@ Steve314: Wir abstrahieren immer, fassen zusammen und fassen zusammen, um uns zu helfen, Dinge zu verstehen. Immer. Chunking, Abstracting, Summation ("Vereinfachung") ist etwas, was wir immer tun. Wir machen es einfach. So nimmt unser Gehirn die Realität wahr. Vereinfachung verbessert immer die Lesbarkeit und kann immer durchgeführt werden.
S.Lott
ja, tun wir. Ich habe nie etwas anderes gesagt.
Steve314
-2

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.

KaptajnKold
quelle
1
Deshalb habe ich in der Frage Einfachheit definiert.
Richard
-2

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?

Stephen Gross
quelle
Ja. Ein Anruf pro Leitung ist für mich einfacher und leichter zu lesen. Die Lesbarkeit ist jedoch subjektiv. (Auch dies ist nicht annähernd die Beantwortung der Frage.)
Richard
Hallo Stephen, kannst du näher erläutern, wie du denkst, dass dies die Frage beantwortet? Es ist nicht klar, worauf Sie hier hinweisen möchten.
@ MarkTrapp Kein Problem. In der ursprünglichen Frage wurde ein Ansatz mit einer Funktion pro Zeile vorgeschlagen. Das Beispiel, das ich gepostet habe, zeigt dieselben zwei Codeausschnitte, von denen einer als Single-Function-per-Line-Code und der andere als verkettete Methodenaufrufe implementiert ist. Ich denke, der verkettete Aufruf ist viel einfacher zu lesen: kurz, ohne unnötige temporäre Variablen und elegant.
Stephen Gross
Wenn Sie Getter verketten müssen, dann ist Ihr Code pooly gestaltet
Winter