Hallo,

es gibt verschiedene Kriterien, um Code zu beurteilen. Zum Beispiel:
• Einhaltung der Styleguides der jeweiligen Sprache, des Projektes, der Firma.

die Übereinstimmung mit vorgegebenen Style Guides ist IMO kein Kriterium, um Code zu beurteilen, sondern höchstens, um die Style Guides zu beurteilen.

• Ansprechende Formatierung
• Effizienz, sprich bestes O() erreichen. Auch Speichereffizienz.
• Mit der Programmiersprache/API arbeiten, statt gegen sie. D.h. in Javaland objektorientiert, in Haskell funktional. Gerne mal die standard library durchforsten, was es da alles schon gibt und wie es einem helfen kann.

Alles sinnvolle Kriterien, denke ich.

Mich beschäftigt etwas, was irgendwo dazwischen liegt, wofür ich aber nicht so wirklich ein Vokabular finde. Nicht Microästhetik wie Formatierung sondern mehr eine Ästhetik, die den Quellcode verständlicher macht. Die Absicht hinter dem konkreten Ablauf verständlich macht und gleichzeitig verwirklicht.

Ich glaube zu verstehen, was du meinst - und behaupte mal, dass man das in der Praxis vieler Programmiersprachen und -umgebungen nur durch eine ausgewogene Kombination von eingängigem Code und hilfreichen Kommentaren erreichen kann.

Ok, das klingt vielleicht zu abstrakt, deswegen ein Beispiel. Ich bin vor ein paar Tagen über diese Quellcodeschnipsel gestolpert. Dort werden zwei Programmiervarianten für ein Problem verglichen. Zum einen eine recht funktionale Variante, zum anderen eine imperative Variante.

Ohne jetzt die zugrundeliegende Aufgabe zu kennen: Auf den ersten Blick erscheinen mir beide Varianten ziemlich komplex. Wenn ich mich in die Materie einarbeite, würde ich aber vermutlich die erste Version für "ästhetischer" halten, weil sie alle relevanten Schritte zu einem umfangreichen Ausdruck kombiniert, anstatt sie in mehrere abgehackte Einzelschritte zu zerlegen, deren Zusammenhang man erst mühsam wieder herstellen muss.

Ich mochte beide Varianten für den Problemfall nicht und bastelte schnell aus Spaß an der Freud' eine eigene Variante.

Auf den ersten Blick fällt es mir bei der Variante noch schwerer, mich darin zurechtzufinden. Möglich, dass das nach einer kurzen Einarbeitung anders aussieht.

• Anonyme Lambdas ...

Was soll das sein? Den Begriff habe ich noch nie gehört.

Ideal wäre eine Macro, selbst wenn es nur einmal genutzt wird, aber Macros sind abseits von Lisp-Dialekten leider Mangelware.

In C sind sie durchaus üblich.

• Imperativer Stil hat den Vorteil, bei frühen Bedingungserfüllungen short-circuiting zu betreiben, ohne groß unnötigerweise Daten zu erzeugen.

Das ist sicher ein Vorzug.

Auch bin ich zunehmend skeptischer gegenüber mehreren Ausstiegspunkten aus einer Funktion.

Ich nicht, im Gegenteil: Sobald das Ergebnis einer Funktion feststeht, beende ich sie. Ich finde das übersichtlicher, als "pro forma" das schon feststehende Ergebnis bis zum Ende der Funktion durchzureichen.

pattern matching/guards aus Haskell ... anonyme Lambda ... lazy list

Wenn du nicht so sehr mit extrem spezifischen Buzzwords um dich werfen würdest, könnte man vielleicht sogar verstehen, was du sagen möchtest.

Und das ist letztendlich der Grund für dieses Posting: Ich interessiere mich in letzter Zeit für eine Ästhetik/Lesbarkeit/Intuitive Klarheit von Code. Nicht auf einer Ebene von Microsyntax, auch nicht auf der Ebene von Objekthierarchien, sondern irgendwo dazwischen, bei den Algorithmen. Wie man es schafft, seine abstrakte Vorstellung möglichst gut, tlw. deklarativ zu verdeutlichen.

Meiner Ansicht nach erreicht man das am besten, indem man versucht, den natürlichen Gedankengang so gut wie möglich mit den Strukturen der jeweiligen Programmiersprache abzubilden. Das ist allerdings keine Einbahnstraße: Intensive Beschäftigung mit einer bestimmten Programmiermethode führt dazu, dass man selbst anfängt, so zu denken, und das als "normal und intuitiv" empfindet.

Das finde ich aber gar nicht so schlimm, denn Programmieren ist einerseits eine Art Handwerk, das man erlernen und üben kann, andererseits aber auch eine Art Kunst, für die man eine gewisse Begabung mitbringen sollte. Und so muss "ästhetischer", gut verständlicher Programmcode auch nicht für jeden Laien verständlich sein, sondern für jemanden, der selbst die Grundzüge der Programmierung, der Programmiersprache und des individuellen Problems kennt.

Und Ihr, die ihr dieses lange Posting überstanden habt, in dem ich versuche zu erklären, wonach ich eigentlich suche, wisst Ihr da vielleicht etwas interessantes? Bücher, Artikel, Postings, Diskussionen?

Leider nein, denn ich fürchte, die Ansichten und Meinungen dazu sind sehr zahlreich und kontrovers.

Ciao,
 Martin