Archiv verlassen und diese Seite im Standarddesign anzeigen : Wo findet man eigentlich schönen Code?
Shink
2010-06-11, 21:25:46
Es gibt keine einzige Ingenieursdisziplin, in der nicht die bedeutenden Werke früherer Meister genau unter die Lupe genommen werden. Auch alle angehenden Autoren müssen zunächst viel lesen. Nur die Schreiber von Programmen meinen, dass sie genial sind und nicht den Code von anderen analysieren müssen.
http://www.heise.de/newsticker/meldung/UML-Erfinder-Grady-Booch-zeichnet-duesteres-Bild-der-Softwareentwicklung-1020658.html
Nun ja; klingt so weit ganz logisch wie ich finde.
Was ist das "am schönsten programmierte" (Open Source - sonst macht es ja keinen Spaß) Projekt dass ihr kennt?
Die JDK-Library fällt ja schon mal nicht darunter.
An vielen Apache-Projekten könnte ich auch so einiges nennen das mir nicht gefällt und manche behaupten gar jeder Programmcode den es auf der Welt gibt ist mies.
Gibt es Projekte die das als einen ihrer Hauptziele sehen?
Die Literate Programming Sachen von Donald Knuth sind interessant. Ob der Code wirklich schön ist, ist eine andere Frage. Der Programmierstil an sich ist aber auf jeden Fall sehenswert.
Das Thema als solches finde ich auf jeden Fall interessant und Booch hat da meiner Meinung nach völlig reicht.
Monger
2010-06-11, 22:49:55
Zum Zitat: der Unterschied zwischen Softwareentwicklung und praktisch jeder anderen Ingenieursdisziplin ist, dass man beim Haus- oder Autobau eine Vorstellung davon hat, wo man eigentlich hin will. Häuser haben heute genauso wie vor 4000 Jahren Türen und Fenster, Autos sind in ihrer grundsätzlichen Form seit gut 150 Jahren nahezu unverändert.
Software ändert sich innerhalb eines Entwicklungszyklus vollkommen: angefangen hat man mit einem Rasenmäher, und am Ende hat man eine Schubkarre.
Das geht imho auch nicht anders, denn Softwareentwicklung ist nunmal naturgemäß sehr abstrakt. In dem Moment wo man ein Problem formulieren kann, ist es auch bereits gelöst. Software handelt mehr davon, sich über die Frage klar zu werden, als die Antwort zu finden.
Ich fände es fatal, wenn man an Softwarearchitektur mit der selben Systematik rangehen würde wie an einen Hausbau. Software lebt nunmal, und anders als z.B. in der Architektur sind die Lösungen von vor zehn Jahren nahezu allesamt deutlich schlechter als moderne Architekturen. Die ganze Disziplin ist so jung, dass jeder Laie über bisher unbeantwortete Phänomene stoßen kann.
Was den schönsten Code angeht: was die API angeht, finde ich das JDK echt nicht verkehrt. Ich hab mir die Implementierung nie angesehen, aber das öffentliche Interface (vorallem im Bereich IO und Collections) finde ich enorm gut durchdacht.
Ich hab ein paar Implementierungen im .NET Framework gesehen, die ich sehr schön fand... aber ich hab auch ehrlich gesagt zu wenig Code gesehen, um mir da ein Urteil zu bilden. Ich weiß nur, dass ich schon mehr als genug hässlichen Code gesehen habe! :ugly:
Ich fände es fatal, wenn man an Softwarearchitektur mit der selben Systematik rangehen würde wie an einen Hausbau. Software lebt nunmal, und anders als z.B. in der Architektur sind die Lösungen von vor zehn Jahren nahezu allesamt deutlich schlechter als moderne Architekturen. Die ganze Disziplin ist so jung, dass jeder Laie über bisher unbeantwortete Phänomene stoßen kann.
Das geht imho am Thema vorbei. Architektur ist das eine - klar. Hier geht es aber mehr um Design im Kleinen und dem darunterliegenden Code. Dort haben sich gerade in den letzten Jahren Normen (noch keine DIN, aber klare Muster und Richtlinien) ergeben, die sich aber gerade die "alten Hasen" oder junge Besserwisser meistens nicht aneignen (wollen).
Zum Thema: Schöner Code? Es kann eigentlich nur Code schön sein, der tausendfach geprüft und trotzdem anerkannt ist -> Linux-Kernel. :)
Ich persönlich fand den Code (hab mich im TCP/IP-Stack umgesehen) sehr schön. Spärlich kommentiert - wie immer - aber trotzdem verständlich nach relativ kurzer Einarbeitung. Und ein durchgängiger und sinnvoller Schreibstil.
Wobei speziell hier das Thema Design-Patterns fehl am Platz is. Wo RFCs anfangen hört die Kreativität zwangsläufig auf. ;) (was nicht negativ gemeint ist)
Ganon
2010-06-11, 23:48:17
Linux-Kernel. :)
Garantiert nicht ;) "dunno why this works" und so ein Kram sprechen da eine andere Sprache. Funktionieren tut der Code meist, aber schön ist er nicht.
Man könnte aber mal bei FreeBSD und OpenBSD gucken. Die achten eigentlich immer darauf das der eigene Code relativ gut dokumentiert und eine bestimmte Qualität hat. Zumindest hatte ich bisher nie große Probleme dort etwas nicht zu verstehen.
Achja, es ist auch eine Fehlannahme, dass OpenSource-Code "1000fach geprüft" ist. Solange ein bestimmter Code keinen Stress macht und wie erwartet funktioniert, wird er auch nicht geprüft. So verstecken sich gerne über Jahrzehnte Sicherheitslücken.
SavageX
2010-06-12, 10:46:00
Schöner Code? Es kann eigentlich nur Code schön sein, der tausendfach geprüft und trotzdem anerkannt ist -> Linux-Kernel. :)
Da muss man schon spezifischer werden: Der Linux-Kernel ist ja ein ziemlich großer Haufen Code. Wenn man aber vielleicht all die Treiber ausblendet (das ist ja häufig "nur" gerätespezifische Bitschubserei, von der man wenig Generelles lernen kann) - vielleicht bleibt ja ein... err... "schöner" Scheduler übrig oder ein "schönes" Dateisystem oder ein "schöner" Allocator?
Gibt es Projekte die das als einen ihrer Hauptziele sehen?
http://clean-code-developer.de/
registrierter Gast
2010-06-12, 15:21:39
Ich weiß nicht, ob der Code schön ist, aber ich habe mir mal Teile die Sourcen des Spring Frameworks ansehen müssen und fand ihn leserlich, mehr als ausreichend kommentiert, gut strukturiert, nachvollziehbar, fortgeschritten entwickelt und war durchgehend auf gleiche Art und Weise formattiert.
Bestimmt gibt es bessere, aber seitdem ich da mal reingeschaut habe, benutze ich Spring umso lieber.
Shink
2010-06-12, 17:00:32
Software ändert sich innerhalb eines Entwicklungszyklus vollkommen: angefangen hat man mit einem Rasenmäher, und am Ende hat man eine Schubkarre.
Was ändert das denn? Deswegen soll die Schubkarre trotzdem nicht so aussehen dass jeder weiß dass es ursprünglich ein Rasenmäher war.
Software lebt nunmal, und anders als z.B. in der Architektur sind die Lösungen von vor zehn Jahren nahezu allesamt deutlich schlechter als moderne Architekturen.
Naja. Ich finde eher viel zu oft lebt die Software-Architektur davon dass jemand Buzzwords für cool erklärt und sich Leute daran halten weil es sich verkauft. Bevor die Mehrfachvererbung als sinnvoll und später verpönt erklärt wurde gab es irgendwann eine Zeit in der man sie nicht verwendete. Was soll daran schlechter gewesen sein als heute?
Was den schönsten Code angeht: was die API angeht, finde ich das JDK echt nicht verkehrt.
Ich eigentlich schon. Swing-Komponenten implementieren Serializable obwohl sie nicht serialisierbar sind, Date und Calendar sind ein ziemliches Schlachtfest bei dem man sicher nicht intuitiv versteht was die Methoden tun (was passiert z.B. bei setYear(2010) bei einem Date-Objekt oder setDayOfMonth(30) in einem Calendar-Objekt bei dem gerade Februar ist?)
Was passiert wenn man Swing- und AWT- Komponenten (die ja sich ja sogar voneinander ableiten) im selben GUI verwendet?
Das API von SWT finde ich im direkten Vergleich wirklich interessant da es sich z.B. großteils nicht einmal auf Vererbung verlässt. Aber dann schaut man sich die Implementierung an und sieht Methoden in denen in 20 LOC Integer-Flags bitgeshiftet werden. So stell ich mir moderne Programmierung auch nicht gerade vor:freak:
zu clean-code-developer: Die Ideen und Prinzipien klingen ja OK. Aber wenn die auf der Hauptseite auf das Buch "Clean Code" verweisen...
Nein: Ich finde nicht dass Algorithmen dadurch schöner werden dadurch dass man sie in prinzipiell unnötige Methoden aufteilt und die eigentliche Methode dann wie englische Prosa aussieht. Naja, außer in Assembler vielleicht.
Tiamat
2010-06-12, 19:18:56
Man könnte ja eine Art Zertifizierung daraus machen. Natürlich gibt es immer
Termine und einzuhaltende Fristen, aber der Code entsteht ja während des Projekts und da trägt jeder Entwickler dazu bei. Wie jeder weiß, hat jeder so seinen eigenen Programmierstil und es sind halt meistens welche dabei, die ihre Teile ziemlich individuell hardcoden :D. Genau diese Stellen erweisen sich später bei einer Erweiterung des Codes als Frickelware.
Spontan würden mir zig Dinge einfallen, die noch dafür sorgen, dass der Code wie dahingehunzt aussieht, aber da müsste sich eigentlich die Qualitätssicherung einschalten. Blöd nur, wenn gar keine QS existiert ;)
Gruß
Tiamat
kloffy
2010-06-13, 00:36:03
Leider nur noch über archive.org erreichbar: Beautiful Code Blog (http://web.archive.org/web/20080605173704/http://beautifulcode.oreillynet.com/). Dort gab es immer mal wieder recht interessante Beiträge.
Yavion
2010-06-13, 07:00:09
Schwierig da einen Konsens zu finden.
Code ist dann schön, wenn der Mensch der den Code liest, als schön empfindet.
Vermutlich ist es einfacher, sich darüber einig zu sein, was nicht schön ist.
"The Art of writing Computer Programs" von Don Knuth
und
http://mitpress.mit.edu/sicp/
http://www.htdp.org/2003-09-26/
Das sind einfach zeitlose Klassiker, die im Gegensatz z.B. zu irgendwelchen Sourcen, über Trends und Paradigmenwechsel erhaben sind.
Wenn es dann doch unbedingt Sourcen sein sollen, würde ich mir z.B. die von TeX angucken...
http://www.heise.de/newsticker/meldung/UML-Erfinder-Grady-Booch-zeichnet-duesteres-Bild-der-Softwareentwicklung-1020658.html
Nun ja; klingt so weit ganz logisch wie ich finde.
Was ist das "am schönsten programmierte" (Open Source - sonst macht es ja keinen Spaß) Projekt dass ihr kennt?
Mein hello-world.c
Einfach, schön strukturiert, bugfrei und gut durchschaubar.
Yavion
2010-06-13, 09:02:54
Ich finde Hello World in so ziemlich jeder Sprache hässlich. ^^
tomvos
2010-06-13, 11:49:29
Viele Sprachen/Frameworks, insb. die objektorientierten Sprachen, haben meist auch eine Beschreibung der Coding Guidelines.
Java (http://java.sun.com/docs/codeconv/)
Objective-C (http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html)
.Net (http://msdn.microsoft.com/en-us/library/czefa0ke(v=VS.71).aspx)
Selbst wenn man den Code nur für sich selbst oder ein sehr kleines Team entwickelt, ist es ratsam, diese Empfehlungen einzuhalten.
Meiner Ansicht nach ist der ehrlichste Test, ob der eigene Code schön ist, folgendes:
Schau in deinen eigenen Code, den du vor einem Jahr geschrieben hast und seitdem nicht mehr bearbeitet hast.
Falls du dann ohne viel Einarbeitung eine mittlere Änderung vornehmen kannst und das Programm dir nicht mit unerwarteten Fehlern um die Ohren fliegt, dann hast du vermutlich schönen Code fabriziert.
zu clean-code-developer: Die Ideen und Prinzipien klingen ja OK. Aber wenn die auf der Hauptseite auf das Buch "Clean Code" verweisen...
Nein: Ich finde nicht dass Algorithmen dadurch schöner werden dadurch dass man sie in prinzipiell unnötige Methoden aufteilt und die eigentliche Methode dann wie englische Prosa aussieht. Naja, außer in Assembler vielleicht.
Das ist wie immer bei solchen Vorschlägen. Man hat ein extrem übertriebenes Konstrukt und man sucht sich einige Ideen raus, die für einen persönlich wichtig sind.
Ich finde Hello World in so ziemlich jeder Sprache hässlich. ^^
Dann findest du keine Sprache und kein Programm schön.
Yavion
2010-06-13, 16:49:16
Es ist eher eine gewisse Abneigung gegen wertloses Wirken.
Nasenbaer
2010-06-20, 13:39:03
Ich fände es fatal, wenn man an Softwarearchitektur mit der selben Systematik rangehen würde wie an einen Hausbau. Software lebt nunmal, und anders als z.B. in der Architektur sind die Lösungen von vor zehn Jahren nahezu allesamt deutlich schlechter als moderne Architekturen. Die ganze Disziplin ist so jung, dass jeder Laie über bisher unbeantwortete Phänomene stoßen kann.
Also sind dir "Gang of 4" Idioten, weil sie einem mit der Niederschreibung sinnvoller Design Pattern, den Spaß genommen haben? Also ich finde Systematik ist durchaus sinnvoll.
Das Problem ist meist, dass man ein konkretes Problem lösen soll und dabei nicht die Zeit hat wiederverwendbaren Code zu schreiben. Viele Bausteine könnte man in anderen Projekten wiederverwenden und damit gewissermaßen einen Baukasten aufstellen aus dem man sich bedient - jedenfalls für viele grundlegende Probleme. Bspw. nimmt man fürs logging log4cxx, für die grafische Ausgabe D3D und für Webseitenrendering z.B. Webkit. Und es ist ja richtig sich nicht zu sehr mit der Funktionsweise von diesen APIs zubeschäftigen sondern mit dessen Schnittstellen. Ein Maurer ist auch egal wie der Ziegel gebrannt wurde oder oder der Motor im Kran funktioniert - hauptsache er weiß sie zu nutzen.
Also solche Bausteine werden schon seit Ewigkeiten benutzt und deshalb finde ich das Zitat natürlich auch nicht so zutreffend. Sicher gibt es "Experten", die sich ihren eigenen Queue schreiben, weil sie die C++ Standard Library nicht zu nutzen wissen aber das trifft doch eher auf Anfänger zu.
roadfragger
2010-06-21, 13:30:00
http://clean-code-developer.de/
Super Zusammenfassung sehr wichtiger Coding-Grundsätze. Danke schön für diesen Link. Die Seite werde ich mal durchackern. (y)
Shink
2010-06-21, 14:00:22
Das Problem ist meist, dass man ein konkretes Problem lösen soll und dabei nicht die Zeit hat wiederverwendbaren Code zu schreiben.
Naja, Wiederverwendbarkeit als Selbstzweck ist weder finanziell sinnvoll noch kann sie funktionieren.
registrierter Gast
2010-06-22, 01:15:16
Das Problem ist meist, dass man ein konkretes Problem lösen soll und dabei nicht die Zeit hat wiederverwendbaren Code zu schreiben. Viele Bausteine könnte man in anderen Projekten wiederverwenden und damit gewissermaßen einen Baukasten aufstellen aus dem man sich bedient - jedenfalls für viele grundlegende Probleme. [..]
Mit wachsender Entwicklererfahrung programmiert man automatisch in solchen Baukästen und denkt generell daran, wie man Bausteine möglichst generisch zusammenbastelt, damit sie auch späteren Anforderungen gerecht werden können.
Aber ja, bei den Bausteinen funktioniert dies nicht immer, weil die Anforderungen zu stark schwanken können. Man bekommt jedoch ein gewisses Feeling dafür, wo es hingeht. Do you feel me? :freak:
Nasenbaer
2010-06-22, 08:54:26
@Shink
Ich meinte auch nicht als Selbstzweckung, sondern in weiser Voraussicht für zukünftiges. Und es gibt halt vieles, dass man durch aus wiederverwehrten kann. Bei manch einer Stelle kanns auch unsinnig sein, keine Frage.
@reg. Gast
Sicher versucht man mit wachsender Erfahrung vorausschauend zu handeln aber gerade wenn man sich mit neuen Themen auseinandersetzt, dann übersieht man immer mal irgendwas, das, wenn man es gut machen wollte, ein Refactoring vertragen könnte aber dafür ist, so habe ich das bei den Projekten an denen ich mitarbeiten durfte, zeitlich nicht immer drin.
Als Hobby-Progger hat man keine Deadline aber in ner Firma interessiert es nen fachfremden Chef nicht ob man die Prinzipien von OOP gut umgesetzt hat oder nicht und mit dem Argument der Wartbarkeit zu kommen klappt auch nicht immer.
BeeRockxs
2010-06-22, 15:36:13
Was passiert wenn man Swing- und AWT- Komponenten (die ja sich ja sogar voneinander ableiten) im selben GUI verwendet?
Das ist inzwischen kein Problem mehr.
registrierter Gast
2010-06-24, 02:21:02
@reg. Gast
Sicher versucht man mit wachsender Erfahrung vorausschauend zu handeln aber gerade wenn man sich mit neuen Themen auseinandersetzt, dann übersieht man immer mal irgendwas, das, wenn man es gut machen wollte, ein Refactoring vertragen könnte aber dafür ist, so habe ich das bei den Projekten an denen ich mitarbeiten durfte, zeitlich nicht immer drin.
Als Hobby-Progger hat man keine Deadline aber in ner Firma interessiert es nen fachfremden Chef nicht ob man die Prinzipien von OOP gut umgesetzt hat oder nicht und mit dem Argument der Wartbarkeit zu kommen klappt auch nicht immer.
Das definitiv. Als die Firma, in der ich arbeite, ein neues CMS bekam und man anfing, alles darauf umzustellen, gab es viele tolle neue Ideen. Die wurden dann natürlich auch umgesetzt und als man damit fertig war, merkte man dann: "Ach, ist ja doch nicht so toll. Anders ist es bestimmt besser...". Erst circa anderthalb Jahre später kam man dann zu einem Punkt mit ausreichendem Entwicklungsgrad und genug Erfahrung, dass man vorher sagen konnte, welche Feature sich lohnen und wie man sie flexibel umsetzt.
Bis dahin hatte man allerdings viel Schrott angehäuft. Wir gehen davon aus, dass ca. ein drittel unserer Klassen wegfallen würden, würde man unseren ganzen CMS Aufsatz neu entwickeln. Zudem führen manche architektonische Entscheidungen aus der Vergangenheit nun zu seltsamen Strukturen, auf die man leider aufbauen muss.
Ja, da hast du dann leider Recht und Zeit bleibt bei solch großen Projekten nicht, um daran groß etwas zu ändern.
Bei unseren kleineren Projekten aber, zu denen neue Funktionen hinzugefügt werden sollen, gebe ich mit Absicht eine längere Entwicklungszeit an und nutze die zusätzliche Zeit für umfangreiches Refactoring. Das muss einfach sein. :freak:
Nasenbaer
2010-06-24, 08:44:04
Das definitiv. Als die Firma, in der ich arbeite, ein neues CMS bekam und man anfing, alles darauf umzustellen, gab es viele tolle neue Ideen. Die wurden dann natürlich auch umgesetzt und als man damit fertig war, merkte man dann: "Ach, ist ja doch nicht so toll. Anders ist es bestimmt besser...". Erst circa anderthalb Jahre später kam man dann zu einem Punkt mit ausreichendem Entwicklungsgrad und genug Erfahrung, dass man vorher sagen konnte, welche Feature sich lohnen und wie man sie flexibel umsetzt.
Bis dahin hatte man allerdings viel Schrott angehäuft. Wir gehen davon aus, dass ca. ein drittel unserer Klassen wegfallen würden, würde man unseren ganzen CMS Aufsatz neu entwickeln. Zudem führen manche architektonische Entscheidungen aus der Vergangenheit nun zu seltsamen Strukturen, auf die man leider aufbauen muss.
Ja, da hast du dann leider Recht und Zeit bleibt bei solch großen Projekten nicht, um daran groß etwas zu ändern.
Bei unseren kleineren Projekten aber, zu denen neue Funktionen hinzugefügt werden sollen, gebe ich mit Absicht eine längere Entwicklungszeit an und nutze die zusätzliche Zeit für umfangreiches Refactoring. Das muss einfach sein. :freak:
Tja so ist das leider. Ich sehs ja auch an meiner Studienarbeit. Ich würde so manches anders machen und noch dies oder jenes Feature einbauen wollen aber die Zeit rennt mir so langsam davon - schreiben muss ich ja leider auch noch ein paar *ggg* Sätze dazu.
Kann sich ja nicht jeder soviel Zeit lassen wie 3DRealms. ^^
Shink
2010-06-24, 08:47:07
Das ist inzwischen kein Problem mehr.
Nö, Problem war es glaub ich noch nie. Man sieht aber dass gemischt wurde.
Wenn ich schönen Code sehen will, schaue ich meinen eigenen an. Aber nicht denen meiner Kollegen ;D
Yavion
2010-06-24, 20:49:37
Wenn ich schönen Code sehen will, schaue ich meinen eigenen an. Aber nicht denen meiner Kollegen ;D
Wenn Dir Dein Code auch nach ein paar Monaten noch gut gefällt, war er vermutlich tatsächlich nicht absolut schlecht. :wink:
Es kann niemals schöner Code entstehen. Der Mensch sieht Schönheit in der Semantik nicht in der Syntaktik.
Erst wenn Compiler Semantik, ja sogar Ausnahmen von Regeln, das diese beweist, versteht und damit umgehen kann werden wir "schönen" Code sehen.
Code schreiben ist die Orthografie. Schreibkunst ist was Anderes. Wuthering Heights von Emily Brontë ist schön. Nicht der Linux Kernel Code.
Die Kunst eines Kernel Programmieres hat vielleicht diesselbe Gestaltungshöhe wie ein gutes Buch. Aber: Das Buch wurde von Menschen für Menschen geschrieben. Der Code aber für einen Compiler.
Da bleibt kein Raum für Dreck, Redundanzen, Unterlassungen, absichtliche Fehler, Interpretationsspielraum usw.. Es bleiben auch keine offenen Fragen zurück für die Vorstellungskraft. Dies ist genau die Definition eines Bugs, eines Softwarefehlers.
Yavion
2010-06-25, 01:33:06
Es kann niemals schöner Code entstehen. Der Mensch sieht Schönheit in der Semantik nicht in der Syntaktik.
Erst wenn Compiler Semantik, ja sogar Ausnahmen von Regeln, das diese beweist, versteht und damit umgehen kann werden wir "schönen" Code sehen.
Code schreiben ist die Orthografie. Schreibkunst ist was Anderes. Wuthering Heights von Emily Brontë ist schön. Nicht der Linux Kernel Code.
Die Kunst eines Kernel Programmieres hat vielleicht diesselbe Gestaltungshöhe wie ein gutes Buch. Aber: Das Buch wurde von Menschen für Menschen geschrieben. Der Code aber für einen Compiler.
Da bleibt kein Raum für Dreck, Redundanzen, Unterlassungen, absichtliche Fehler, Interpretationsspielraum usw.. Es bleiben auch keine offenen Fragen zurück für die Vorstellungskraft. Dies ist genau die Definition eines Bugs, eines Softwarefehlers.
Die Betrachtung finde ich, wenn auch verständlich, vielleicht etwas einseitig. Genauso wie sich in einer sauber laufenden Maschine Schönheit findet, so auch in einem Programm, welches sauber und offensichtlich fehlerfrei entwickelt wurde. Es ist die Klarheit der Gedanken, die die Schönheit ausmacht. Das ist die Schönheit eines mathematischen Beweises, einer logischen Schlussfolgerung, einer neuen Erkenntnis.
Die Schönheit einer Idee, die durch erwiesene Transformationsregeln zu einem Computerprogramm wird, das genau diese Idee umsetzt.
Dazu fällt mir ein m.E. sehr empfehlenswertes Buch ein. Ich bin mal so frei und zitiere Wikipedia dazu:
Zen und die Kunst ein Motorrad zu warten (Originaltitel: Zen and the Art of Motorcycle Maintenance), Robert M. Pirsig 1974
"(..)
Zur Verdeutlichung und Illustration des Qualitätsbegriffs verwendet Pirsig das Beispiel eines Güterzuges.[8] An diesem Beispiel lassen sich zwei Betrachtungsweisen unterscheiden: (1) der Blick auf den Zug, in dem dieser als ein statisches Gebilde aus Lokomotive und einzelnen Waggons erscheint, wie auf einer Fotografie; (2) der Blick auf den Zug, in dem dieser als ein dynamisches Gebilde erscheint, das fährt und dabei Strecke zurücklegt.
Es handelt sich um zwei Arten und Weisen, dasselbe zu betrachten. In der ersten Betrachtungsweise ist der Zug in Form von Einzelteilen behandelt. Pirsig nennt das Resultat dieser Betrachtungsweise „klassisches Wissen“ oder „klassische Qualität“. In der zweiten Betrachtungsweise ist der Zug in Bewegung betrachtet, und dabei fokussiert Pirsig genau auf den vordersten Teil, den er als „Leitkante der Lokomotive“ bezeichnet. Das Resultat dieser zweiten Betrachtungsweise nennt Pirsig „romantisches Wissen“ oder „romantische Qualität“.
Mit Hilfe der zweiten Betrachtungsweise verdeutlicht Pirsig das, was er unter „Qualität“ versteht. Er bezeichnet das Gleis, auf dem der Zug fährt, als „Qualitätsgleis“. Die Perspektive ist auf die vorderste Seite des Zuges und auf die Bewegung verschoben. Aus dieser Perspektive ist das Gleis und sein weiterer Verlauf nicht (oder nur sehr wenig) einsehbar. Anders als in der ersten („klassischen“) Betrachtungsweise, in der ein Zug auf einem festgelegten Gleis fährt, ist das Gleis der zweiten („romantischen“) Sichtweise nicht vorher festgelegt. Für den Beobachter an der Leitkante des Zuges entsteht das Gleis mitsamt des Zuges im Moment des Fahrens. Einteilungen der Wahrnehmung in einen Zug mit einzelnen Waggons, der einem Gleisverlauf folgt, entstehen gegenüber dieser Sichtweise erst später. Dazu muss der Beobachter sich von der Vorderkante des Zuges entfernen.(..)"
Capt'N Coax
2010-06-25, 10:10:54
'Schöner' Code ist, wenn man anhand der Benennung der Elemente und anhand sinnvoller Kommentare Klassenübergreifend die Zusammenhänge erkennen kann. Und wenn Probleme nicht umständlicher gelöst sind als nötig.
Daraus ergibt sich meiner Meinung die einzige wahre Erleichterung für den Programmierer. Selbst der intensive Einsatz von Designpatterns mag zwar "schön" sein, erschwert aber das Verständnis enorm (Listener Prinzipien und lose Kopplungen machen das Debugging nicht einfacher).
Das größte Problem ist meiner Meinung noch immer, dass der Software Entwickung wirklich sinnvolle Tools fehlen und Programmiersprachen unabhängig von Guis entstehen. Ebenfalls ist mir die Trennung von Code und Kommentaren suspekt, solange der Code sich nicht selbst erklären kann. JavaDoc und Konsorten reichen nicht, weil sie zwar im selben Text stehen, jedoch keinerlei Beziehung zueinander haben (Abgesehen von den Tags).
Es gibt einen Haufen Tools und Bestrebungen, Code verständlich zu machen (UML etc.), aber ich kenne wirklich KEINE Entwicklungsumgebung, die dies grundsätzlich und inherent VORRAUSETZT. Aber wie gesagt, möglicherweise muss schon die Sprache dahingehend erweitert/entwickelt werden.
Monger
2010-06-25, 23:08:40
Schöner Code ist für mich, wenn mit einem Blick erfassbar ist, was Methode XY tut. Analog dazu: eine gute API ist eine, die man benutzen kann ohne irgendeine Dokumentation zu lesen und ohne dass man auf Trial & Error (sprich: Debuggen) zurückgreifen muss.
In objektorientierten Sprachen verschwimmt mMn diese Grenze. Die Implementierung einer Methode ist dort meistens eher nebensächlich, bzw. deren Syntax hängt ganz wesentlich von dem öffentlichen Interface der verwendeten Klassen ab. Und da es dann dort eben beliebig viele Wege zum Ziel gibt, ist ein gescheites API Design mehr Kunst als Wissenschaft.
Konkretes Beispiel: öffentlicher Konstruktor - ja oder nein? Kommt auf den Fall an: wenn man keinen oder nur einen Parameter hat der dringend zur Erzeugung benötigt wird, ist möglicherweise ein normaler Konstruktor für viele Entwickler intuitiver. Wenn der Konstruktor komplexer ist, oder es sogar mehrere Erzeugungswege gibt die sich massiv unterscheiden, ist eventuell ein Factory-Pattern verständlicher. Und wenn es sehr viele optionale Parameter gibt, bietet sich eventuell ein Builder Objekt an.
Man kann nicht rational erklären, was da die beste Lösung ist. Man muss einfach mal ein paar Anwendungsbeispiele damit schreiben, und dann schauen was sich am flüssigsten runterschreibt.
Deshalb mag ich diesen Formalismus mit den Design Patterns auch nicht - als ob Code automatisch besser wird, je mehr Patterns man in ihn reinstopft.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.