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

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?

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

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.

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.

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

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.

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.

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.

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.

Viele Tricks, die den Code schneller machen sollten, aber dazu neigen, den Code weniger lesbar zu machen, sind nicht mehr erforderlich, da entweder Compiler sehr schlau (sogar schlauer als die meisten Entwickler) oder Computer lächerlich schnell wurden.

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.

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.

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

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.

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.

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.

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.