it-swarm-eu.dev

Sollten Sie die Lesbarkeit des Codes mit der Effizienz des Codes opfern?

Sollten Sie die Lesbarkeit des Codes mit der Effizienz des Codes opfern?

z.B. 3 Codezeilen in 1 Zeile.

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

Ihre Gedanken?

40
TeaDrinkingGeek

"Weniger Zeilen" ist nicht immer dasselbe wie "effizienter". Ich nehme an, Sie meinen "Sollte ein Programm auf Kosten der Lesbarkeit kürzer gemacht werden".

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

- Abelson & Sussman, Struktur und Interpretation von Computerprogrammen

Im Allgemeinen denke ich, dass es wichtiger ist, dass ein Programm leicht zu verstehen ist, als dass es kurz ist. Ich sollte jedoch beachten, dass ein kürzeres Programm es oft auch lesbarer macht (es gibt den offensichtlichen Schwellenwert, den Sie erreichen, wenn 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 einen der Daten-Munging-Codes), die niemand jemals pflegen muss und die nur Sie jemals lesen müssen. In dieser Situation ist es wahrscheinlich in Ordnung, die Lesbarkeit aus Gründen der Zweckmäßigkeit zu opfern, solange Sie dies noch verstehen können.

62
Inaimathi

Manchmal ja.

Lesbarkeit ist eine gute Sache zu streben. Der meiste Code, der für typische Branchenanwendungen geschrieben wurde, ist leistungsfähig genug, und es ist wichtig, sich auf die Lesbarkeit zu konzentrieren. In leistungsintensiveren Bereichen (wie Videospielprogrammierung oder umfangreiches Rechnen) kann es wichtig sein, auf die Lesbarkeit zu verzichten, um eine bestimmte Sprachfunktion zu verwenden, die schrecklich unlesbar und dennoch unglaublich leistungsfähig 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 um die Leistung zu sorgen, vorausgesetzt, es werden Vorsichtsmaßnahmen getroffen, wie beispielsweise, dass kein O (n ^ 2) -Algorithmus anstelle von O(n)) gewählt wird Die Lesbarkeit allein der Kürze halber ist meines Erachtens falsch.

30
Adam Lear

Ich zitierte es vorher und ich zitiere es noch einmal:

Mach es richtig,
mach es klar,
machen Sie es kurz,
Mach schnell.

In dieser Reihenfolge.

Wes Dyer

23
Benjol

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

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

22
ChrisF

Sollten Sie die Lesbarkeit von Code mit der Effizienz von Code opfern?

In Bezug auf 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 sehr lesbar.

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

Meiner Meinung nach gibt es absolut keine Entschuldigung, nicht ein paar grundlegende Kommentare zu haben. Offensichtlich ist if ( x == 0 ) /* check if x is 0 */ völlig nutzlos; Sie sollten dem Code kein unnötiges Rauschen hinzufügen, aber so etwas:

; 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 sehr hilfreich.

9
user10197

Sollten Sie die Lesbarkeit von Code mit der Effizienz von Code opfern?

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

Andernfalls können Sie (oder eine andere) diesen Code später ändern, um ihn effizienter zu gestalten, da er leichter zu verstehen ist.

6
Klaim

Niemand gewinnt Code Golf

z.B. 3 Codezeilen in 1 Zeile

Eine besonders schreckliche Idee.

Kosten für Code Golf - sehr hoch.

Kosten für die Wartung unlesbarer Programme - astronomisch.

Wert dieser Art von minimiertem Code - Null. Es funktioniert immer noch, aber 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 richtigen Datenstruktur - hoch. Der Ressourcenverbrauch ist gering.

Dumme ("Mikrooptimierung") Effizienz

Kosten für das Herumspielen der Mikrooptimierung - hoch.

Kosten für die Wartung von unlesbarem, mikrooptimiertem Code - sehr hoch.

Wert der Mikrooptimierung - variiert. Wenn hier ein Wert ungleich Null vorliegt, überwiegen die Kosten immer noch.

4
S.Lott

Ich akzeptiere das Argument "Lesbarkeit über Leistung" nicht. Lassen Sie mich Ihnen eine Antwort mit einem anderen Dreh geben.

Hintergrund: Weißt du, was mich krank macht? Wenn ich auf Arbeitsplatz doppelklicke, muss ich tatsächlich warten, bis er ausgefüllt ist. Wenn das länger als 5 Sekunden dauert, bin ich wirklich frustriert. Das Dumme ist, und nicht nur Microsoft dafür verantwortlich zu machen, dass in einigen Fällen der Grund dafür, dass es so lange dauert, ist, dass eine Entscheidung getroffen werden muss, welches Symbol angezeigt werden soll! Das stimmt. Hier sitze ich also und bin nur daran interessiert, zu meinem Laufwerk C: zu wechseln. 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).

OK. Stellen Sie sich also für eine Sekunde alle Ebenen zwischen mir vor, die auf Arbeitsplatz doppelklicken und tatsächlich über Treiber mit der CD-ROM kommunizieren. Stellen Sie sich nun vor, jede Schicht wäre ... 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 zum Kotzen (Fachbegriff). Und so schlafen Sie nachts laut und sagen sich, dass Sie das Richtige getan haben, indem Sie sicherstellen, dass der Code besser lesbar und dennoch langsamer ist. Noch etwas langsamer als es sein kann. Und so tun dies Tausende von Entwicklern, und wir warten wegen Ihnen auf unsere PCs. Meiner Meinung nach bist du nicht würdig. Ich sage nicht, dass Ihre ersten Zeilen die besten sein müssen.

Hier ist mein Ansatz: Lassen Sie es zuerst funktionieren, dann beschleunigen Sie es.Immer zielen darauf ab, effizienten Code zu schreiben, und wenn Sie die Lesbarkeit opfern müssen, ergänzen Sie ihn mit Kommentaren. Ich werde die Effizienz nicht opfern, damit ein mittelmäßiger Programmierer sie beibehalten kann. Ich werde jedoch meinen Code erklären, aber wenn das nicht genug ist, tut es mir leid, Sie sind einfach inkompetent, hier zu arbeiten. Denn hier schreiben wir Code, der schnell und lesbar ist, und obwohl es ein Gleichgewicht gibt, kann lesbarer Code erklärt werden, während Ineffizienz einfach inakzeptabel ist.

2
Maltrap

Hängt davon ab, 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 Code sehr schnell eingeben zu können, werden Sie wahrscheinlich die Zeit später für das Debuggen bezahlen.

Wenn es jedoch darum geht, die Lesbarkeit des Codes in Bezug auf die Ausführungsgeschwindigkeit des Codes 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 Sie es können, ist bei weitem kein so guter Grund wie weil es so etwas wie die schnelle inverse Quadratwurzel ist, bei der Leistung der Schlüssel ist. Der Trick wird darin bestehen, den Code auszugleichen und sicherzustellen, dass die Kommentare, die beschreiben, was sie tun, erklären, was vor sich geht, obwohl die Quelle möglicherweise schwer zu lesen ist.

2
rjzii

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 das Individuelle überleben, da die Menschen mehr als lebhaft kommen und gehen werden und Sie so schnell wie möglich neue Starts 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 Buch gelesen, das ziemlich gut war und sich Domain Driven Development nennt: Domain-gesteuertes Design: Komplexität im Herzen von Software angehen Zugegeben, es ist am Anfang etwas trocken, 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 für die Kommunikation Ihrer Lösung. Je klarer die Lösung ausgedrückt wird, desto einfacher ist die Anpassung, wenn die Leistung zu einem wichtigen Faktor wird. Das ist mein Glaube und es scheint gut für mich funktioniert zu haben.

2
Desolate Planet

Viele Tricks, die Code schneller machen sollten, aber dazu neigen, den Code weniger lesbar zu machen, sind nicht mehr notwendig, weil entweder Compiler sehr klug (sogar klüger als die meisten Entwickler) oder Maschinen schnell lächerlich wurden .

2

Selten würde sich der ROI für eine schnellere Ausführung des Codes auf Kosten der Lesbarkeit lohnen. Moderne Computer laufen so schnell, dass ich bezweifle, dass es ein Szenario geben würde, in dem Sie dies wünschen würden. Wenn auf einem Computer der Code ausgeführt wird, muss dieser Code beibehalten werden.

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

Ein gutes Beispiel ist ein Variablenname: $a

Was ist $a? Dies ist nicht kontextbezogen, daher können Sie das nicht beantworten, aber sind Sie jemals im tatsächlichen Code darauf gestoßen? Nehmen wir nun an, jemand hat $file_handle Geschrieben - was ist das nun? Es ist auch außerhalb des Kontexts klar. Die Länge des Variablennamens macht für den Computer einen unbedeutenden Unterschied.

Ich denke, dass hier gesunder Menschenverstand ist.

Einige Anwendungen rechtfertigen möglicherweise eine Abkürzung für die Bitverschiebung, die nicht alle verstehen werden, aber ich denke, dass irgendwann die Renditen sinken und es selten vorkommt, ein Szenario zu finden *.

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


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

Ich würde viel lieber jemand etwas sehr ineffizientes, aber lesbares tun, als es schick und "schnell" zu machen. Unsere Webserver sind auf dem neuesten Stand und eine Anfrage muss nicht in Millionstelsekunden zugestellt werden. Wir haben keine Ladeprobleme.

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

1
Frank V

In den meisten Fällen lautet die Antwort "Vertrauen Sie Ihrem Compiler, dass er seine Arbeit erledigt" und schreiben Sie lesbaren Code. Dies impliziert, dass der Code logisch strukturiert (d. H. Keine Spaghetti) und selbstdokumentierend (d. H. Ausreichend klare Namen von Variablen, Funktionen usw.) ist. Ergänzungscode, der nicht selbst dokumentiert ist, mit aussagekräftigen Kommentaren. Kommentieren Sie nicht, um zu kommentieren, d. H.

x++; // Add one to x

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

1
Throwback1986

Sauberer Code ist schneller Code. Klar geschriebener, leicht zu pflegender Code ist in der Regel schneller, da dies ein Indikator dafür ist, dass der Programmierer die anstehende Aufgabe verstanden und den Code bis zu seinem Hauptzweck ü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 Leistungsbasiertem wie Grafik arbeite, werde ich gelegentlich die Lesbarkeit/Wartbarkeit opfern, 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" versucht habe, nur um festzustellen, dass dies die App tatsächlich verlangsamt hat, da der Compiler den handgeschriebenen Code optimiert hat.

0
GrandmasterB