Kommentare zu: Clean Code Teil 1 http://blog.aztec-project.org/2009/08/11/clean-code-teil-1/ but we can fix it! Sometimes :) Tue, 27 Jul 2010 06:41:30 +0000 hourly 1 http://wordpress.org/?v=abc Von: build broken » Clean Code Teil 2 http://blog.aztec-project.org/2009/08/11/clean-code-teil-1/comment-page-1/#comment-84 build broken » Clean Code Teil 2 Wed, 04 Nov 2009 14:16:06 +0000 http://blog.aztec-project.org/?p=497#comment-84 [...] habe das Buch “Clean Code” von Robert C. Martin a.k.a. Uncle Bob durchgelesen. Nach dem ersten Teil hier nun die versprochene Fortsetzung meiner [...] [...] habe das Buch “Clean Code” von Robert C. Martin a.k.a. Uncle Bob durchgelesen. Nach dem ersten Teil hier nun die versprochene Fortsetzung meiner [...]

]]> Von: Rene Drescher-Hackel http://blog.aztec-project.org/2009/08/11/clean-code-teil-1/comment-page-1/#comment-44 Rene Drescher-Hackel Thu, 27 Aug 2009 22:29:09 +0000 http://blog.aztec-project.org/?p=497#comment-44 Ich kann Peter hier nur zustimmen. Ergänzend sei noch gesagt - was keine wertende Aussage zum Blogbeitrag sein soll - dass die ganze Diskussion um Clean Code inzwischen aus meiner Sicht recht übertrieben wird. Um sauberen Code zu schreiben, muss ich weder ein Armband tragen, noch muss ich Pyramiden falten oder entsprechende T-Shirts tragen. Da fällt mir eine sehr praktische Redensart ein: "Es gibt nichts Gutes, außer man tut es". Und so ist es auch mit der losgetretenen "Clean Code Debatte". Was letztlich "sauberer Code" ist, wird doch von vielen Faktoren bestimmt, die im Wesentlichen aus einem Allgemeinverständnis herrührt und aber auch vom Entwicklerteam maßgeblich mit beeinflusst wird. Sicher, man sollte nicht unbedingt ein 500 Seiten umfassendes Referenzwerk zu Rate ziehen müssen, um den Code des Kollegen zu verstehen. Gelegentlich sieht man auch immer wieder noch den ungeliebten "Spagetthi-Code", was keineswegs erstrebenswert ist. Aber müssen wir denn jetzt alle um jeden Preis nach den Empfehlungen des Buches "Clean Code" von Robert C. Martin unseren Code umschreiben? Nein, ich denke, manchmal ist es viel vernünftiger seinem Stil treu zu bleiben. Dennoch kann man dabei funktionellen, sauberen, lesbaren Code schreiben. Wenn ich lese, dies und das ist "böse" und "verboten", dann hat das etwas von "Bibel", wo ich mich dann frage, wer gibt hier wem das Recht, Dinge als "verboten" zu deklarieren. Also man sollte bei aller Clean-Code Diskussion immer das Ziel nicht aus den Augen verlieren und vor allem auf dem Teppich bleiben. ;-) Grüße aus dem Frankenland. Rene Ich kann Peter hier nur zustimmen. Ergänzend sei noch gesagt – was keine wertende Aussage zum Blogbeitrag sein soll – dass die ganze Diskussion um Clean Code inzwischen aus meiner Sicht recht übertrieben wird. Um sauberen Code zu schreiben, muss ich weder ein Armband tragen, noch muss ich Pyramiden falten oder entsprechende T-Shirts tragen. Da fällt mir eine sehr praktische Redensart ein: “Es gibt nichts Gutes, außer man tut es”. Und so ist es auch mit der losgetretenen “Clean Code Debatte”.

Was letztlich “sauberer Code” ist, wird doch von vielen Faktoren bestimmt, die im Wesentlichen aus einem Allgemeinverständnis herrührt und aber auch vom Entwicklerteam maßgeblich mit beeinflusst wird. Sicher, man sollte nicht unbedingt ein 500 Seiten umfassendes Referenzwerk zu Rate ziehen müssen, um den Code des Kollegen zu verstehen. Gelegentlich sieht man auch immer wieder noch den ungeliebten “Spagetthi-Code”, was keineswegs erstrebenswert ist.
Aber müssen wir denn jetzt alle um jeden Preis nach den Empfehlungen des Buches “Clean Code” von Robert C. Martin unseren Code umschreiben? Nein, ich denke, manchmal ist es viel vernünftiger seinem Stil treu zu bleiben. Dennoch kann man dabei funktionellen, sauberen, lesbaren Code schreiben.
Wenn ich lese, dies und das ist “böse” und “verboten”, dann hat das etwas von “Bibel”, wo ich mich dann frage, wer gibt hier wem das Recht, Dinge als “verboten” zu deklarieren.

Also man sollte bei aller Clean-Code Diskussion immer das Ziel nicht aus den Augen verlieren und vor allem auf dem Teppich bleiben. ;-)

Grüße aus dem Frankenland.

Rene

]]> Von: Peter Bucher http://blog.aztec-project.org/2009/08/11/clean-code-teil-1/comment-page-1/#comment-33 Peter Bucher Tue, 11 Aug 2009 17:45:34 +0000 http://blog.aztec-project.org/?p=497#comment-33 Salute Andreas Coole Zusammenfassung, gefällt mir gut :-). Ein paar Anmerkungen bzw. Ergänzungen: Das Buch "Clean Code" ist extra extrem und provokant geschrieben, es soll provozieren. Man sollte nicht alles 1:1 übernehmen und als bare Münze hinnehmen, sondern nur das und soviel wie es Sinn macht. Mit den Kommentaren sind nicht die JavaDocs / XmlDocs von C# / VB.NET gemeint. API Dokumentation ist nach wie vor sehr wichtig und hilfreich und sollte benutzt und aktualisiert werden. Stell dir nur mal ein .NET Framework ohne Intellisense-Kommentare vor :-). Zu dont`t return null / don`t pass null muss ich sagen, das Clean Code auf Java fokusiert ist und das dort anders sein kann. Man sollte null mit Bedacht und Strategie einsetzen, so eine pauschale Aussage kann ich aber für C# nicht gelten lassen. Denn zum Teil ist das bei .NET selber Konvention (ob das jetzt gut oder schlecht ist, lassen wir mal aussen vor), oder sinnvoll gar nicht anders möglich. Eine interessante Diskussion dazu findet sich bspw. auf: - http://www.mycsharp.de/wbb2/thread.php?threadid=69181&hilight=null+funktion+php+peter Grüsse aus der Schweiz, Peter Salute Andreas

Coole Zusammenfassung, gefällt mir gut :-) .
Ein paar Anmerkungen bzw. Ergänzungen:

Das Buch “Clean Code” ist extra extrem und provokant geschrieben, es soll provozieren.
Man sollte nicht alles 1:1 übernehmen und als bare Münze hinnehmen, sondern nur das und soviel wie es Sinn macht.

Mit den Kommentaren sind nicht die JavaDocs / XmlDocs von C# / VB.NET gemeint. API Dokumentation ist nach wie vor sehr wichtig und hilfreich und sollte benutzt und aktualisiert werden.
Stell dir nur mal ein .NET Framework ohne Intellisense-Kommentare vor :-) .

Zu dont`t return null / don`t pass null muss ich sagen, das Clean Code auf Java fokusiert ist und das dort anders sein
kann. Man sollte null mit Bedacht und Strategie einsetzen, so eine pauschale Aussage kann ich aber für C# nicht gelten lassen.

Denn zum Teil ist das bei .NET selber Konvention (ob das jetzt gut oder schlecht ist, lassen wir mal aussen vor),
oder sinnvoll gar nicht anders möglich.

Eine interessante Diskussion dazu findet sich bspw. auf:
- http://www.mycsharp.de/wbb2/thread.php?threadid=69181&hilight=null+funktion+php+peter

Grüsse aus der Schweiz, Peter

]]> Von: Christina http://blog.aztec-project.org/2009/08/11/clean-code-teil-1/comment-page-1/#comment-32 Christina Tue, 11 Aug 2009 13:26:57 +0000 http://blog.aztec-project.org/?p=497#comment-32 Super Zusammenfassung, ich möchte nur ein Paar kleine Ergänzungen machen: Kleine 3-er Regel zu DRY: einmal schreiben -> OK. Zweimal schreiben -> kann man noch akzeptieren. Dreimal schreiben-> refaktorieren! (Fowler-Refactoring) Was das KATEGORISCHE Abweisen von Kommentaren betrifft, kann ich wirklich nicht einverstanden sein. Ich kann mir Millionen von Fällen vorstellen, wo ein Name nicht aussagend genug sein kann. aber ich finde auch, dass Namen genau so wichtig sind wie DRY oder The Boy Scout Rule. Bin schon auf die Fortsetzung gespannt :) Super Zusammenfassung, ich möchte nur ein Paar kleine Ergänzungen machen:

Kleine 3-er Regel zu DRY: einmal schreiben -> OK. Zweimal schreiben -> kann man noch akzeptieren. Dreimal schreiben-> refaktorieren! (Fowler-Refactoring)

Was das KATEGORISCHE Abweisen von Kommentaren betrifft, kann ich wirklich nicht einverstanden sein. Ich kann mir Millionen von Fällen vorstellen, wo ein Name nicht aussagend genug sein kann. aber ich finde auch, dass Namen genau so wichtig sind wie DRY oder The Boy Scout Rule.

Bin schon auf die Fortsetzung gespannt :)

]]>