Was ist für euch "Beautiful Code"?

[Thomas Darimont]

Hallo,

vor ein paar Monaten hab ich mir das Buch "Beautiful Code":
http://www.amazon.de/Beautiful-Code-Theory-Practice-OReilly/dp/0596510047 gekauft. Darin beschreiben 33 namhafte Autoren anhand von kleinen mehr oder weniger leicht verständlichen Beispielen was für sie "Beautiful Code" ausmacht.

Auch wenn mich die vorgestellten Probleme nicht wirklich vom Hocker gehauen haben fannd ich doch sehr interessant das fast jedes Beispiel in einer anderen Programmiersprache vorgestellt wird. So kann man sich relativ schnell einen Einblick in eine "fremde" Programmiersprache verschaffen ;-)

Während der Lektüre dieses Buchs hab ich mich dann mal selbst gefragt, was macht für mich persönlich Code schön.

Mein Ergebnis war, dass Code für mich dann schön ist wenn er so klar ist, dass man eigentlich keinerlei Kommentare braucht um zu verstehen was da passiert. Im grunde genommen rede ich hier von sowas wie einer intuitiven API bei der man schon vom bloßen draufschauen auf die Packages/Module Klassen/Interfaces und Methoden weis wozu diese da sind ohne gleich alles in der Dokumentation nachlesen zu können. Ein Weg wie man solche APIs bauen kann sind Fluent Interfaces: http://en.wikipedia.org/wiki/Fluent_interface hier noch weitere Beispiele dazu:
http://martinfowler.com/bliki/FluentInterface.html
http://www.tutorials.de/forum/java/...-aspectj-style-aop-pointcut-definitionen.html

Darüber hinaus nene ich eine API zusätzlich elegant wenn sie so mächtig (Feature complete) ist, dass diese die Anforderungen an sie erfüllt
und gleichzeitig auf das wesentliche reduziert ist, dass man nichts mehr wegnehmen kann.

Versteht mich nicht falsch-Ich finde gute Dokumentation ist sehr wichtig-aber wenn die APIs zusätzlich noch intuitiv zu benutzen sind findet man sich viel schneller / besser damit zurecht.

Wie seht ihr das?

Gruß Tom

 

[DarthShader]

Ich unterstütze Deine Punkte - auch für mich sollte eine API nach Außen hin klar semantisch sein.

Ich kenne Beautiful Code - habe das Buch zwar nicht gelesen, aber verfolge regelmäßig den Blog dazu. Fluent Interfaces finde ich ne nette Idee, ich stehe dem aber Kritisch gegenüber. Soetwas setzt sich höchstens für Skriptsprachen oder sowas wie Testing Frameworks durch (siehe JUnit 4).

Viele finden ja auch sehr simplen und fast schon "kryptischen" code schön, da man ihn - das Wissen vorausgesetzt - sehr schnell lesen (und schreiben) kann. Aber das ist eben wie LaTeX, wunderbar wenn man es kann, aber wenn man es nur sehr selten nutzt, wird man mit einer wiederholten Einarbeitung konfrontiert.

Ich persönlich mag das Prinzip der Convecntion over Configuration (http://en.wikipedia.org/wiki/Convention_over_Configuration) und zwar nicht nur im Code, sondern auch z.B. im Projektmanagement. Man könnte auch "Konvention über Bürokratie" sagen Allerdings funktioniert das nur unter bestimmten Umständen. Ausschlaggebend dafür ist eben das Team selbst, vor allem sog. "Softskills" ... aber ich schweife ab

Manches mal finde ich Code auch sehr schön, der einfach raffiniert ist. Das muss weder leserlich noch Informativ sein - einfach die Tatsache, dass ein Problem sehr "smart" gelöst wurde, finde ich oft "beautiful"

Alles eine Sache der Perspektive - mein letztes Beispiel fußt natürlich nicht auf große Frameworks bzw. große Projekte, dort sehe ich es wieder so, wie Du anfangs geschrieben hast (klare, aussagekräftige API).


Abschließen würde ich wohl sagen, dass Code immer nur in einem bestimmten Kontext und unter bestimmten Anforderungen "beautiful" ist. Auch wenn der Kontext mal der persönliche Geschmack ist ;-)

 

[Dörti.Hermi]

Hallo,

also ich versteh zwar nichts von APU und dgl, aber für mich wirkt ein Code "schön", wenn er deutlich strukturiert ist. Was man hier manchmal im Forum von manchen Usern geliefert bekommt - ohne diese persönlich angreigen zu wollen - ist das Grauen. Da laufen mir manchmal die Tränen runter

Wenn ein Programm wirklich ohne Kommentare auskommt, ist das natürlich absolut top, aber ich finde, dass ein Programm mit (wenigen & sinnvollen) Kommentaren besser auf den Betrachter wirkt, weil die einzelnen Programmteile so noch besser ins Auge springen.

Was ich aber an dieser Stelle sinnlos finde, ist, wenn man zu jeder noch so kleinen Funktion ein Kommentar dazugibt. Dabei verliert der Betrachter viel schneller den Überblick, als ohne diese Kommentare. Sie können zwar bei kleinen Code-Schnipseln wirklich hilfreich sein - ein ganzes Programm damit zu füllen ist aber meiner Meinung nur verwirrend...:suspekt:

So, das war's auch schon wieder

Lg

 

[CSANecromancer]

Ach, ich hatte auch mal Träume von klaren Interfaces, Dokumentation, Case Tests etc. Heutzutage ist für mich Code schon "beautiful", wenn er komplett und compilierbar ist und ich mir nicht erst die Einzelteile eines Projekts aus 30-40 Unterverzeichnissen zusammensuchen muss. Sprechende Variablennamen sind da schon ein zusätzlicher Bonus, den ich allerdings gar nicht mehr erwarte. Ich habe schon Programme mit "x1" bis "x75" hinter mir und die Zusatz"dokumentation" mit der Erläuterung des Variableninhalts war natürlich unauffindbar.
Sourcekommentare? Wenn ich die nicht selber schreibe, dann sind die zu 95% vom Typ

i++; // increment i

In der Theorie mag es tolle und tollste Konzepte geben, wie man Code noch besser, übersichtlicher etc. erstellen kann, doch meine ganz persönliche Erfahrung ist, dass all diese Bemühungen in der Praxis sofort vom Marketing und teils sogar auch der Projektleitung niedergemacht werden. Von ersteren, weil sie ein "Ergebnis" verkaufen, während noch gar kein Produkt fertig ist, letztere weil sie ihre Jobs behalten wollen und dann panisch dem Marketing zustimmen.
Alle "das kann's doch nicht sein"-Sprüche und Verbesserungskonzepte der Welt haben daran nichts geändert.

Wie gesagt: Soweit meine persönliche Erfahrung.

 

[Norbert Eder]

Ich denke hier muss man zwischen zwei Dingen unterscheiden:

1) Frameworks
2) tatsächlicher Sourcecode

Zu den Frameworks:
Hier ist es absolut nebensächlich wie der Code dahinter aussieht (nach außen hin). Ein Framework sollte intuitiv und einfach verwendbar sein. Die Vergabe von Typennamen etc. sollte selbstsprechend sein und den Entwickler ermöglichen, auch ohne Dokumentation zu seinem Ziel zu gelangen. Natürlich sollte dennoch eine Dokumentation vorhanden sein um allfällige tiefergreifende Fragen beantworten zu können. Welcher Ansatz und welche Methodik im Endeffekt dahinter steckt ist zweitrangig. Die obigen Ziele sollten meiner Meinung nach erreicht werden.

Zum tatsächlichen Sourcecode:
Hierzu finde ich die Diskussion bzw. auch die Fragestellung eher esoterischer Natur. Es verhält sich gleich wie das Herantragen einer Beschwerde an 5 Ärzte: das Resultat spiegelt sich in 7 Meinungen wider.

Jeder hat ein anderes Bild von schönem Sourcecode. Ich persönlich finde es wichtig, dass Sourcecode:

• klar strukturiert
• gut dokumentiert
• auf Basis eines Styleguides
• einigermaßen sinnvoll

implementiert ist. Vor allem in größeren Teams besteht natürlich die Gefahr, dass jeder ein anderes Verständnis für schönen Sourcecode mitbringt und andere gar kein Verständnis davon haben und froh sind, wenn sie eine Aufgabe erledigen können und das Teil hinterher auch kompiliert.