Sollte der Code kurz/prägnant sein?

Question

Beim Schreiben eines mathematischen Beweises besteht ein Ziel darin, den Beweis weiter zu komprimieren. Der Beweis wird eleganter, aber nicht unbedingt lesbarer. Die Komprimierung führt zu besserem Verständnis, da Sie unnötige Zeichen und Ausführlichkeit aussortieren.

Ich höre oft Entwickler sagen, Sie sollten Ihren Code Footprint so klein wie möglich machen. Dies kann sehr schnell zu unlesbarem Code führen. In der Mathematik ist das kein Problem, da die Übung rein akademisch ist. Im Produktionscode, wo Zeit Geld ist, scheint es jedoch wenig sinnvoll zu sein, wenn Leute versuchen herauszufinden, was ein sehr prägnanter Code macht. Für etwas ausführlicheren Code erhalten Sie Lesbarkeit und Einsparungen.

An welchem ​​Punkt hören Sie auf, den Softwarecode zu komprimieren?

Answer 1

Ich versuche eine Ausführlichkeitsstufe zu erreichen, wo meine Programmanweisungen wie ein Satz lesen, den jeder Programmierer verstehen könnte. Das bedeutet, dass ich meinen Code stark reformatiere, so dass es sich um kurze Teile einer Geschichte handelt. Jede Aktion wird daher in einer separaten Methode beschrieben (eine weitere Ebene könnte einer anderen Klasse angehören).

Bedeutung Ich würde meine Anzahl von Zeichen nicht reduzieren, nur weil es in weniger ausgedrückt werden kann. Dafür gibt es Code-Golf-Wettbewerbe.

Answer 2

Sie können den Code verkleinern, indem Sie die Redundanz sehen und eliminieren oder indem Sie clever sind. Tun Sie das erstere und nicht das letztere.

Answer 3

Es gibt keine genaue Linie, die gezeichnet werden kann, um zwischen glib-Code und blumigem Code zu unterscheiden. Verwenden Sie Ihr bestes Urteil. Lassen Sie andere Ihren Code sehen und sehen Sie, wie leicht er sie verstehen kann. Aber denken Sie daran, dass Korrektheit das Ziel Nummer 1 ist.

Answer 4

Es muss ein Gleichgewicht zwischen kurzen süßen Quellcode und Leistung bestehen. Wenn es nette Quelle ist und am schnellsten läuft, dann gut, aber wegen der netten Quelle läuft es wie ein Hund, dann schlecht.

Answer 5

Der Bedarf an kleinen Code-Footprints ist eine Reminiszenz an die Zeit der Assemblersprache und der ersten etwas höheren Programmiersprache ... da sind kleine Code-Fußabdrücke, wo ein echter und dringender Bedarf besteht. In diesen Tagen ist es nicht so sehr eine Notwendigkeit.

Das heißt, ich hasse ausführlichen Code. Wo ich arbeite, schreiben wir Code, der so viel wie möglich wie eine natürliche Sprache liest, ohne zusätzliche Grammatik oder Wörter. Und wir kürzen nichts ab, außer es ist eine sehr gebräuchliche Abkürzung.

Company.get_by_name("ABC") 
makeHeaderTable() 

ist etwa so knapp wie wir gehen.

Answer 6

Im Allgemeinen mache ich die Dinge offensichtlich und einfach zu arbeiten. Wenn mir die Kürze/Kürze zu diesem Zweck dient, umso besser. Oft sind kurze Antworten am deutlichsten, daher ist Kürze ein Nebenprodukt von offensichtlich.

Answer 7

Es gibt ein paar Punkte meiner Meinung nach die bestimmen, wann die Optimierung zu stoppen:

• Worth, Zeit zu investieren Durchführung Optimierungen. Wenn Sie Leute Wochen verbringen und nichts finden, gibt es eine bessere Nutzung dieser Ressourcen?

• Was ist die Reihenfolge der Optimierungspriorität. Es gibt ein paar verschiedene Faktoren, die beim Code eine Rolle spielen könnten: Ausführungszeit, Ausführungsraum (sowohl ausgeführt als auch nur der kompilierte Code), Skalierbarkeit, Stabilität, wie viele Funktionen implementiert sind usw.Ein Teil davon ist der Ausgleich von Zeit und Raum, aber es kann auch sein, wo ein Code geht, z. Kann Middleware Ad-hoc-SQL-Befehle ausführen oder sollten diese über gespeicherte Prozeduren weitergeleitet werden, um die Leistung zu verbessern?

ich glaube, der Hauptpunkt ist, dass es eine Mäßigung ist, dass die meisten gute Lösungen haben.

Answer 8

Meine Regel ist sagen Sie, was Sie meinen. Ein gängiger Weg, auf dem Menschen Fehler machen, ist "Stärkeabbau". Im Grunde ersetzen sie das Konzept, das sie denken, mit etwas, das Schritte zu überspringen scheint. Leider hinterlassen sie Konzepte aus ihrem Code, was das Lesen erschwert.

Zum Beispiel Ändern

for (int i = 0; i < n; i++) 
    foo[i] = ... 

zu

int * p = foo, q = foo+n; 
while (*p++ = ... < q); 

ist ein Beispiel für eine Verringerung der Festigkeit, die Schritte zu retten scheint, aber es lässt sich die Tatsache, dass foo ein Array ist, so dass es ist schwerer zu lesen.

Eine andere häufige verwendet Bool anstelle einer Enum.

enum { 
    MouseDown, 
    MouseUp 
}; 

Mit diesem seinen

bool IsMouseDown; 

die Tatsache läßt darauf hin, dass dies eine Zustandsmaschine ist, so dass der Code schwieriger zu pflegen.

Also meine Faustregel wäre, in Ihrer Implementierung, graben Sie nicht auf eine niedrigere Ebene als die Konzepte, die Sie ausdrücken möchten.

Answer 9

Sie können Ihren Code so kurz oder kompakt wie Sie möchten, solange Sie es kommentieren. Auf diese Weise kann Ihr Code optimiert werden, aber dennoch Sinn machen. Ich bleibe irgendwo in der Mitte mit beschreibenden Variablen und Methoden und Sparce-Kommentaren, wenn es noch unklar ist.

Answer 10

Eine Möglichkeit, ein Gleichgewicht zu finden, ist die Suche nach Lesbarkeit und nicht Prägnanz. Programmierer scannen ständig Code visuell, um zu sehen, was getan wird, und so sollte der Code so gut wie möglich fließen.

Wenn der Programmierer Code scannt und einen Abschnitt erreicht, der schwer zu verstehen ist, oder etwas Mühe braucht, um visuell zu analysieren und zu verstehen, ist das eine schlechte Sache. Es ist wichtig, allgemein bekannte Konstrukte zu verwenden, sich von den vagen und selten verwendeten zu entfernen, es sei denn, dies ist notwendig.

Menschen sind keine Compiler. Compiler können das Zeug essen und weitermachen. Unklarer Code wird von Menschen nicht so schnell wie klar verstandenen Code gedanklich verbraucht.

Manchmal ist es sehr schwer, lesbaren Code in einem komplizierten Algorithmus zu erzeugen, aber in den meisten Fällen sollten wir nach menschlicher Lesbarkeit suchen, und nicht nach Klugheit. Ich glaube nicht, dass die Länge des Codes auch ein Maß für die Klarheit ist, denn manchmal ist eine ausführlichere Methode lesbarer als eine präzise Methode, und manchmal ist eine präzise Methode lesbarer als eine lange.

Auch sollten Kommentare nur ergänzen, und sollten nicht Ihren Code beschreiben, sollte sich Ihr Code selbst beschreiben. Wenn Sie eine Zeile kommentieren müssen, weil es nicht offensichtlich ist, was getan wird, ist das schlecht.Für die meisten erfahrenen Programmierer dauert es länger, eine englische Erklärung zu lesen, als den Code selbst zu lesen. Ich denke das Buch Code Complete hämmert dieses eine Zuhause.

Answer 11

Code sollte kurz, Beton und konzentriert sein. Sie können Ihre Ideen immer mit vielen Worten im Kommentare erklären.

Answer 12

Bemühen Sie sich, um zu refaktorieren, bis der Code selbst gut liest. Sie werden dabei Ihre eigenen Fehler entdecken, der Code wird leichter für den "nächsten Typ" zu finden sein, und Sie werden nicht dadurch belastet, dass Sie die Kommentare beibehalten (und später vergessen, sie zu ändern), worüber Sie bereits geäußert haben Code.

Wenn das fehlschlägt ... sicher, lassen Sie mich einen Kommentar.

Und sagen Sie mir nicht "was" in dem Kommentar (das ist, wofür der Code ist), sag mir "warum".

Answer 13

Die Codeoptimierungen haben wenig mit dem Codierungsstil zu tun. Die Tatsache, dass die Datei weniger als zu Beginn x-Leerzeichen oder neue Zeilen enthält, macht es zumindest in der Ausführungsphase nicht besser oder schneller - Sie formatieren den Code mit weißen Zeichen, die vom Compiler ignoriert werden. Es macht sogar den Code schlechter, weil es für die anderen Programmierer und für sich selbst unlesbar wird.

Es ist viel wichtiger, dass der Code in seiner logischen Struktur kurz und sauber ist, wie etwa Testbedingungen, Kontrollfluss, Annahmen, Fehlerbehandlung oder die gesamte Programmierschnittstelle. Natürlich würde ich hier auch schlaue und nützliche Kommentare + die Dokumentation einbeziehen.

Answer 14

Es besteht nicht unbedingt eine Korrelation zwischen prägnantem Code und Leistung. Das ist ein Mythos. In ausgereiften Sprachen wie C/C++ können die Compiler den Code sehr effektiv optimieren. In solchen Sprachen besteht die Notwendigkeit, anzunehmen, dass der prägnantere Code der leistungsstärkere Code ist. Neueren, weniger leistungsoptimierten Sprachen wie Ruby fehlen die Compiler-Optimierungsfunktionen von C/C++ - Compilern, aber es gibt immer noch wenig Grund zu der Annahme, dass prägnanter Code besser abschneidet. Die Realität ist, dass wir nie wissen, wie gut Code in der Produktion funktioniert, bis er in Produktion geht und profiliert wird. Einfache, harmlose Funktionen können zu großen Leistungsengpässen führen, wenn sie von genügend Stellen innerhalb des Codes aufgerufen werden. In hochgradig parallelen Systemen werden die größten Engpässe im Allgemeinen durch schlechte Gleichzeitigkeitsalgorithmen oder übermäßiges Sperren verursacht. Diese Probleme werden selten gelöst, indem man "prägnanten" Code schreibt.

Die Quintessenz ist folgende: Code, der schlecht funktioniert, kann immer wieder umgestaltet werden, sobald das Profiling feststellt, dass es der Engpass ist. Code kann nur dann effektiv umstrukturiert werden, wenn er einfach zu verstehen ist. Code, der "prägnant" oder "clever" geschrieben ist, ist oft schwieriger zu refaktorieren und zu pflegen.

Schreiben Sie Ihren Code für menschliche Lesbarkeit, und refaktorieren Sie die Leistung, wenn nötig.

Meine zwei Cent ...

Answer 15

Hier ist ein guter Artikel von Steve McConnell - Best Practices http://www.stevemcconnell.com/ieeesoftware/bp06.htm

Ich denke, kurz/prägnant sind zwei Ergebnisse aus gut geschriebenen Code. Es gibt viele Aspekte, um Code gut zu machen und viele Ergebnisse aus gut geschriebenem Code, die beiden sind unterschiedlich. Du planst nicht einen kleinen Fußabdruck, du planst eine Funktion, die prägnant ist und eine Sache sehr gut macht - das SOLLTE zu einem kleinen Fußabdruck führen (aber vielleicht nicht).Hier ist eine kurze Liste von dem, was ich würde den Schwerpunkt auf die beim Schreiben von Code:

• einzelne fokussierte Funktionen - eine Funktion sollte nur eine Sache tun, eine einfache Lieferung, multifunktionsfähige Funktionen sind fehlerhaft und nicht leicht wiederverwendbar
• lose gekoppelten - nicht von innerhalb einer Funktion auf globale Daten zugreifen und nicht stark von anderen Funktionen abhängen
• präzise Benennung - sinnvolle präzise Variablennamen verwenden, kryptische Namen sind nur das
• halten Sie den Code einfach und nicht komplex - Überspringe nicht sprachspezifische technische Wow's, gut um andere zu beeindrucken, schwer zu verstehen und mai Ntain - wenn Sie etwas tun hinzufügen ‚besondere‘ kommentieren so zumindest die Leute es vor zu schätzen wissen Sie Fluchen aus
• gleichmäßig Kommentar - zu viele Kommentare ignoriert und veraltet zu wenige haben keine Bedeutung
• Formatierung - stolz in wie der Code aussieht, richtig eingerückt Code hilft
• arbeiten mit dem Verstand eines Code-Wartungsperson - denken Sie, wie es wäre, den Code, den Sie schreiben
• haben Angst haben oder zu faul zu refactor - nichts ist perfekt das erste Mal, bereinigen Sie Ihre eigene Unordnung

Answer 16

Als im Gegensatz zu lang/weitschweifig? Sicher!

Aber es kommt zu dem Punkt, wo es so kurz und so knapp ist, dass es schwer zu verstehen ist, dann bist du zu weit gegangen.

Answer 17

Ja. Immer.

Answer 18

Soweit Objektnamen gehen, hat das Denken mit der Einführung neuer Programmiersprachen eine Evolution durchlaufen.

Wenn Sie die Sprachen "geschweifte Klammer" nehmen, beginnend mit C, wurde die Kürze als die Seele des Witzes betrachtet. Sie hätten also beispielsweise eine Variable, um einen Kreditwert namens "lv" zu halten. Die Idee war, dass Sie eine Menge Code eingaben, also halten Sie die Tastenanschläge auf ein Minimum.

Dann kam die Microsoft-sanktionierte "Ungarische Notation", wo die ersten Buchstaben eines Variablennamens den zugrunde liegenden Typ anzeigen sollten. Man könnte "fLV" oder etwas ähnliches verwenden, um anzuzeigen, dass der Kreditwert durch eine Float-Variable repräsentiert wurde.

Mit Java, und dann C#, ist das Paradigma einer der Klarheit geworden. Ein guter Name für eine Kreditwertvariable wäre "loanValue". Ich glaube, ein Teil des Grundes dafür ist die Befehlsvervollständigung in den meisten modernen Editoren. Da es nicht mehr erforderlich ist, einen vollständigen Namen einzugeben, können Sie genauso viele Zeichen verwenden, die für die Beschreibung erforderlich sind.

Dies ist ein guter Trend. Code muss verständlich sein. Kommentare werden oft als Nachtrag hinzugefügt, wenn überhaupt. Sie werden auch nicht aktualisiert, wenn der Code aktualisiert wird, sodass sie veraltet sind. Beschreibend, gut gewählt, Variablennamen sind der erste, beste und einfachste Weg, andere wissen zu lassen, worüber Sie codierten.

hatte ich ein Informatik-Professor, der sagte: „Als Ingenieure sind wir ständig Arten von Dingen zu schaffen, die es noch nie gegeben. Die Namen, die wir ihnen geben haften, also sollten wir Dinge zu benennen Bedeutung vorsichtig sein ."

Answer 19

DRY: Sie Repeat Yourself nicht Das gibt Ihnen einen Code, der sowohl präzise und sicher ist, den gleichen Code mehrmals zu schreiben, ist ein guter Weg, es ist schwer zu halten zu machen

Jetzt... das bedeutet nicht, dass Sie eine Funktion von irgendwelchen Codeblöcken machen sollten suchen Ferne gleichermaßen.

ein sehr häufiger Fehler (Horror?) zum Beispiel ist Faktorisierung Code fast das gleiche tun, und die Unterschiede zwischen den Vorkommnissen zu handhaben durch Hinzufügen eines Flags zur Funktions-API Dies mag zunächst unschädlich sein, erzeugt jedoch schwer zu verstehenden Code-Fluss und b ug anfällig, und noch schwieriger zu refaktorieren.

Wenn Sie die üblichen Refactoring-Regeln befolgen (indem Sie nach Code-Gerüchen suchen), wird Ihr Code immer prägnanter als ein Nebeneffekt, da viele Code-Gerüche dazu dienen, Redundanz zu erkennen.

Auf der anderen Seite, wenn Sie versuchen, den Code so kurz wie möglich zu machen und keine sinnvollen Richtlinien zu befolgen, müssen Sie irgendwann aufhören, weil Sie einfach nicht mehr sehen, wie Sie Code reduzieren können.

Stellen Sie sich vor, wenn der erste Schritt alle nutzlosen Leerzeichen entfernt ... danach wird der Code in den meisten Programmiersprachen so schwer lesbar sein, dass Sie keine Chance mehr haben werden, eine andere mögliche Verbesserung zu finden.

Das obige Beispiel ist ziemlich natürlich, aber nicht so weit von dem, was Sie bekommen, wenn Sie versuchen, für die Größe zu optimieren, ohne eine vernünftige Richtlinie zu befolgen.