Sollten Sie die Lesbarkeit von Code mit der Effizienz von Code einbüßen? [geschlossen]

37

Sollten Sie die Lesbarkeit von Code mit der Effizienz von Code einbüßen?

zB 3 Codezeilen in 1 Zeile.

Ich habe in Code Craft von Pete Goodliffe gelesen, dass die Lesbarkeit der Schlüssel ist.

Ihre Gedanken?

TeaDrinkingGeek
quelle
13
Warum ist Code mit weniger Zeilen Ihrer Meinung nach effizienter? Dies ist bei modernen Sprachen selten der Fall, obwohl dies möglicherweise für 8-Bit-BASIC-Interpreter zutrifft.
David Thornley
69
Weder die Lesbarkeit noch die Leistung werden in Zeilen gemessen.
In sehr wenigen Fällen würde ich die Lesbarkeit für die Geschwindigkeit opfern, aber sehr selten. Embedded Code für Hochgeschwindigkeitsmaschinen ist ein Fall. Für die meisten Programme ist die Lesbarkeit weitaus wichtiger.
Jim C
Ich würde immer die Lesbarkeit bevorzugen, bis die Leistung zum Problem wird. Dann würde ich mir Sorgen machen.
Pete

Antworten:

62

"Weniger Linien" ist nicht immer dasselbe wie "effizienter". Ich nehme an, Sie meinen "Sollte ein Programm auf Kosten der Lesbarkeit verkürzt werden".

Programme müssen geschrieben werden, damit die Benutzer sie lesen können, und nur im Übrigen, damit Maschinen ausgeführt werden können.

-Abelson & Sussman, Struktur und Interpretation von Computerprogrammen

Generell halte ich es für wichtiger, dass ein Programm leicht verständlich ist, als dass es kurz ist. Ich sollte jedoch beachten, dass die Verkürzung eines Programms häufig auch die Lesbarkeit verbessert (es gibt die offensichtliche Grenze, bis zu der Ihr Code wie Zeilenrauschen aussieht, aber bis zu diesem Punkt scheint es klarer zu sein, etwas prägnanter auszudrücken).

Es gibt bestimmte Ausnahmen (wie Ihre persönlichen Shell-Skripte oder ein Mungo-Code für Daten), die niemand pflegen muss und die nur Sie jemals lesen müssen. In dieser Situation ist es wahrscheinlich in Ordnung, etwas Lesbarkeit für die Zweckmäßigkeit zu opfern, solange Sie es noch verstehen können.

Inaimathi
quelle
3
+1 Es gibt abnehmende Renditen, aber ich habe auch festgestellt, dass ein kurzes Programm im Allgemeinen leichter zu lesen ist als ein langes.
Michael K
23
Ich habe leider festgestellt, dass der einmalige, nicht sofort gelöschte Mungo-Code viel zu häufig in Langzeitcode umgewandelt wird. Erwarten Sie immer, dass Dinge herumhängen, wiederverwendet und erweitert werden, es sei denn, Sie löschen den Code.
Vatine
1
Ich stimme dem Vatin zu. Gehen Sie jemals zurück und versuchen Sie, etwas herauszufinden, von dem Sie einst dachten, es sei "vollkommen klar". Wann?
Wonko the Sane
+ 1 für SICP. Geniales Buch.
Jason Yeo
30

Manchmal ja.

Lesbarkeit ist eine gute Sache anzustreben. Der meiste Code, der für typische Branchenanwendungen geschrieben wurde, ist ausreichend performant und es ist wichtig, sich auf die Lesbarkeit zu konzentrieren. In leistungsintensiveren Bereichen (z. B. beim Programmieren von Videospielen oder bei umfangreichen Berechnungen) kann es wichtig sein, auf Lesbarkeit zu verzichten, um eine bestimmte Sprachfunktion zu verwenden, die fürchterlich unleserlich und dennoch unglaublich performant ist.

Ein Beispiel für Letzteres finden Sie im Artikel Fast Inverse Square Root auf Wikipedia.

Ich denke im Allgemeinen, dass es besser ist, zuerst etwas Lesbares zu machen und sich danach Gedanken über die Leistung zu machen, vorausgesetzt, es werden Vorsichtsmaßnahmen getroffen, die dem gesunden Menschenverstand dienen, wie z. Ich halte es für falsch, die Lesbarkeit nur der Kürze halber zu opfern.

Adam Lear
quelle
4
Ich denke, es könnte einen Unterschied zwischen "lesbarem Code" und "Kenntnis des Algorithmus" geben. Ich denke, jeder Code ist mehr oder weniger schwer zu lesen und zu verstehen, wenn Sie den Algorithmus nicht kennen. Zum Beispiel ist in dem erwähnten FISR-Fall der Klartext tatsächlich gut lesbar, aber der Algorithmus ist nicht dokumentiert. Wenn Sie den FISR-Algorithmus kennen, wie viel lesbarer könnten Sie den Code schreiben? Eine eng verwandte Frage könnte sein: Wann soll man einen ausgefallenen Algorithmus wählen?
Maglob
@Maglob Ich bezog mich speziell auf die Verwendung von 0x5f3759df. Ohne Rücksicht auf die Leistung könnten Sie den ISR-Algorithmus mithilfe der regulären Aufteilung implementieren, die für eine Person, die mit den internen Funktionen des Computers weniger vertraut ist, wahrscheinlich besser lesbar ist.
Adam Lear
3
Dies könnte vielleicht ausgedrückt werden als "Es ist manchmal richtig, einen naiven Algorithmus, der in 5 Kommentarzeilen und 20 Codezeilen ausgedrückt wird, durch einen ausgeklügelten Algorithmus zu ersetzen, der in 15 Kommentarzeilen und 5 Codezeilen ausgedrückt wird".
Peter Taylor
1
Denken Sie auch daran, dass eine schrecklich stumpfe Verschleierung eines Entwicklers in einer Domäne für einen Entwickler in einer anderen Domäne durchaus akzeptabel sein kann. Während die magische Konstante im ISR-Algorithmus die Grenzen ein wenig verschoben zu haben scheint, würde ich vermuten, dass diese Art von Hacking auf Bit-Ebene für Gleitkommanäherungen zu dieser Zeit in der Spieleentwicklung ziemlich verbreitet war. Ähnlich ist es bei der Arbeit in eingebetteten Systemen üblich, ein bisschen herumzudrehen, was für einen Anwendungsentwickler jedoch übermäßig stumpf erscheinen mag.
Cercerilla
eines der wunder des internets -> bei der implementierung eines komplexen algorithmus (beispiel: levenshtein distance mit der diagonalen optimierung ... ich arbeite gerade daran;)) kann man entweder auf einen artikel verweisen oder sogar den artikel in die dokumentation kopieren des Projekts und setzen Sie einen Verweis in den Code. Auf diese Weise folgen Personen, die die Algorithmen kennen, lediglich den Kommentaren, die bestimmte Tests / Optimierungen erläutern, während Anfänger zuerst den Algorithmus lesen und dann zur Implementierung zurückkehren müssen.
Matthieu M.
22

Das einzige Mal, dass ich die Lesbarkeit einschränken würde, wäre, wenn sich herausstellen würde, dass der Code ein Leistungsengpass ist, und ein Umschreiben dies beheben würde. In diesem Fall sollte die Absicht des Codes gut dokumentiert sein, damit ein Fehler leichter aufgespürt werden kann.

Das heißt natürlich nicht, dass das Umschreiben unlesbar sein muss.

ChrisF
quelle
22

Ich habe es schon einmal zitiert und ich zitiere es noch einmal:

Machen Sie es richtig,
machen Sie es klar,
machen Sie es kurz,
machen Sie es schnell.

In dieser Reihenfolge.

Wes Dyer

Benjol
quelle
2
+1 Ich habe schnell nach unten gescrollt, um sicherzustellen, dass dieses Zitat enthalten ist. Jetzt muss ich keine Antwort eingeben. :-)
RationalGeek
9

Sollten Sie die Lesbarkeit von Code mit der Effizienz von Code einbüßen?

In Sachen Code ist es immer schön, sich selbst zu dokumentieren. Aber manchmal kann das nicht passieren. Manchmal müssen Sie optimieren und manchmal ist dieser Code an sich nicht gut lesbar.

Dafür wurden Kommentare erfunden . Benutze sie. Auch die Montage hat Kommentare. Wenn Sie eine Menge Code geschrieben haben und kein Kommentar in Sicht ist, bin ich besorgt. Kommentare wirken sich nicht auf die Laufzeitleistung aus, aber ein paar Hinweise zu den Vorgängen helfen immer weiter.

Meines Erachtens gibt es absolut keine Entschuldigung, nicht ein paar grundlegende Kommentare abzugeben. Klar if ( x == 0 ) /* check if x is 0 */ist völlig nutzlos; Sie sollten dem Code kein unnötiges Rauschen hinzufügen, aber ungefähr so:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

Ist ganz hilfreich.

user10197
quelle
6

Sollten Sie die Lesbarkeit von Code mit der Effizienz von Code einbüßen?

Wenn Effizienz Ihr aktuelles Ziel ist (wie in der Optimierungsphase) und Sie wissen - Sie haben Metriken, nicht wahr? - Diese Codezeile (n) ist der aktuelle Engpass, dann ja.

Andernfalls ermöglicht es no: readability Ihnen (oder einem anderen), diesen Code später zu ändern, um ihn effizienter zu gestalten, da dies einfacher zu verstehen ist.

Klaim
quelle
4

Niemand gewinnt Code Golf

zB 3 Codezeilen in 1 Zeile

Eine besonders schreckliche Idee.

Kosten für Code Golf - sehr hoch.

Kosten für die Wartung nicht lesbarer Programme - astronomisch.

Wert dieser Art von minimiertem Code - Null. Es funktioniert immer noch, aber es funktioniert nicht "besser".

Mit Bedacht gewählte Effizienz

Kosten für die Auswahl des richtigen Algorithmus und der richtigen Datenstruktur - moderat.

Kosten für die Aufrechterhaltung des richtigen Algorithmus und der richtigen Datenstruktur - gering.

Wert des richtigen Algorithmus und der Datenstruktur - hoch. Der Ressourcenverbrauch ist gering.

Dumm ("Mikrooptimierung") Effizienz

Kosten für das Herumspielen der Mikrooptimierung - hoch.

Wartungskosten für unlesbaren, mikrooptimierten Code - sehr hoch.

Wert der Mikrooptimierung - variiert. Wenn es hier einen Wert ungleich Null gibt, überwiegen die Kosten immer noch.

S.Lott
quelle
2

Kommt darauf an, ob es sich um Effizienz handelt, wie schnell der Code ausgeführt wird oder wie schnell der Entwickler den Code schreiben kann. Wenn Sie die Lesbarkeit des Codes opfern, um den Code sehr schnell eingeben zu können, müssen Sie wahrscheinlich die Zeit für das Debuggen aufwenden.

Wenn es jedoch darum geht, die Lesbarkeit des Codes in Bezug auf die Ausführungsgeschwindigkeit zu beeinträchtigen, ist dies wahrscheinlich ein akzeptabler Kompromiss, solange der Code auf effiziente Weise ausgeführt werden muss. Etwas zu schreiben, das so schnell wie möglich läuft, nur weil man es kann, ist nicht annähernd so gut wie die schnelle Quadratwurzel, bei der Leistung der Schlüssel ist. Der Trick wird darin bestehen, den Code auszugleichen und sicherzustellen, dass, obwohl die Quelle möglicherweise schwer zu lesen ist, die Kommentare erklären, was dort vor sich geht.

rjzii
quelle
2

Ich akzeptiere das Argument "Lesbarkeit über Leistung" nicht. Lassen Sie mich eine andere Antwort geben.

Hintergrund: Weißt du, was mich krank macht? Wenn ich auf "Arbeitsplatz" doppelklicke und warten muss, bis er ausgefüllt ist. Wenn das länger als 5 Sekunden dauert, bin ich sehr frustriert. Das Dumme ist, und wir machen nicht nur Microsoft dafür verantwortlich, dass in einigen Fällen die Entscheidung, welches Symbol angezeigt werden soll, so lange dauert. Korrekt. Hier sitze ich also und möchte nur zu meinem Laufwerk C: gehen. Ich muss warten, bis der Treiber auf meine CD-ROM zugreift und das Symbol von dort liest (vorausgesetzt, es befindet sich eine CD im Laufwerk).

OKAY. Stellen Sie sich für einen Moment alle Ebenen vor, zwischen denen ich auf "Arbeitsplatz" doppelgeklickt habe und die tatsächlich über Treiber mit der CD-ROM kommunizieren. Nun stell dir vor, jede Schicht war ... schneller ...

Sie sehen, dahinter stecken Tausende glücklicher Programmierer, weil ihr Code "besser lesbar" ist. Das ist großartig. Ich freue mich für dich. Aber aus der Sicht des Benutzers ist es einfach nur schlecht (Fachbegriff). Und so schläfst du nachts und sagst dir, dass du das Richtige getan hast, indem du dafür sorgst, dass der Code besser lesbar und dennoch langsamer ist. Sogar etwas langsamer als es sein kann. Und so machen das Tausende von Entwicklern, und am Ende warten wir wegen Ihnen auf unsere PCs. Meiner Meinung nach bist du es nicht wert. Ich sage nicht, dass Ihre allerersten Zeilen die besten sein müssen.

Hier ist mein Ansatz: Lass es zuerst funktionieren, dann mach es schneller. Versuchen Sie immer, effizienten Code zu schreiben, und ergänzen Sie ihn mit Kommentaren, wenn Sie auf Lesbarkeit verzichten müssen. Ich werde die Effizienz nicht opfern, damit ein mittelmäßiger Programmierer sie aufrechterhalten kann. Ich werde jedoch meinen Code erklären, aber wenn das nicht ausreicht, tut es mir leid, Sie sind einfach inkompetent, um hier zu arbeiten. Denn hier schreiben wir Code, der schnell und lesbar ist, und obwohl ein Gleichgewicht besteht, kann lesbarer Code erklärt werden, während Ineffizienz einfach inakzeptabel ist.

Maltrap
quelle
"OK. Stellen Sie sich also für eine Sekunde vor, dass alle Ebenen zwischen mir auf" Arbeitsplatz "doppelklicken und tatsächlich über Treiber mit der CD-ROM kommunizieren. Stellen Sie sich nun vor, jede Ebene wäre ... schneller ...", sofort für mich mit 2 DVDs Drives
Rangoric
Ein Wort: Upgrade
jmort253
2
Leute, arbeitet mit mir hier, es ist eine Illustration ...
Maltrap
@Rangoric Das nenne ich Fortschritte in der Technologie als Krücke und nicht als Geschenk. Für die Branche ist es gut, wenn Sie Benutzer dazu verleiten können, ihre Brieftaschen häufiger zu öffnen.
Jonathan Neufeld
Ich denke, die energetischen Auswirkungen von aufgeblähtem Code erfordern genauere und strengere Maßnahmen. Umweltverantwortung fehlt hier. In Anbetracht der Tatsache, dass wir jetzt einen Anstieg der globalen Temperaturen um 4 Grad erwarten, warum tritt die Komplexität der Berechnungen in den Hintergrund?
Jonathan Neufeld
2

Diese Frage ist mir oft in den Sinn gekommen, wenn Interviews im Büro besprochen werden. Vor vielen Jahren wurde mir als Absolvent die Frage gestellt: "Glaubst du, Code ist selbstdokumentierend?". Jetzt sollte ich diese Frage als Programmierer beantworten und für den Interviewer war es eine Schwarz-Weiß-Frage, also gab es keinen Mittelweg. Der Prozess sollte den Einzelnen überleben, da die Menschen mehr als munter kommen und gehen werden und Sie neue Starts so schnell wie möglich vorbereiten möchten. Je einfacher der Code zu lesen ist, desto schneller ist es zu verstehen, was vor sich geht.

Ich habe vor einiger Zeit ein ziemlich gutes Buch mit dem Titel "Domain Driven Development: Domain-driven Design: Komplexität im Herzen von Software angehen" gelesen. Zugegeben, es ist zu Beginn ein bisschen trocken zu lesen, aber das Material ist gut präsentiert. Dies zeigt einen guten Ansatz, der zu Systemen führt, die sich selbst gut dokumentieren. Die Sprache ist das Medium, um Ihre Lösung zu kommunizieren. Je klarer die Lösung ausgedrückt wird, desto einfacher ist es, sie anzupassen, wenn die Leistung zu einem zentralen Faktor wird. Das ist meine Überzeugung und es scheint gut für mich funktioniert zu haben.

Desolate Planet
quelle
1

In den seltensten Fällen lohnt sich der ROI, wenn der Code auf Kosten der Lesbarkeit schneller ausgeführt wird. Moderne Computer laufen so schnell, dass ich bezweifle, dass es ein Szenario gibt, in dem Sie dies wünschen würden. Wenn auf einem Computer der Code ausgeführt wird, muss dieser Code verwaltet werden.

Zu diesem Zweck finde ich die Lesbarkeit sehr wichtig. Natürlich bedeutet es nicht unbedingt, dass Code, wie bereits mehrfach erwähnt, langsamer ist, nur weil er lesbar ist.

Ein gutes Beispiel ist ein Variablenname: $a

Was ist $a?? Das ist aus dem Zusammenhang geraten, also können Sie das nicht beantworten, aber sind Sie jemals in tatsächlichem Code darauf gestoßen? Nehmen wir an, jemand hat geschrieben $file_handle- was ist das? Es ist klar, auch außerhalb des Kontexts. Die Länge des Variablennamens spielt für den Computer eine unbedeutende Rolle.

Ich denke, dass hier gesunder Menschenverstand herrscht.

Einige Anwendungen erfordern möglicherweise eine Bit-Shift-Abkürzung, die nicht alle verstehen, aber ich denke, dass irgendwann die Rendite sinkt und es selten ist, ein Szenario zu finden *.

* Dies hängt von der Industrie und anderen derartigen Dingen ab. Ich betrachte dies aus der Perspektive eines Business Software-Entwicklers (Business Information Systems).


Um dies aus einer anderen Perspektive zu betrachten (aber nicht um herumzuspazieren), arbeite ich in einer Firma, die SAAS betreibt. Wenn eine Site ausfällt, müssen wir sie wirklich, wirklich schnell reparieren - normalerweise repariert jemand anderes den Code eines anderen Entwicklers.

Ich würde viel lieber jemand etwas tun , sehr uneffizient , aber lesbar als Phantasie zu machen und „schnell“. Unsere Webserver sind auf dem neuesten Stand und eine Anfrage muss nicht in einer Millionstel Sekunde zugestellt werden. Wir haben keine Probleme beim Laden.

In der Praxis glaube ich, dass Sie sich selbst oder andere eher verletzen werden ... (Ich hätte lieber mein Wochenende zurück.)

Frank V
quelle
1

In den meisten Fällen lautet die Antwort "Vertrauen Sie darauf, dass Ihr Compiler seine Aufgabe erfüllt" und schreiben Sie lesbaren Code. Dies impliziert, dass der Code logisch strukturiert (dh ohne Spaghetti) und selbstdokumentierend ist (dh ausreichend eindeutige Namen von Variablen, Funktionen usw.). Ergänzungscode, der nicht selbst dokumentiert ist, mit aussagekräftigen Kommentaren. Kommentieren Sie nicht, um zu kommentieren, dh,

x++; // Add one to x

Kommentieren Sie stattdessen für Sie, den Leser, in 6 Monaten oder 12 Monaten oder in einer anderen ausreichend langen Zeit. Übernehmen Sie einen Kodierungsstandard und befolgen Sie ihn.

Throwback1986
quelle
+1 für "Vertraue deinem Compiler, dass er seine Arbeit macht". Das ist mein neuer Skype-Kommentar.
jmort253
0

Sauberer Code ist schneller Code. Klarer, einfach zu wartender Code ist in der Regel schneller, da er ein Indikator dafür ist, dass der Programmierer die anstehende Aufgabe verstanden und den Code bis zu seinem eigentlichen Zweck überarbeitet hat.

Außerdem optimieren moderne Compiler Anweisungen sehr effektiv. Wie viele Codezeilen Sie eingeben, um etwas zu tun, und was der Compiler in Bezug auf Anweisungen erstellt, hängt nicht unbedingt zusammen. Informieren Sie sich über Compiler, um zu verstehen, warum dies der Fall ist.

Wenn ich an etwas Performance-basiertem wie Grafik arbeite, werde ich gelegentlich auf Lesbarkeit / Wartbarkeit verzichten, wenn ich Dinge wie Bildverarbeitung mache, wenn ich an den tiefsten verschachtelten Algorithmen arbeite, bei denen kleine Optimierungen einen großen Effekt haben können. Und selbst dann mache ich das erst nach der Profilerstellung, um sicherzustellen, dass die Änderungen tatsächlich die Dinge beschleunigen. Ich kann Ihnen nicht sagen, wie oft ich handcodierte "Optimierungen" ausprobiert habe, nur um festzustellen, dass dies die App aufgrund der Art und Weise, wie der Compiler den handschriftlichen Code optimiert hat, tatsächlich verlangsamt hat.

GroßmeisterB
quelle
-1

Lesbarkeit ist eine Entschuldigung für inkompetente und faule Programmierer (das gleiche gilt für "Einfachheit", wenn es als Argument zur Verteidigung eines beschissenen Algorithmus / Designs verwendet wird)!

Für jedes Problem sollten Sie die optimale Lösung anstreben! Die Tatsache, dass Computer heutzutage schnell sind, ist keine Entschuldigung für die Verschwendung von CPU-Zyklen. Die einzige Einschränkung sollte "Lieferfrist" sein. Beachten Sie, dass "optimale Lösung" hier die ist, die SIE finden können (wir können nicht alle die beste Lösung finden oder die Fähigkeit / das Wissen haben, diese umzusetzen).

Wie jemand anderes erwähnte, wenn es "schwer zu verstehende" Aspekte einer Lösung gibt, sind dies Kommentare. Der Befehl "richtig, lesbar, schnell" (oder so ähnlich), den jemand anders erwähnt hat, ist reine Zeitverschwendung.

Es fällt mir wirklich schwer zu glauben, dass es Programmierer gibt, die, wenn sie mit einem Problem konfrontiert werden, denken, dass "... dies so gemacht werden muss, aber ich werde es so machen, dass es weniger effizient, aber besser lesbar ist / wartbar und andere solche Mist ... ". Der Trugschluss dabei ist, dass der nächste Entwickler (der die Ineffizienzen sieht) höchstwahrscheinlich den Code ändern wird und der nächste wird das Gleiche tun und so weiter ... Das Endergebnis ist, dass der Code nach einigen Versionen so wird, wie er ursprünglich ist Entwickler sollte an erster Stelle geschrieben haben. Die einzige Entschuldigung für den ursprünglichen Entwickler ist a. er / sie hat nicht daran gedacht (fair genug) und (wie bereits erwähnt) b. Zeit- und Ressourcenbeschränkungen.

jemand
quelle
-2

Wenn eine geringere Lesbarkeit die Leistung / Optimierung des Codes unterstützt (wie in swfobject und anderen js-Bibliotheken), ist dies ein Grund, weiterhin gut formatierten und klar lesbaren Code zu schreiben und ihn im Rahmen des Kompilierungs- / Veröffentlichungsprozesses in unlesbaren / optimierten Code zu konvertieren.

www0z0k
quelle