|
|
|
Durchschnittliche Kundenbewertung
Sagen Sie Ihre Meinung zu diesem Artikel
|
|
|
Die hilfreichste positive Rezension
Die hilfreichste negative Rezension
15 von 17 Kunden fanden die folgende Rezension hilfreich:
Programming does not have to be painful
The "Pragmatic Programmer" gives you the philosophy for writing better code. "Clean Code" gives you the details of exactly how to do it. This is a great read for programmers who take their craft seriously and who want to write objectively better code (hey, I *do*). It is a great reference, too, for people whose job is to review and evaluate code (and who might have to...
Vor 12 Monaten von Christian Treber veröffentlicht
|
› Weitere Rezensionen anzeigen: 5 Sterne, 4 Sterne |
 |
24 von 29 Kunden fanden die folgende Rezension hilfreich:
Zu viel des Guten
Von den begeisterten Rezensionen hier geleitet habe ich mir das Buch zugelegt und direkt gelesen. Vorneweg, der Schreibstil ist sehr angenehm, es liest sich hervorragend.
Die Punkte, die im Buch abgearbeitet werden um aufzuzeigen, was guter Code ist und ihn von schlechtem Code trennt decken sich mit meinen Erfahrungen, die Argumentationen, warum etwas...
Vor 2 Monaten von Nicolai Waniek veröffentlicht
|
› Weitere Rezensionen anzeigen: 3 Sterne, 2 Sterne, 1 Sterne |
|
|
15 von 17 Kunden fanden die folgende Rezension hilfreich:
Programming does not have to be painful, 25. November 2008
The "Pragmatic Programmer" gives you the philosophy for writing better code. "Clean Code" gives you the details of exactly how to do it. This is a great read for programmers who take their craft seriously and who want to write objectively better code (hey, I *do*). It is a great reference, too, for people whose job is to review and evaluate code (and who might have to explain *why* some code is good, or not).
I program since 1982, from Texas Instruments pocket calculators to J2EE Java. I have to admit my skills improved pretty slowly and I wish books like these would have been available years ago. And I wish, too, I would have had a bigger interest and insight that every craft can be improved - yes - gasp! - even my own programming style. Your code might work pretty well, but this book will challenge you to "expect more", and "do more". And, yes, it can be done.
If you're good at programming you probably will be familiar with a number of the ideas presented, and you'll find confirmation for practices that you felt were "the right thing to do". And then there will be some more tips to help you to improve your style.
The book summarizes frequent real world observations and resonates with my own experiences slogging through code messed-up beyond recognition by programmers who are just "getting the job done". Understanding, maintaining, and extending existing code should not be as painful as it way to often is. The book gives concrete, usable advice on how to do it better.
I would make both books a "must read" for programmers I hire - if they understand and like what is presented, they couldn't have a better start on better programming.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen
War diese Rezension für Sie hilfreich?
 
|
|
|
|
|
|
24 von 29 Kunden fanden die folgende Rezension hilfreich:
Zu viel des Guten, 5. September 2009
Von den begeisterten Rezensionen hier geleitet habe ich mir das Buch zugelegt und direkt gelesen. Vorneweg, der Schreibstil ist sehr angenehm, es liest sich hervorragend.
Die Punkte, die im Buch abgearbeitet werden um aufzuzeigen, was guter Code ist und ihn von schlechtem Code trennt decken sich mit meinen Erfahrungen, die Argumentationen, warum etwas schlecht ist und besser anders gemacht wird, nachvollziehbar. Bei den meisten Punkten stimme ich überein, doch was mir ziemlich sauer aufgestoßen ist:
* (Zu) Java-zentriert. Das ist an sich ja nicht so schlimm, würde man nicht bei den Argumentationen das ein oder andere mal - jedenfalls aber zu oft während des Buchs - denken, dass das Argument nur in Java Gültigkeit besitzt.
* Martin vergleicht ziemlich am Anfang des Buches die Aufbröselung langer Methoden mit der Normalisierung von Datenbanken. Offenbar hat er aber vergessen, dass sehr oft aber auch wieder Denormalisiert wird, da die weitere Auftrennung den Kontext auseinander reisst. Er hat zwar recht, dass man nach Möglichkeit alles auseinanderbricht, aber er verliert kein Wort darüber, dass man damit oft auch zu viel des Guten erreicht.
* Eine wichtige Grundregel meiner Erfahrung: Algorithmen _nicht_ auseinanderbrechen. Das schreckliche Gegenbeispiel kommt auf Seite 145, in dem Martin Knuths Primzahlencode aus Literate Programming nimmt, nach Java portiert und anschließend nach seinen Methoden refactort. Das Ergebnis ist eine reine Zumutung für das Auge und hat mit Clean Code nichts mehr zu tun. Positiv zu erwähnen ist, dass er die Ausgabe und die Erzeugung getrennt hat. Die Ausgaberoutinen sind sauber und so nachzuvollziehen, wie er es gern hat: Wie ein Stück Prosatext. Aber der Algorithmus als solcher ist nicht mehr zu erkennen. Nicht alles sollte als Prosatext beschrieben werden!
* Leider noch mal der Java Einfluss, aber wer von präzisem, klarem Code spricht, sollte keine Methodennamen verwenden, die länger als 20 Zeichen sind. Das Primzahlbeispiel macht das klar. Eine Methode mit Namen isLeastRelevantMultipleOfNextLargerPrimeFactor sollte nicht von jemandem geschrieben werden der von sich behauptet, sauberen Code zu schreiben... Code-Normalisierung ja, aber bitte nur soweit man keine Algorithmen, die irgendwo anders mathematisch beschrieben und geprüft sind, mit lächerlich anmutenden Funktionsnamen zerstört. Martins Code hat meistens eine gewisse Eleganz, aber die Eleganz in einem wohlgeformten Algorithmus scheint er nicht zu kennen, im Gegenteil, er reisst sie auseinander.
* Leider wird an keiner Stelle im Buch erwähnt, welchen Einfluss die Veränderung des Quellcodes auf die Performance der Software hat. Dass er es mit der Performance in seinem Code nicht all zu ernst nimmt zeigt ein Beispiel, bei dem er einen String zurück gibt, in dem ein Großbuchstabe einen Schalter der auf an steht anzeigt, und einen Kleinbuchstaben, wenn der Schalter aus ist. Normal würde man das über ein Bitfeld machen, und nicht wie er vorschlägt besser mit StringBuffer. Leider lässt der Java Einfluss wieder grüßen.
Ich bin etwas enttäuscht von dem Buch. Bei vielen Stellen im Buch hab ich den Kopf geschüttelt und mir die Frage gestellt, was für ein Schmarrn das ist, was er da macht, da das so einfach nicht in allen Bereichen applikabel ist. Wer viel in Java programmiert wird seine Freude an dem Buch haben und sicher oft mit dem Kopf nicken. Wer unter Clean Code nicht (nur) maximal-aufgebrochene Funktionen mit elendig langen Funktionsnamen versteht wird mit dem Buch nicht glücklich und lediglich seine Vorurteile über Javaprogrammierer bestätigt finden. So jemand schaut sich besser nach anderen Büchern um und reicht das Buch an den fanatischen Javajünger in seinem Freundeskreis weiter ;)
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen
War diese Rezension für Sie hilfreich?
|
|
|
|
|
|
16 von 19 Kunden fanden die folgende Rezension hilfreich:
Endlich einmal aufräumen!, 28. Januar 2009
Eine Frage, die sich früher oder später jeder Softwareentwickler stellt: Wie gut ist mein Quellcode wirklich? Wie kann man den Quellcode anderer bewerten; was ist guter, was ist schlechter Stil?
Wer schon einmal mit fremdem Code zurechtkommen musste könnte sich fragen: "Ist der Code wirklich so schlecht, oder bin ich vielleicht nur zu beschränkt?"
Gibt es harte Kriterien, anhand derer man das herausfinden kann?
Ja, es gibt sie! Dieses Buch stellt diese Kriterien anschaulich und umfassend vor. Es nimmt einem auch ein Stück weit die falsche Ehrfurcht vor allzu verzwicktem Code! Wenn durch kryptische Bezeichner und überlange Funktionen der Sinn des Programms nicht ersichtlich wird, so ist dies ein Makel; auch, wenn der Quellcode nie von mehr als einer Person eingesehen wird.
Erfrischend ist die Einstellung zu Kommentaren: Jeder Kommentar ist ein Anzeichen für das Unvermögen, etwas anschaulich anhand des Codes selber auszudrücken und birgt die Gefahr von Widersprüchen, wenn er bei Änderungen des Codes nicht angepasst wird.
Insgesamt ist dies Buch eine Fundgrube für jeden, der nach sachlich begründeten Richtlinien für eine ordentliche Strukturierung von Quellcode sucht.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen
War diese Rezension für Sie hilfreich?
|
|
|
|
|
|
7 von 8 Kunden fanden die folgende Rezension hilfreich:
Und da ist er wieder der erhobene Zeigefinger, 30. August 2009
Nachdem ich die ersten drei Kapitel gelesen habe möchte ich hier kurz meine Meinung zum besten geben. Das Buch ist gut geschrieben und in verständlichem Englisch gehalten. Es hier und da Karikaturen die das Buch ein wenig auflockern. Die Verarbeitungsqualität ist eher auf unterem Level. Für den Preis kann man auch Hardcover erwarten.
Der Inhalt beschreibt eigentlich auf verständliche Art und Weise warum man Dinge auf eine bestimmte Art und Weise kodieren soll. Dabei schießt der Auto leider weit über das Ziel hinaus. Insbesondere der Abschnitt über Funktionen läßt mich schmunzeln da in diesem ein schlecht geschriebes Beispiellisting komplett zerhackstückt wird und in eine vermeindlich besseren Code verwandelt wurde. Irgendwie scheint dem Autor entfallen zu sein, das sein Quellcode zwar 'sauberer' zu sein scheint aber ebenso schwierig zu lesen ist wie das Ausgangsbeispiel. Man kann an diesem Kapitel deutlich erkennen wie dogmatisch das Buch ist. Grundsätzlich bin ich der Meinung das ein guter Programmierstil mit der Zeit in jedem Programmierer heranreift und diese Art von Büchern nur als Ideengebung für guten Code dienen können. In der Arbeitswelt bleibt für viele nützliche Vorschläge des Buches eh zu wenig Zeit. Der Geist ist willig, aber die Zeit ist knapp!
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen
War diese Rezension für Sie hilfreich?
|
|
|
|
|
|
11 von 14 Kunden fanden die folgende Rezension hilfreich:
A Revelation/Eine Offenbarung, 20. Mai 2009
(German Review below)
I think I should excuse for hyping this book, but I'm completely enthusiastic about it. It's the first textbook that left me sorry it's over. There may be various reasons. It seems I'm a nerd. I love programming and I inherited incredibly rotten C-Code at work.
As newbie to software developement I expected to learn from professionals at work. Instead I got code, that was written from at least 3 different Authors with differend minds about the programming style. The only thing they seemed to agree on was: no comments, no automated tests, no descriptive names and to avoid function calls and do everything inline. Even though the book uses only Java, I could easily transfer the advice to my C code. Since I started using suggestions from this book my code became more readable and programming became more fun. I spend more time programming and less time browsing unreadable code.
The book is easily to read. It gives sound and clear advice without beeing to scholarly. It focuses on describing many screws you can use to tune the readability of your code. The authors give reason for almost everything instead of blindly obtruding their preferences. This is a definite 5 Stars.
Ich muss mich entschuldigen, dass ich das Buch so hype, aber ich bin total begeistert. Es ist das erste Lehrbuch, bei dem ich bedauert habe, als ich damit fertig war. Das mag an verschiedenen Dingen liegen. Ich bin offenbar ziehmlich nerdig, ich programmiere sehr gerne und ich habe in meinem Job eine unglaublich verrotteten C-Quellcode zu betreuen.
Als Software-Entwicklungs-Neuling hatte ich gedacht, ich komme in ein Unternehmen und lerne aus dem Quellcode von Profis wie man es richtig macht. Statt dessen habe ich Code übernommen, der offensichtlich von mindestens 3 Verschiedenen Autoren mit mindestens 3 Verschiedenen Programmierstilen erstellt wurde. Keine Tests, keine Kommentare, kein Durchblick, Lange (beschreibende) Funktions und Variablennamen gelten als unleserlich, Funktionsaufrufe als Performance-Bremse. Das Buch konzentriert sich zwar auf Java-Beispiele, trotzdem konnte ich es gut auf meinen Legacy-Code anwenden. Seit ich begonnen habe, den Code anhand einiger Tipps neu zu gestalten macht das Programmieren wieder mehr Spaß. Man verbringt weniger Zeit mit suchen und mehr Zeit damit, etwas zu verändern.
Das Buch ist locker geschrieben. Es enthält prägnante Aussagen, ohne dabei allzu schulmeisterisch herüber zu kommen. Es schwurbelt nicht herum, sondern bespricht systematisch viele Schrauben an denen man drehen kann, um seinen Quellcode leserlicher zu machen. Dabei geht es nicht ums prinzip und vorlieben der Autoren, sondern um klare Vorteile. Eindeutig 5 Sterne.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen
War diese Rezension für Sie hilfreich?
|
|
|
|
|
|
4 von 5 Kunden fanden die folgende Rezension hilfreich:
Stellenweise zu dogmatisch, daher -1 Stern., 20. August 2009
Ich habe einige Kapitel gelesen und will mir noch kein abschliessendes Bild machen. Das was die anderen Rezensenten sagen, stimmt schon. Es ist wirklich ein gutes Buch über gepflegten Code. Nur an ein paar Stellen wird mir der Autor zu dogmatisch, deswegen sollte man nicht alles blind übernehmen. Am deutlichsten wurde mir das im Kapitel 3 über Funktionen.
Dort beschreibt er anhand einer unaufgeräumten Funktion wie er sie schrittweise verbessert, und gibt dabei den ersten Zwischenschritt und das finale Ergebnis preis. Dabei erstellt er im Zwischenschritt eine absolut verständliche, klare Funktion mit 11 Codezeilen und beschreibenden Funktionsaufrufen. Damit ist der Autor aber nicht zufrieden, bezeichnet die Funktion absurderweise als immer noch "too long" und legt nochmal Hand an, indem er fast jede Zeile in eine eigene Funktion packt. Der daraus resultierende Code hat fast doppelt soviele Zeilen wie der ursprüngliche Code den es zu verbessern galt! Der Autor wünscht sich, das sich der Code wie eine Geschichte lesen soll, zerstückelt ihn dabei aber derart das man meint man würde nun ein Buch lesen in dem auf jeder Seite nur ein Satz mit maximal 10 Worten steht. Ich kann seine Begeisterung für derart zerstückelten Code absolut nicht nachvollziehen, zumal die Bezeichnung der Funktionen immer abstruser wird, da nun nicht mehr nur 5-10 Funktionen sondern eher 25 nach einer sinnvollen Beschreibung verlangen. Ganz zu schweigen davon das man vom Einstiegspunkt aus nun jeden Funktionsübergang mitlesen muss, indem man die aufgerufene Funktion sucht, dort den nächsten Funktionsaufruf vorfindet, um sehr schnell nicht mehr zu wissen auf welchem "level" des callstacks man sich nun befindet. Im Kopf ist sowas nur noch schwer zu durchschauen, und Debugger-freundlich ist das auch nicht mehr.
Ergo: mir hat der Zwischenschritt mit 11 Zeilen wesentlich besser gefallen, er war auf jeden Fall auf einen Blick verständlich und nachvollziehbar. Darauf wollte ich hingewiesen haben, denn hier wird der Autor dogmatisch und schießt sich selbst ins Knie, in dem er seine Argumentationen ad absurdum führt und dennoch sehr deutlich darauf beharrt was für wunderschönen Code er daraus gezaubert hat. Dieser Dogmatismus ist es auf den ich hinweisen wollte, und wegen dem ich auch einen Stern abziehe.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen
War diese Rezension für Sie hilfreich?
|
|
|
|
|
|
4 von 6 Kunden fanden die folgende Rezension hilfreich:
Gut gemeint, 19. September 2009
Gut gemeintes und geschriebenes Buch, das auch viele wichtige Ratschläge für guten Code enthält, insofern wert hineinzuschauen. Aber allzu oft schießt der Autor übers Ziel hinaus, und weit ins Dogmatische hinein. Nach meiner Meinung werden die Ratschläge dann oft kontraproduktiv, und verzetteln den Code, statt ihn leichter wartbar zu machen.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen
War diese Rezension für Sie hilfreich?
|
|
|
|
|
|
5 von 8 Kunden fanden die folgende Rezension hilfreich:
So short and so clean, 13. Dezember 2008
Ich kann das Buch nur empfehlen. Obwohl es ein Fachbuch ist, lässt es sich sehr gut lesen. Es ist wunderbar locker, unterhaltsam und trotzdem auf den Punkt geschrieben. Die Beispiele in Java sind passend und anschaulich und auf alle OO-Sprachen - zumindest auf die, die ich sonst verwende - ohne Probleme zu übertragen.
Wenn ich etwas kritisieren müsste, dann daß das Buch gerne noch umfangreicher sein könnte. Speziell das Kapitel "Error Handling" hört für mich zu früh auf.
Aber es ist auf jeden Fall jeden Cent wert und ich wünschte jeder Software-Entwickler würde es lesen und beherzigen.
Fazit: Unbedingt lesen!
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen
War diese Rezension für Sie hilfreich?
|
|
|
|
|
|
2 von 6 Kunden fanden die folgende Rezension hilfreich:
Viel Text, wenig Information, 28. September 2009
Von den guten Rezensionen verleitet, habe ich mir das Buch gekauft und bin enttäuscht.
Die propagierten Vorgaben zu gutem übersichtlichen Stil hätte man auch ohne die geschwätzigen JAVA Beispiele auf 30 Seiten unterbringen können, und manche Hinweise sind für sicherheitsrelevanten Code (und für's Testen) ungeeignet, zB mehrere return-Statements pro Modul - italienische Teigprodukte lassen grüßen.
Ein recht akademisch abgehobenes Buch von/für Menschen, deren Ruhm sich wohl nach "Lines of Text" bemisst.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen
War diese Rezension für Sie hilfreich?
|
|
|
|
|
|
1 von 4 Kunden fanden die folgende Rezension hilfreich:
Top-Lektüre für Entwickler (und Software-Architekten!), 25. April 2009
Robert Martin in Bestform!
Voller überzeugender Beispiele und guter Hinweise für besseren Code!
Praktische Software-Architekten sowie Entwickler sollten dieses Buch lesen,
allerdings ein paar Tage Zeit für die teilweise komplexen Beispiele reservieren...
Einziges Manko: Einige Beispiele (z.B. Primzahlengenerator) sind nicht wirklich praxisrelevant.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen
War diese Rezension für Sie hilfreich?
|
|
|
|
|
|
|
| |
|
|
| |
Kunden, die diesen Artikel angesehen haben, haben auch angesehen
|
|
| |
|
|
|
Amazon-Homepage
