Warum ist Ausführlichkeit für eine Programmiersprache schlecht? [geschlossen]

98

Ich habe viele Leute gesehen, die sich über Ausführlichkeit in Programmiersprachen beschwert haben. Ich finde, dass eine Programmiersprache umso besser zu verstehen ist, je ausführlicher sie ist. Ich denke, dass Ausführlichkeit auch das Schreiben klarer APIs für diese bestimmte Sprache verstärkt.

Der einzige Nachteil, den ich mir vorstellen kann, ist, dass Sie dadurch mehr tippen, aber ich meine, die meisten Leute verwenden IDEs, die die ganze Arbeit für Sie erledigen.

Was sind die möglichen Nachteile einer ausführlichen Programmiersprache?

Fran Sevillano
quelle
20
Haben Sie in letzter Zeit in APL programmiert?
SK-logic
5
Check out Sprachen, Ausführlichkeit und Java von Dhanji R. Prasanna
Jeremy Heiler
67
"Ein Entwickler hat nur eine bestimmte Anzahl von Tastenanschlägen, bevor sie sterben"
CamelBlues
10
Vielleicht sollten Sie die "vielen Menschen, die sich beschweren", nach ihren Gründen fragen.
Eric Lippert
29
@ EricLippert, ich glaube, P.SE ist der perfekte Ort, um eine große Anzahl von "beschwerdeführenden" Entwicklern zu befragen .
Kevin McCormick

Antworten:

168

Das Ziel ist schnelles Verständnis

"Verbose" bedeutet "verwendet zu viele Wörter". Die Frage ist, was "zu viele" sind.

Guter Code sollte auf einen Blick leicht zu verstehen sein. Dies ist einfacher, wenn die meisten Zeichen direkt dem Zweck des Codes dienen .

Signal gegen Rauschen

Wenn eine Sprache ausführlich ist, ist ein größerer Teil Ihres Codes Rauschen. Vergleichen Sie Javas "Hallo Welt" :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... mit Ruby's:

print "Hello World!"

Lärm verschwendet mentale Energie.

Cryptic vs Clear

Andererseits kostet übermäßige Knappheit in einer Sprache auch mentale Energie. Vergleichen Sie diese beiden Beispiele aus Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious
Nathan Long
quelle
20
Ich würde sagen, bei letzterer geht es um die Lesbarkeit auf der Mikroebene (wo wir normalerweise eine ausführlichere Schreibweise bevorzugen), bei ersterer geht es um die Lesbarkeit auf der Makroebene (wo wir normalerweise eine kürzere Schreibweise bevorzugen)
jk.
67
Für jedes Programm, das tatsächlich etwas ausführt , ist Java häufig um einiges besser lesbar, insbesondere bei guter Bibliotheksnutzung.
9
Tatsächlich könnte ein besseres Beispiel für die Ausführlichkeit von Makros in Mustern bestehen, die ein fehlendes Sprachmerkmal
umgehen
21
Ich würde sagen, dass das Beispiel mit Java auch nicht das beste ist. Solche Dinge wie die Notwendigkeit, eine Klasse und eine Methode zu definieren, spielen beim Codegolf eine Rolle, aber kaum bei realen Anwendungen. Es ist nicht so, dass Java viel Code benötigt, um ein paar Wörter auszugeben. Diese wenigen Zeilen sind erforderlich, um ein Programm zu erstellen, und das ist anders.
Malcolm,
27
+1 für die Unterscheidung zwischen Signal vs. Noise und Cryptic vs. Clear
Spoike
118

Dies wirkt sich darauf aus, wie viel Code Sie auf einen Blick sehen und analysieren können

x++ eher, als set(x,Integeradd(get(x),1))

ps. Es geht nicht nur darum, Code zu lesen. In den Tagen von 40x25-Bildschirmen waren Sprachen vom Typ APL oder Perl über Cobol oder Fortran für die Menge an Code nützlich, die Sie / Seite lesen konnten. Aber jetzt geht es mehr um Ihren eigenen internen Cache - wenn eine Anweisung einen einzelnen Operator hat, ist es für mein alterndes Gehirn einfacher, einen zu analysieren als einen mit 3 Symbolen und 4 Funktionsaufrufen.

Martin Beckett
quelle
19
Ich glaube das ist der ultimative Grund. Lesbarkeit auf engstem Raum wie auf einem Blatt Papier oder einem Monitor.
1
+1, und völlig einverstanden, und ich Code auf einem 13-
Zoll-
1
@ ZJR - siehe Bearbeiten.
Martin Beckett
3
Was macht die setMethode hier? Stellt es tatsächlich etwas ein (dh den ersten xParameter) oder gibt es etwas zurück (dh die Zuordnung zu xnach dem Aufruf)? Ich würde sagen, dass es in dem ausführlichen Beispiel eine seltsame Verdoppelung gibt.
Jesse C. Slicer
8
Eine Sache, die hier fehlt, ist die Nützlichkeit von Ideogrammen - Symbole können sinnvoller sein als Worte. ZB +ist sinnvoller als plus. =ist besser als equals. Dies kann natürlich zu weit gehen (und wurde von mehreren Sprachen verwendet), ist aber in Maßen sehr mächtig.
mcmcc
29

Wenn die Ausführlichkeit der Sprache die Lesbarkeit des Codes beeinträchtigt, ist dies schlecht.

Einige Sprachen haben eine so ausführliche Syntax, dass das Erfassen der Bedeutung des Codes länger dauert (ich denke an VB.NET im Vergleich zu C #):

If something Then
End If

if(something)
{}

Es läuft wirklich auf das hinaus, was ein Programmierer kennt und mit dem er sich gut auskennt.

Oded
quelle
6
Ich arbeite meistens in C #, aber wenn ich VB lese, stelle ich fest, dass ich es so lese, als wäre es C #. Ich ignoriere alles If .. Then .. End Ifund lese nur, was wichtig ist.
Andy Hunt
7
genauso wie Andy. Ich finde beide gleich gut lesbar. Ich würde sogar sagen, dass ich eine kleine VB-Variante bevorzuge (obwohl ich eher an c # gewöhnt bin).
dagnelies
9
VB.NET ist im Vergleich zu anderen schlechteren Tätern nicht wortreich!
3
@ AndyBursh - Genau mein Punkt. Beim Lesen von VB.NET machen Sie eine mentale Übersetzung, die über das Verstehen des Codes hinausgeht.
Oded
6
Oded, End-If ist ein viel einfacher zu verstehendes Konstrukt für das Ende einer if-Anweisung als Klammern, wenn sich die Klammern innerhalb einer anderen if-Anweisung, innerhalb einer Schleife, innerhalb einer anderen Schleife, innerhalb einer Funktion befinden eine Klasse. Alle oben genannten Blöcke verwenden die gleichen Klammern, was bedeutet, dass der Versuch, herauszufinden, welcher einer bestimmten Endklammer weniger intuitiv entspricht.
Andrew Neely
27

Schauen Sie sich AppleScript an , eine der ausführlichsten Sprachen, die ich für aktuell halten kann , versuchen Sie , etwas Trivalentes darin zu schreiben, und kommen Sie zurück und argumentieren Sie, dass Ausführlichkeit ein gutes Merkmal in einer Sprache ist.

Der Versuch, sich an die gesamte Semantik zu erinnern, in der sich die Schlüsselwörter befinden und was sie sind, ist nicht trivial, wenn Sie dies nicht jeden Tag tun.

Schauen Sie sich in diesem einfachen Beispiel das gesamte Keyword-Rauschen an:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

Das Gleiche wie bashbei herkömmlichen Unix-Tools wäre für die meisten OSX-Benutzer knapp, aber kryptisch. Es muss also ein Gleichgewicht gefunden werden.

user7519
quelle
15
Wollten Sie nicht, return the 0als Sie das tippten? AppleScript ist die einzige Sprache, die ich kenne und die es Ihnen ermöglicht, Ihre Gegner mit Stichwörtern zu belästigen ... ich meine Kollegen.
Ccoakley
Die Applescript IDE, Script Editor, wurde in den 90er Jahren verwendet, um mit der Ausführlichkeit der Applescript-Aufzeichnung von Aktionen umzugehen . Sie war nicht besonders schlau, aber irgendwie praktisch beim Erstellen von Skripten. Um 1998 löste sich die Aufzeichnung auf und wurde nie wieder behoben . (Keine Ahnung, ob der OSX-Übergang dies behoben hat, IIRC, nein)
ZJR
3
Die OSX-Antwort auf die Umständlichkeit von AppleScript lautet Automator. Ersetzen wir einfach zu tippenden Text durch eine riesige Bibliothek von ziehbaren, ausführlich beschriebenen und schlecht erklärten Funktionsblöcken!
flauschige
Das Schlimmste an AppleScript ist, dass jede Anwendung, mit der Sie arbeiten möchten, eine andere Terminologie haben kann. Apple definiert bestimmte Befehlssuiten, die von allen Programmen unterstützt werden sollen. Im Allgemeinen ist es jedoch nur bedingt hilfreich, wenn Sie wissen, wie man ein Skript für eine Anwendung erstellt.
Kindall
1
Applescript ist mühsam zu schreiben, aber leicht zu verstehen ... im Rahmen der Möglichkeiten von Programmierern, die das Applescript mit verständlicher Syntax in die gesteuerte Anwendung einbinden.
Aramis
23

Ich denke, Sie müssen die Frage auf den Kopf stellen und fragen: Warum denken manche Leute, dass knapper Code gut ist?

Meine Antwort wäre, dass es zwei grundlegende Gründe gibt:

Gründe, warum knapp besser sein kann

Dazu gehört, dass man besser lesbar ist, so wie ein kurzer Satz verständlicher sein kann als ein blumiger, ausführlicher Satz. Häufig sind Programmiersprachen, die versuchen, die Grammatik der englischen Sprache zu emulieren, fürchterlich umständlich und erfordern große Codeausdehnungen, um die einfachsten Aktionen auszuführen. Oft werden Sie feststellen, dass es umso schwieriger ist, eine Sprache zu logisch komplexen Operationen zu überreden, je mehr sie eine geschriebene Sprache emuliert.

Gründe, warum knappe kann schlimmer sein

Einige Sprachen (und ich denke an Perl) verwenden als Teil ihrer Syntax eine Reihe seltsamer Symbole, die scheinbar willkürlich ausgewählt wurden. Für jeden, der mit diesen Hieroglyphen nicht vertraut ist, wird die Sprache undurchdringlich. Es wird auch leicht, Tippfehler zu machen, die nicht leicht zu erkennen sind. Reguläre Ausdrücke verkörpern vielleicht diese Art von Knappheit.

Außerdem geben manche Leute gerne damit an, dass sie knappen Code schreiben, weil sie ehrlich gesagt denken, dass sie dadurch schlau aussehen. Dies ist manchmal bei StackOverflow der Fall, wo häufig äußerst kompakte Antworten eingereicht werden, die die Lesbarkeit beeinträchtigen. Dies ist eine Art "beeindrucken Sie Ihre Kollegen" mit wie viel Sie Philosophie kennen, aber gute Programmierer erkennen, dass " Code Golf " nicht der Weg ist, wartbare Software zu erstellen.

Dan Diplo
quelle
Ich würde nicht in Betracht ziehen, das Gegenteil von ausführlich zu formulieren. Verbose hat eine negative Konnotation und ist daher wahrscheinlich besser für ein Antonyme mit positiver Konnotation geeignet.
Joshua Drake
6
terseist das Antonyme von verbose, tersekann genau die gleiche negative Konnotation tragen (siehe Perl)
1
@JarrodRoberson: Ich hasse es, ausgerechnet an einem Freitagabend pedantisch zu sein, aber ich habe mir ein paar Online-Thesaurus angesehen, und keiner von ihnen hat terseals Antonyme verbose(oder umgekehrt). / ducks
Scott Mitchell
1
@ScottMitchell de.wiktionary.org/wiki/terse#Antonyms
naught101
15

@frowing, ich würde vorschlagen, dass eine Möglichkeit, das Problem der Ausführlichkeit zu betrachten, darin besteht, zu erkennen, dass Programmierung immer eine Mischung aus zwei ziemlich unterschiedlichen Arten ist, eine Lösung zu finden und auszudrücken.

Der erste und ausführlichere Stil ist die sprachorientierte (sprachliche) Programmierung. Dieser Stil kombiniert nomenähnliche Wörter und verbähnliche Wörter in satzähnlichen Strukturen und soll auf die gleiche Weise wie ein gut geschriebener Absatz gelesen und verstanden werden. Sprachprogrammierung ist der universellste Programmierstil, da die Sprache selbst universell ist. Aus dem gleichen Grund benötigt die langfristige Programmunterstützung immer eine leistungsfähige sprachliche Komponente, da das erste, wonach ein neuer Programmierer suchen wird, das konzeptionelle Verständnis dessen, was getan wird. Je weiter Sie sich von dem Kontext entfernen, in dem Sie ein Programm erstellt haben, desto wichtiger ist in der Regel ein sprachlicher Programmierstil, um sicherzustellen, dass Ihre Annahmen und Konzepte nicht von der nächsten Person missverstanden werden, die versucht, Ihren Code zu verstehen .

Der zweite und prägnantere Stil ist die mathematisch orientierte Programmierung. Diese Art des Denkens beruht auch auf der Sprache, da zum Beispiel Variablen zu Nomen und Operatoren zu Verben analog sind. Das mathematische Denken nutzt jedoch die erstaunliche und höchst parallele Fähigkeit unseres Gehirns, komplexe räumliche Transformationen an Objekten vorzunehmen, die sich in unserer Sichtlinie befinden. Indem wir Substantive und Verben als kompakte, unverwechselbare Symbole darstellen, die in gut strukturierten imaginären Objekten - Gleichungen - angeordnet werden können, können wir unsere hochparallelen visuellen Fähigkeiten nutzen, um Rotationen, Ersetzungen, Bewegungen, Inversionen und andere Transformationen an diesen imaginären Objekten durchzuführen Objekte. Das Ergebnis ist eine enorme Steigerung der Anzahl der Fälle, die wir gleichzeitig bearbeiten können, da jedes Symbol ganze Klassen eng verwandter Objekte darstellen kann.

Beachten Sie, dass Sie Ihr imaginäres Objekt in Größe und Merkmalen einem realen Objekt so ähnlich wie möglich halten müssen, um die visuelle Verarbeitung effektiv anwenden zu können. Wenn das erforderliche Sichtfeld zu weit wird oder die Symbole nicht wie bewegliche Markierungen auf einem Objekt verwendet werden können oder wenn Sie Buchstaben „lesen“ und in Wörter umwandeln müssen, wird die Fähigkeit, komplexe Transformationen zuverlässig durchzuführen, beeinträchtigt schnell auch für einen sehr guten Mathematiker.

Das ist der Grund, warum Menschen, die tief in den mathematischen Stil des Programmierens vertieft sind, ernsthaft unglücklich werden können, wenn eine Gleichung in einem so genannten "wörtlichen" Sprachstil ausgedrückt wird. Es liegt nicht daran, dass sich die Gleichung wesentlich geändert hat, sondern daran, dass eine solche Verbreitung es nahezu unmöglich machen kann, einen visuellen Stil des Verstehens auf sie anzuwenden. Gleichzeitig wird ein neuer Programmierer, der mit den kurzen Symbolen überhaupt nicht vertraut ist, wahrscheinlich eine ausführlichere Version bevorzugen, die mehr sprachliche Informationen bietet, um zunächst zu verstehen, was der Code tut.

Also, was würde ich empfehlen?

Verwenden Sie beide Stile, achten Sie jedoch genau darauf, warum Sie die einzelnen Stile verwenden.

Zum Beispiel sollte alles, was die Möglichkeit hat, mit der Außenwelt in Kontakt zu treten, auf einer bestimmten Ebene sehr ausführlich sein, auch wenn es sich nur um Inline-Kommentare handelt, die mit dem Code vermischt sind, und es sollte auch eine automatische Überprüfung auf korrekte Verwendung enthalten. Kryptische und vor allem unvollständig definierte Notationen haben mit solchen Schnittstellen nichts zu tun, da sie irgendwann garantiert missverstanden werden. Der Verlust des Mars Climate Obiter im Jahr 1999, der darauf zurückzuführen ist, dass nicht erkannt wurde, ob Software-Schnittstelleneinheiten in Pfund oder Newton ausgedrückt wurden, ist ein besonders deutliches Beispiel für die Gefahren, sich bei Software- oder Hardware-Schnittstellen zu beiläufig auf unformatierte Zahlen zu verlassen.

Umgekehrt ist jede Form der Programmierung, die stark algorithmisch und mathematisch ist, ein guter Kandidat für eine prägnante Programmierung, die den mathematischen Denkstil unterstützt. Wenn jemand neuen Code pflegen muss, ist es normalerweise besser, die mathematischen Notationen zu lernen, als zu versuchen, den Code in ausführlichere Formen umzuwandeln. Es sollte natürlich jederzeit eine Dokumentation zur Verfügung stehen, um den Entwicklern die mathematischen Teile des Codes zu erläutern, aber das ist ein separates Problem.

Dazwischen liegen viele Fälle, in denen der Programmierer über ein beträchtliches Ermessen verfügt. Ich würde vorschlagen, zu prüfen, wie der Code auf lange Sicht gepflegt wird, und zu versuchen, den Bedürfnissen der Menschen Rechnung zu tragen, die den Code auf lange Sicht am ehesten pflegen.

Terry Bollinger
quelle
8

Einige Leute haben auf etwas hingewiesen, von dem ich denke, dass es wahrscheinlich explizit angegeben werden sollte.

Ausführlichkeit tendiert dazu, das Verständnis auf mikroskopischer Ebene zu begünstigen - es führt im Allgemeinen dazu, dass eine einzelne Aussage leicht zu lesen und zu verstehen ist. Ausführlichkeit neigt auch dazu, den Grad der Vertrautheit mit der Sprache, die zum Verstehen erforderlich ist, zu verringern (bis zu einem gewissen Grad). Die ausführlichsten Sprachen (z. B. COBOL) können selbst von vollständigen Nicht-Programmierern zumindest etwas lesbar sein.

Concision tendiert zum Gegenteil: Es hilft beim Verständnis auf makroskopischer Ebene, insbesondere von Programmierern, die mit dieser bestimmten Sprache bestens vertraut sind. Gleichzeitig kann eine mangelnde Vertrautheit mit dieser spezifischen Sprache sogar ein rudimentäres Verständnis verhindern, selbst von Programmierern, die ansonsten ziemlich erfahren sind.

Daher variiert die Lesbarkeit je nach Zielgruppe erheblich. Stellen Sie sich auf der einen Seite ein großes, komplexes Projekt vor, das von Leuten geschrieben und gepflegt wird, die fast ausschließlich an diesem Projekt arbeiten und zum größten Teil über umfangreiche Programmierkenntnisse und -kenntnisse verfügen (z. B. viele Doktoranden). Dies wird tendenziell zu einer prägnanteren Sprache führen.

Stellen Sie sich im Gegenteil ein Projekt vor, das erheblich einfacher (wenn auch möglicherweise noch recht umfangreich) ist und in erster Linie von Leuten verwaltet wird, die sich wirklich auf das mit der Software verbundene Geschäft spezialisiert haben, und nicht auf die Software selbst. Dies wird mit ziemlicher Sicherheit eine viel ausführlichere Sprache bevorzugen.

Jerry Sarg
quelle
6

Anstatt ein technisches Buch zu lesen, greife ich auf die Elements of Style * von Strunk and White zurück. Das zugrunde liegende Konzept lautet "Sei genau" und "Sag nicht mehr als nötig". Alles andere ist Kommentar.

Beim Programmieren geht es darum, sehr präzise zu sein, aber keine unnötigen Flusen zu haben. Der zusätzliche Flaum kann Syntax sein, es können aber auch mehr Wörter als erforderlich sein, um die Bedeutung zu vermitteln. (Natürlich auch nicht zu wenig, um Mehrdeutigkeiten zuzulassen.)

  • Ich zitiere die Originalversion, da sie die prägnanteste ist. :-)
MathAttack
quelle
5

Am Ende des Tages wird alles, was "anders" ist, Menschen zum Heulen bringen. Ich bin mit der Syntax im C-Stil vertraut und daher mit anderen Sprachen, die eine ähnliche Syntax haben (C ++, Java, C #), in Ordnung. Also neige ich dazu, diesen besonderen Stil zu bevorzugen.

Sprachen neigen dazu, ein Gleichgewicht zwischen beschreibend genug und nicht ausführlich zu finden.

Perl ist ein Beispiel dafür, wo Sie sehr präzisen Code schreiben können. Für den Uneingeweihten ist der von einem Perl-Ninja geschriebene Code geradezu magisch.

COBOL ist ein Beispiel für zu ausführlich.

Nasir
quelle
5
Wie beantwortet dies die Frage?
ChrisF
Ausführlichkeit ist für jeden unterschiedlich. Das war die Absicht meines Kommentars. Wenn Sie im C / C ++ - Camp sind, unterscheidet sich die akzeptierte Ausführlichkeit von der im Perl-Camp.
Nasir
Code geschrieben von einem Perl-Ninja ist nichts weniger als Magie? Im Ernst, ich denke, es ist ein Albtraum.
Kevin
Ich meide Perl :)
Nasir
Für Programmierer ist COBOL im Vergleich zu anderen Sprachen möglicherweise zu ausführlich. Gut geschriebenes COBOL kann jedoch für Geschäftskunden leicht lesbar sein. Auf diese Weise können sie überprüfen, ob der Code den Anforderungen entspricht, indem sie ihn lesen.
BillThor
4

Ich habe einmal irgendwo gelesen, dass ein Großteil der ausführlichen Debatte von neuen Programmierern gegen alte Hasen kommt. Die verwendete Analogie war, dass wir uns, wenn wir etwas Neues lernen, eine "Geschichte" erzählen, um sie durchzuhalten (denken Sie daran, wann Sie Algebra in HS gelernt haben). Wenn wir Erfahrung sammeln, gehen wir über die Notwendigkeit einer Geschichte, in der einzelne Komponenten erklärt werden, hinaus und verstehen eine größere Menge. Unser Code wird dichter und prägnanter, wobei Kommentare nur die erforderlichen Elemente erläutern, anstatt zu wiederholen, was der Code sagt.

Ich habe festgestellt, dass dies zwischen mir und einem Kollegen zutrifft. Sie schreibt Code mit vielen Kommentaren, die erklären, was die Codezeilen sind, und viel Leerraum. Wenn ich es lese, stelle ich fest, dass ich nur ein paar Codezeilen auf einem Bildschirm anzeigen kann. Das macht das Verstehen jeder einzelnen Zeile viel einfacher, aber es wird viel schwieriger, die gesamte Funktion zu verstehen.

Ich neige dazu, Code ohne zusätzliche Leerzeichen oder Kommentare zu schreiben. Dies erleichtert das Sehen des Ganzen erheblich, aber Sie müssen in der Lage sein, die einzelnen Code- "Wörter" einfach "abzurufen". Wenn Sie versuchen würden, diese Antwort so zu lesen, dass jedes Wort in einer eigenen Zeile steht, mit vielen Leerzeichen / Kommentaren / zusätzlichen Worten, dann wäre es viel einfacher, jedes einzelne Wort zu verstehen, aber viel schwieriger, das Ganze zu verstehen.

Spencer Rathbun
quelle
Niemand ist gegen Kommentare. Das Problem sind Sprachen wie Java, AppleScript oder Visual Basic, die viele redundante, aber obligatorische Elemente enthalten.
Marcin
2
@Marcin Ich bin auch nicht gegen Kommentare, aber wenn sie so sind: i++; //this is adding one to var iEs ist überflüssig.
Spencer Rathbun
Die Frage bezieht sich jedoch auf Programmiersprachen.
Brendan Long
2
@BrendanLong Hmm, vielleicht war mir nicht klar. Ich habe unnötige Kommentare mit ausführlichen Programmiersprachen gleichgesetzt. Viele Wörter, um dasselbe zu sagen, nur eine ausführliche Programmiersprache erfordert sie zu jeder Zeit.
Spencer Rathbun
Man könnte argumentieren, dass eine Funktion sowieso nicht aus mehr als ein paar Zeilen bestehen sollte. Wenn es schwer zu verstehen ist, wie die Funktion funktioniert, liegt es wahrscheinlich nicht an zu vielen Kommentaren. Aber ich stimme zu, dass Kommentare, die nur sagen, was sowieso sofort klar ist, besser vermieden werden sollten.
linksum den
4

Einstein hat es richtig verstanden: "Machen Sie die Dinge so einfach wie möglich, aber nicht einfacher."

Dies gilt auch für Code. Wenn Sie Code vereinfachen können, indem Sie sich wiederholende und unnötig ausführliche Elemente entfernen, ist dies eine gute Sache.

Außerdem legen einige Fallstudien nahe, dass die in Codezeilen gemessene Programmiererproduktivität mehr oder weniger konstant ist. So ist die Anzahl der Fehler pro LOC. Der Wechsel zu einer Sprache, mit der Sie mehr pro Codezeile tun können, kann als Produktivitätsverbesserung angesehen werden, wenn alle anderen Faktoren gleich bleiben.

Davon abgesehen besteht in dieser Branche die Tendenz, zu viel zu konstruieren und zu komplizieren, was eigentlich einfach sein sollte. Einfache Dinge wie das Speichern von Kontaktdaten in einer relationalen Datenbank. Ich habe einige lächerlich komplizierte und fehlgeleitete Lösungen ( Husten MDA) für dieses bestimmte Problem gesehen. Sprachen wie Scala und Ruby sind gute Beispiele für leistungsstarke Tools, die in den Händen bestimmter Personen zu unverständlichem, übermäßig kompliziertem und schlecht wartbarem Code führen. Nur weil Sie mit ein paar Tastenanschlägen mehrere Indirektionsebenen verwenden können, bedeutet dies nicht, dass Sie jeden Nagel, der in Sichtweite ist, mit diesem bestimmten Hammer einschlagen müssen.

Bei richtiger Verwendung erhalten Sie einen sauberen Code, der kurz und verständlich ist. Bei unsachgemäßer Verwendung ist es besser, die betreffende Person auf die Verwendung von Visual Basic oder einer ähnlich eingeschränkten Sprache zu beschränken, um weiteren Schaden zu vermeiden.

Die wahre Fähigkeit besteht darin, komplexe Dinge auf einfache Weise zu machen, nicht darin, einfache Dinge auf komplizierte Weise zu machen.

Jilles van Gurp
quelle
3

Etwas, das niemand sonst getroffen hat, ist die Menge an Code, die Sie auf einem Bildschirm anzeigen können. Es hilft aus mehreren Gründen:

  • Weniger Scrollen vor und zurück, wenn Sie mehrere Funktionen in einer Datei bearbeiten (oder lesen).
  • Weniger horizontales Scrollen (Lesen anhalten, Bildlaufleiste anklicken und ziehen, Lesen anhalten, Bildlaufleiste anklicken und ziehen ...).
  • Schnelleres Scannen, da weniger nutzlose Syntax die Suche nach dem gewünschten Objekt behindert.
Brendan Long
quelle
Wie viel Scrollen wird auf einem 1920 x 1080-Bildschirm mit einer einigermaßen lesbaren Schriftgröße ausgeführt? Es gibt auch Tastenkombinationen für die Navigation.
@JarrodRoberson - Mein Bildschirm zeigt ungefähr 30 Zeilen. Wenn ich das Codefenster auf Vollbild stellen und die Schriftgröße verringern, um kaum lesbar zu sein, erhalte ich 60 Zeilen. Ich musste an mehreren tausend Zeilendateien arbeiten (ich versichere Ihnen, dass dies kein Zufall war). Ich verwende den "Navigator" in meiner IDE, aber es ist noch lange nicht so praktisch, wie zwischen zwei Codeabschnitten zu blättern, die beide auf dem Bildschirm angezeigt werden.
Brendan Long
Unterstützt Ihre IDE keine geteilten Ansichten?
links ungefähr am
2
Ihnen beiden entgeht der springende Punkt - ob meine IDE das Scrollen weniger schlecht machen kann , wird es niemals so gut sein, als wenn Sie überhaupt nicht scrollen müssen (oder Hotkeys oder Splitscreen verwenden) . Es ist, als würde man sagen "Bildschirmtastaturen sind in Ordnung, haben Sie noch nie davon gehört, auf etwas zu klicken?"; Natürlich habe ich, aber es ist nicht zu übertreffen, eine echte Tastatur zu haben.
Brendan Long
Ich erinnere mich vage daran, dass es tatsächlich Studien gibt, die belegen, dass dies zutrifft (insbesondere der scrollende Teil). Scrollen zu müssen, um eine ganze logische Einheit zu sehen, erschwert das Verständnis. Klingt zumindest plausibel.
Konrad Rudolph
1

Weil mehr Code mehr Entwicklungszeiten und mehr Fehler bedeutet.

Wenn Sie 100 Codezeilen anstatt 300 Codezeilen schreiben. Das bedeutet, dass Sie fast 1/3 der Entwicklungszeiten benötigen und 1/3 der potenziellen Fehler, auf die Sie möglicherweise stoßen.

In den meisten Fällen müssen Sie Effizienz und Prägnanz in Einklang bringen, da das Schreiben von weniger Codes bedeutet, dass die Maschine mehr Aufgaben ausführen muss und die Effizienz dadurch verringert wird.

Fang Zhou
quelle
2
Ich würde weit mehr versteckte Fehler in 100 typischen Perl-Zeilen erwarten als in 300 Ada-Zeilen. - Da "weniger Codes schreiben bedeutet, dass die Maschine mehr Dinge tun muss und die Effizienz sinkt", kann es eine solche Korrelation geben, aber dies ist keine Kausalität. Es ist nur so, dass die knappen dynamischen und / oder interpretierten Sprachen wie Ruby, Perl und Python langsamer sind als die ausführlicheren statisch kompilierten Sprachen wie C oder Fortran. Verkürzte kompilierte Haskell-, Python-w / PyPy- oder C ++ - Programme können jedoch viel schneller sein als ausführliche, z. B. interpretierte Basic-, Groovy-, Smalltalk- oder sogar C # -Codes.
linksum den
1

Normalerweise bevorzugen die Leute lesbare / ausführliche Sprachen gegenüber kryptischen / knappen. Ich denke jedoch, dass die meisten Leute "Ausführlichkeit" mit "Unordnung" assimilierten, die nicht dasselbe sind.

Zum Beispiel: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

ist eine sehr knappe Aussage. Es enthält alles, was Sie wissen wollen. Aufgrund seiner Kürze ist es jedoch schwer zu verstehen. Andererseits wäre eine etwas ausführlichere Version desselben Programms recht einfach zu verstehen, da sie besser lesbar ist. Dies ist natürlich keine Eigenschaft der Sprache per se, aber einige Sprachen tendieren zu mehr Ausführlichkeit, während andere zu mehr Prägnanz in ihrer Programmierweise tendieren.

Zum anderen Extrem der Ausführlichkeit gehört http://en.wikipedia.org/wiki/Literate_programming , was ich für ein ziemlich interessantes Konzept halte.

Ein weiterer Aspekt ist "unerwünschte Ausführlichkeit", auch "Unordnung" genannt. Dinge, die Sie aus technischen Gründen hinzufügen müssen, Mangel an syntaktischem Zucker, aufgeblähte APIs und so weiter.

Ich halte eine klare und intuitive Syntax für sehr wichtig. Es muss auch ausführlich genug sein, um ein leichtes Lesen zu ermöglichen. Zu kurze Anweisungen mit zu viel Logik können oft zu einer längeren Entschlüsselungszeit führen als ihre etwas längeren Gegenstücke. Auf der anderen Seite ist unnützer aufgeblähter Code voller Boilerplate-Zeilen, um etwas ganz Einfaches zu tun, gleichermaßen ein Ärgernis.

Arnaud
quelle
4
Vielleicht möchten Sie die [Bedeutung von prägnant] ( en.wiktionary.org/wiki/concise ) noch einmal überprüfen , da dies fast ein Antonyme von kryptisch ist. Schreiben Sie vielleicht in Java?
Joshua Drake
2
Ich bevorzuge ausführlichen Code in prägnanten Sprachen.
Brendan Long
@Joshua: Ja, ich habe bemerkt, dass es sehr unterschiedlich interpretiert werden kann, also habe ich meine Antwort bearbeitet. ... und was hat Java damit zu tun?
Dagnelies
1
Ein Kommentar, der angibt, warum es abgelehnt wurde, ist möglicherweise interessanter als die Ablehnung selbst.
dagnelies
@arnaud mein schlechtes für die Verwendung von Wiktionary. Die Google-Suche define: concise startet: "Viele Informationen klar angeben", gegen die Ihr Beispielcode eindeutig verstößt. Obwohl ich die ursprüngliche Bedeutung von Knappheit anerkennen muss, reisen wir jetzt klar und deutlich zusammen.
Joshua Drake
1

Ausführlichkeit ist eine Tendenz, umfangreiche Textmengen zu verwenden, und Knappheit die Verwendung von sehr wenig Text ...

Ausführlichkeit ist schlecht, weil:

  1. Es bietet mehr Möglichkeiten für Tippfehler
  2. Dadurch wird es schwieriger, Code auf dem Bildschirm oder Papier zu lesen und / oder auf der Lochkarte einzugeben
    1. Dies erhöht die Debug-Zeiten
    2. Dies erschwert das Verständnis des Codes für die Aktualisierung / Wartung
    3. Dies kann zu unbeabsichtigter Code-Vervielfältigung führen
  3. Dies erhöht die Wahrscheinlichkeit von Syntaxfehlern etwas
  4. es verringert die Flexibilität der Codierung, da die meisten ausführlichen Sprachen stark strukturiert sind und nicht mehrere Möglichkeiten haben, dasselbe zu sagen.
  5. Es erhöht die Codierungs- und Kompilierungszeiten
  6. Es kann mehr Speicherplatz in Anspruch nehmen.

Ein gewisses Maß an Ausführlichkeit ist jedoch für die Klarheit unerlässlich ...

Ein Mindestmaß an Ausführlichkeit ist gut, weil:

  1. Es ist für den Menschen einfacher, semantischen Wert zu lesen und ihm beizufügen als rein symbolischen Code
  2. Bei der Benennung von Variablen und Funktionen wird das Debuggen, Portieren und Verwalten von Code vereinfacht
  3. Bei Sprachoperationen auf Basisebene und Schlüsselwörtern komplexer Sprachen führt dies zu weniger falschen Operationen / Schlüsselwortzuweisungen.

Einige wunderbare Beispiele für zu knappe Befehle für viele Menschen sind die alten BASIC-Standbys von val(x$), str$(x)und chr$(x)..., die eine Zahl aus der Zeichenfolgendarstellung zurückgeben, eine Zeichenfolge für eine Zahl zurückgeben und ein einzelnes Zeichen mit dem ASCII-Wert x als Zeichenfolge zurückgeben.

Oder der C / C ++ - Zeiger und die Referenzoperatoren &und *das byrefSchlüsselwort BASIC . In C / C ++ kann ich eine Variable X haben und einen Zeiger auf diese Variable übergeben, aber ich muss mich daran erinnern, welcher der Zeiger und welcher der "Use-Zeiger als die Variable ist, auf die er zeigt" ist. Im Grunde übergebe ich die Referenz einfach mit einem byref-Schlüsselwort im Funktionsaufruf, was klarer, aber weniger flexibel ist:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

In diesem Code wird der Inhalt von x aufgrund des byref-Flags geändert. Einige Geschmacksrichtungen erlauben byref at call, andere in der Definition, andere in beiden.

Die Ausführlichkeit ist wichtig, damit Gelegenheitsprogrammierer die Symbolik leichter verwenden können. BASIC oder Python sind lesbarer und ausführlicher als C / C ++ und daher für Gelegenheitsprogrammierer viel nützlicher. Die Kürze von C / C ++ macht es viel besser für erfahrene Programmierer, die mehr Code und komplexeren Code auf einem Bildschirm sehen müssen, aber die verschiedenen symbolischen Strukturkonventionen kennen müssen. Am anderen Ende befindet sich APL, das fast vollständig für den Menschen unlesbar ist.

Ein eng verwandtes Problem ist die Klarheit - knapper Code ist oft unklar und übermäßig ausführlicher Code (wie in AppleScript) kann ebenso unklar sein. Die Vertrautheit mit einer bestimmten Sprache erhöht die Klarheit des knappen Codes in dieser Sprache - ein Anfänger, der mit C ++ konfrontiert ist, kann wahrscheinlich nur die Formeln analysieren, und selbst ein Großteil des funktionellen BASIC- oder Python-Codes ist für das Verständnis zu knapp, aber AppleScript kann es im Allgemeinen ohne Rückgriff auf Sprachwörterbücher verwirrt werden. Das am wenigsten klare, was ich ohne absichtliche Verschleierung erlebt habe, ist Inform 7 ...

In den alten Tagen

Ein weiterer wichtiger Gesichtspunkt in der Vergangenheit, der jedoch für den Hobby-Programmierer nicht mehr so ​​wichtig ist, ist die Bedienung und der Speicherplatz. (Am oberen Ende ist es immer noch wichtig.) Unter Berücksichtigung der Tatsache, dass viele Sprachen interpretiert wurden, insbesondere BASIC-Varianten, und viele weitere zur Laufzeit kompiliert wurden, war der Code-Speicherplatz wichtig, insbesondere, wenn die Festplatten nur 128 KB groß und einzelne Lochkarten nur 80 KB groß waren.

Es gab mehrere Lösungen - Tokenisierung war in BASIC äußerst verbreitet; Die einzelnen Sprachschlüsselwörter wurden entweder im oberen 128 oder im Steuerzeichenbereich auf ein 1 oder 2-Byte-Wort reduziert. Die Tokenisierung führte auch zur Bytecode-Kompilierung (wie bei Inform und der Z-Machine).

Das Kompilieren und Verknüpfen mehrerer Objektdateien wurde auch verwendet, um Speicherplatzbeschränkungen zu umgehen. Ein 100-KB-Pascal-Codeabschnitt kann möglicherweise nur mit 5 KB kompiliert werden. Durch das Verknüpfen mehrerer kompilierter Dateien können umfangreiche Anwendungen erstellt werden, ohne dass auf großformatige Laufwerke zugegriffen werden muss.

Bei knapperen Sprachen wurde jedoch mehr Code in einen bestimmten Teil sowohl der Festplatte als auch des Arbeitsspeichers eingefügt, sodass jeweils größere Teile kompiliert wurden. Denken Sie daran: "Minicomputer" der frühen 1970er Jahre hatten möglicherweise nur 64 KB RAM (der Honeywell 800 verfügte über eine Basisinstallation von 4 Bänken mit jeweils 2048 Wörtern zu je 8 KB). APL und ähnliche symbolische Sprachen näherten sich 1B pro Befehl plus Operanden gegenüber den viel größeren 3B-10B pro Befehl plus Operanden. (Es war ein Albtraum, auf Lochkarten zu tippen, zumal die Symbole im Wesentlichen eine Schriftart auf Typ-Ball waren und viele Kartenstanzen nicht die Symbole auf den Schlüsseln hatten ...)

Denken Sie auch daran, dass Karten nicht gelöscht werden konnten ... und viele Programme auf Karten eingegeben wurden. Je komprimierter der Code auf der Karte ist, desto weniger wird benötigt und desto größer oder billiger sind die Programme. Dies ist ein Grund dafür, dass BASIC in den meisten Varianten mehrere Anweisungen pro Zeile verkettet - dies wurde eingeführt, um Lochkarten einzusparen. (Das sagt zumindest mein Vax Basic-Programmiertext.) Obwohl ich nicht für einen Kartenleser programmiert habe, habe ich die Karten für einen Honeywell 800 in FORTRAN, BASIC, APL und einigen anderen hochsymbolischen Sprachen gestanzt.

Aramis
quelle
Ausführlichkeit erhöht in vielen Fällen die Wahrscheinlichkeit, dass typografische Fehler beim Kompilieren erkannt werden , anstatt nur fehlerhaftes Verhalten zu verursachen.
Supercat
-1

Wie bei so vielen Dingen hängt die Antwort von der konkreten Definition von "Ausführlichkeit" ab. Wenn die Definition so ist, dass Ausführlichkeit Redundanz impliziert, würde ich behaupten, dass es immer schlecht ist. Beachten Sie, dass bei einer solchen Definition das oft zitierte Java-Hallo-Welt-Programm nicht als "ausführlich" eingestuft wird, da nichts redundant ist.

Ingo
quelle
1
Ausgeglichene Klammern und Semikolons sind ebenso überflüssig wie weitgehend Typdeklarationen.
Marcin
1
@Marcin: Ja, aber sie machen das Schreiben eines Parsers / Analysators für die Sprache einfacher. Ich bin ziemlich davon überzeugt, dass eine solche Syntax zugunsten des Sprachimplementierers und nicht des Programmierers existiert, der die Sprache verwendet.
Ccoakley
1
@Marcin - hängt ganz von der Sprache ab, ob Typdeklarationen erforderlich sind oder nicht. Bestimmte Schriftsysteme sind einfach nicht entscheidbar, daher ... in Bezug auf Klammern und Semikolons möchten Sie lieber eine Sprache mit einer eindeutigen Grammatik und einem kurzen Lookahead - oder das Kompilieren selbst kleiner Programme kann Stunden dauern und am Ende können Sie Sie müssen auswählen, welche Interpretation Ihres Programms Sie bevorzugen.
Ingo
1
@ingo Mir ist keine Sprache bekannt, in der aufgrund der Komplexität des Typsystems für alle Variablen oder Funktionen eine Typdeklaration erforderlich ist. Tatsächlich würde ich sagen, dass Sprachen mit leistungsfähigeren Typsystemen eher das Weglassen solcher Deklarationen zulassen.
Marcin
1
@Marcin, kein Grund wütend zu werden. Sie sagten, ich würde sagen, dass Sprachen mit leistungsfähigeren Typsystemen eher das Weglassen solcher Deklarationen zulassen, und ich gab Ihnen ein Beispiel, in dem ein leistungsfähigeres Typsystem mehr Typanmerkungen erfordert. Wenn Sie das Gefühl haben, dass dies Ihrer Konsequenz nicht widerspricht, dann sollten Sie es auch tun.
Ingo
-1

Programmierer neigen dazu, Sprachen mit Ausdruckskraft zu mögen, da sie dadurch die einfachen Dinge, die häufig ausgeführt werden müssen, in kleinen Codestücken codieren können. Ausführliche Sprachen bedeuten in der Regel, dass viele, viele Codezeilen verwendet werden müssen, um immer wieder dasselbe zu tun. Bei ausdrucksstarken Sprachen kann jedoch ein gewisser Preis anfallen, da sie möglicherweise nicht so schnell ausgeführt werden können wie einfachere Hochsprachen. Wenn ich im Kontrast zwischen C und C ++ ein Beispiel geben kann. C ++ verleiht Code-Schreibern mehr Ausdruckskraft - sie können die Idee von Objekten der realen Welt in Klassen zusammenfassen. C-Programmierer können die gleichen Dinge erreichen, aber sie verfügen über die Ausdruckskraft des Klassenkonstrukts, um ihnen zu helfen - so oft müssen sie längeren, komplizierteren (um zu verstehen) Code schreiben. Dieser Code kann jedoch schneller ausgeführt werden (obwohl dies in hohem Maße von der Compilerqualität usw. abhängt), da für die Ausführung des Codes nicht die "späte Bindung" von C ++ (dh das Laufzeit-Refactoring) verwendet wird. C führt nur den kompilierten und verknüpften Code aus, C ++ muss (unter bestimmten Umständen) zur Laufzeit entscheiden, welche Codeteile ausgeführt werden sollen.

adrianmcmenamin
quelle
Mit dieser "späten Bindung" meinen Sie wahrscheinlich virtuelle Funktionsaufrufe. Dies ist jedoch nur eine Möglichkeit unter vielen anderen, die Wiederverwendung von Code zu erreichen. Dynamische Typisierung ist eine weitere Möglichkeit, und sie ist wahrscheinlich ein besseres Beispiel für Ihren Standpunkt, da dies tendenziell mit viel mehr Aufwand verbunden ist als die virtuellen Aufrufe von C ++. Es gibt jedoch auch Mechanismen, die sich überhaupt nicht auf die Laufzeitleistung auswirken, da sie zur Kompilierungszeit vollständig aufgelöst werden können: In modernen objektorientierten Sprachen verfügen Sie über Vorlagen / Generika, in statischen Funktionssprachen über parametrischen Polymorphismus.
Leftaroundabout
Spätes Binden ist das, was verwendet wird, um virtuelle Funktionsaufrufe zum Laufen zu bringen. Nein, ich habe nicht "virtuelle Anrufe" gemeint, ich habe spätes Binden gemeint. Virtuelle Anrufe sind Teil der Sprachdefinition, eine späte Bindung bewirkt, dass dieser Teil funktioniert. Und ja, natürlich gibt es auch andere Beispiele in anderen Sprachen. Ich habe ein Beispiel für die Möglichkeit eines Kompromisses zwischen Ausdruckskraft und Geschwindigkeit angeführt und nicht empfohlen, eine Sprache einer anderen vorzuziehen.
Adrianmcmenamin
-1

Ich glaube, dass es eine Antwort auf die Frage gibt, die auf einer grundlegenderen und theoretischeren Frage als der Lesbarkeit beruht, und diese Antwort bezieht sich auf die von Gregory Chaitin begründete algorithmische Informationstheorie: http://en.wikipedia.org/wiki/Algorithmic_information_theory . Mit wenigen Worten ausgedrückt: "Der Informationsgehalt einer Zeichenfolge entspricht der Länge der kürzestmöglichen in sich geschlossenen Darstellung dieser Zeichenfolge." Dies impliziert, dass das kürzeste Programm (nämlich in Bezug auf seine lexikografische Länge) ein gegebenes Problem genau löst stimmt mit der Komplexität des Problems überein, für das es eine Lösung gibt, und hängt daher mehr von der Art des Problems und weniger von der Darstellung des Problems ab.

Daniel
quelle