CleanCode: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
Roth (Diskussion | Beiträge) →Versionierung: SVN weg Git da. |
Einleitung, Warum Clean Code?, sowie Bennenungsteil hinzugefügt. Prinziepien reihenfolge überarbeitet |
||
| Zeile 1: | Zeile 1: | ||
== Clean Code Development == | == Clean Code Development == | ||
Clean Code ist ein von Robert C. Martin in seinem gleichnamigen Buch <ref> | |||
Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1 Edition, 2008. [http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 Bei Amazon.]</ref> geprägter Begriff aus der Softwareentwicklung welcher in erster Linie Quellcode aber auch andere Dokumente und Konzepte bezeichnet welche intuitiv verständlich sind. <ref>Seite „Clean Code“. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 16. März 2018, 09:50 UTC. URL: https://de.wikipedia.org/w/index.php?title=Clean_Code&oldid=175065244 (Abgerufen: 20. April 2019, 15:58 UTC)</ref> | |||
=== Warum Clean Code? === | |||
Je größer ein Projekt ist und je mehr Parteien daran entwickeln desto wichtiger wird es, dass Code nicht nur funktional seinen Zweck erfüllt sondern auch Lesbar und Verständlich ist für alle die, die nicht Autoren des Quellcodes sind. Das erleichtert zum einen das Verwenden von bereits geschriebenen Klassen, Funktionen und Konstrukten, das Finden von Bugs, sowie das Erweitern solcher Konstrukte. "Unsauberer" Code führt zu steigendem Zeitaufwand beim Implementieren und zu Unproduktivität, was demotivierend sein kann. | |||
=== Benennung === | |||
Ein wichtiger Teil von “sauberem” Code ist eine gute Benennung von Klassen, Methoden, und Variablen. Hierfür gibt es einige sehr nützliche Richtlinien: | |||
* '''Intention aufzeigende Namen'''<br>fileAgeInDays statt age | |||
* '''Such freundliche Namen'''<br>days statt d | |||
* '''Keine humoristischen Namen'''<br>deleteItem statt destroyEverything | |||
* '''Eine Bezeichnung pro Konzept'''<br>set[Name], get[Name], create[Name], ... | |||
* '''Keine Abkürzungen'''<br>timeStamp statt tmp | |||
* '''Keine Artikel'''<br>objectList statt theObjectList | |||
== Prinzipien == | |||
Hierbei handelt es sich um bewährte Prinzipien und Praktiken aus der objektorientierten Softwareentwicklung. Ein reflektiertes Verwenden dieser Richtlinien kann zu besserem und vor allem lesbarerem Quellcode führen. Diese Zusammenstellung orientiert sich an <ref>[http://www.clean-code-developer.de/ Clean Code Developer]</ref> und <ref> | Hierbei handelt es sich um bewährte Prinzipien und Praktiken aus der objektorientierten Softwareentwicklung. Ein reflektiertes Verwenden dieser Richtlinien kann zu besserem und vor allem lesbarerem Quellcode führen. Diese Zusammenstellung orientiert sich an <ref>[http://www.clean-code-developer.de/ Clean Code Developer]</ref> und <ref> | ||
Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1 Edition, 2008. | Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1 Edition, 2008. | ||
| Zeile 5: | Zeile 22: | ||
[http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 Bei Amazon.]</ref>. Es wurden absichtlich nicht alle Richtlinien übernommen, da sie umstritten, nicht eindeutig oder sehr schwierig anzuwenden sind. | [http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 Bei Amazon.]</ref>. Es wurden absichtlich nicht alle Richtlinien übernommen, da sie umstritten, nicht eindeutig oder sehr schwierig anzuwenden sind. | ||
=== | ===== [http://clean-code-developer.de/die-grade/orangener-grad/#Source_Code_Konventionen Coding Conventions] ===== | ||
[[Coding Conventions]] sind für die Zusammenarbeit mehrerer Entwickler an einem größeren Softwareprojekt unverzichtbar. Sie erhöhen die Lesbarkeit und sorgen für Konsistenz im Quellcode. Im Softwarepraktikum wird die Einhaltung der [[Coding Conventions]] durch [[Resharper]] unterstüzt. | |||
[http://en.wikipedia.org/wiki/Coding_conventions → mehr dazu] | |||
===== [http://clean-code-developer.de/die-grade/gelber-grad/#Principle_of_Least_Astonishment Principle of Least Astonishment] ===== | |||
Programmteile sollten sich so verhalten, "wie man es erwartet". Funktionen sollten sich ihrem Namen entsprechend verhalten und Seiteneffekte sollten klar ersichtlich und gut dokumentiert sein. | |||
[http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/02/27/9590.aspx → mehr dazu] | |||
===== [http://clean-code-developer.de/die-grade/roter-grad/#Dont_Repeat_Yourself_DRY Don't repeat yourself (DRY)] ===== | ===== [http://clean-code-developer.de/die-grade/roter-grad/#Dont_Repeat_Yourself_DRY Don't repeat yourself (DRY)] ===== | ||
Kopierter Code leistet Inkonsistenzen Vorschub und führt zu einem mehr an Fehleranfälligkeit und Arbeit. Kein Copy & Paste sondern mehrfach verwendeten Code in Funktionen und/oder Klassen auslagern. | Kopierter Code leistet Inkonsistenzen Vorschub und führt zu einem mehr an Fehleranfälligkeit und Arbeit. Kein Copy & Paste sondern mehrfach verwendeten Code in Funktionen und/oder Klassen auslagern. | ||
===== [http://clean-code-developer.de/die-grade/roter-grad/#Keep_it_simple_stupid_KISS Keep it simple, stupid (KISS)] ===== | ===== [http://clean-code-developer.de/die-grade/roter-grad/#Keep_it_simple_stupid_KISS Keep it simple, stupid (KISS)] ===== | ||
| Zeile 16: | Zeile 40: | ||
[http://people.apache.org/~fhanik/kiss.html → mehr dazu] | [http://people.apache.org/~fhanik/kiss.html → mehr dazu] | ||
===== [http://clean-code-developer.de/die-grade/ | ===== [http://clean-code-developer.de/die-grade/gruener-grad/#Law_of_Demeter Law of Demeter] ===== | ||
"Don't talk to strangers": Lange Abhängigkeitsketten zwischen den Klassen eines Projekts führen zu einer engen Kopplung im gesamten Projekt. Die erschwert Wartung, Erweiterung und Tests. Um dies zu vermeiden, sollte eine Methode nur folgende andere Methoden verwenden: | |||
* Methoden der eigenen Klasse | |||
* Methoden der Parameter | |||
* Methoden assozierter Klassen | |||
* Methoden selbst erzeugter Objekte | |||
===== [http://clean-code-developer.de/die-grade/orangener-grad/#Single_Responsibility_Principle_SRP Single Responsibility Principle (SRP)] ===== | ===== [http://clean-code-developer.de/die-grade/orangener-grad/#Single_Responsibility_Principle_SRP Single Responsibility Principle (SRP)] ===== | ||
Eine Klasse sollte genau eine Aufgabe erfüllen. | Eine Klasse sollte genau eine Aufgabe erfüllen. | ||
===== [http://clean-code-developer.de/die-grade/orangener-grad/#Separation_of_Concerns_SoC Separation of Concerns (SoC)] ===== | ===== [http://clean-code-developer.de/die-grade/orangener-grad/#Separation_of_Concerns_SoC Separation of Concerns (SoC)] ===== | ||
| Zeile 37: | Zeile 54: | ||
[http://weblogs.asp.net/arturtrosin/archive/2009/01/26/separation-of-concern-vs-single-responsibility-principle-soc-vs-srp.aspx → mehr dazu] | [http://weblogs.asp.net/arturtrosin/archive/2009/01/26/separation-of-concern-vs-single-responsibility-principle-soc-vs-srp.aspx → mehr dazu] | ||
===== [http://clean-code-developer.de/die-grade/gelber-grad/#Liskov_Substitution_Principle Liskov Substitution Principle (LSP)] ===== | ===== [http://clean-code-developer.de/die-grade/gelber-grad/#Liskov_Substitution_Principle Liskov Substitution Principle (LSP)] ===== | ||
| Zeile 66: | Zeile 66: | ||
[http://en.wikipedia.org/wiki/Information_hiding → mehr dazu] | [http://en.wikipedia.org/wiki/Information_hiding → mehr dazu] | ||
===== [http://clean-code-developer.de/die-grade/gruener-grad/#Tell_dont_ask Tell, don't ask] ===== | ===== [http://clean-code-developer.de/die-grade/gruener-grad/#Tell_dont_ask Tell, don't ask] ===== | ||
| Zeile 77: | Zeile 72: | ||
[http://pragprog.com/articles/tell-dont-ask → mehr dazu] | [http://pragprog.com/articles/tell-dont-ask → mehr dazu] | ||
===== [http://clean-code-developer.de/die-grade/ | ===== [http://clean-code-developer.de/die-grade/gelber-grad/#Dependency_Inversion_Principle Dependency Inversion Principle (DIP)] ===== | ||
Entkopple Module über Interfaces: | |||
* Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Abstraktionen abhängen. | |||
* Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen. | |||
[http://lostechies.com/gabrielschenker/2009/01/30/the-dependency-inversion-principle/ → mehr dazu] | |||
===== [http://clean-code-developer.de/die-grade/roter-grad/#Vorsicht_vor_Optimierungen Beware of Optimizations] ===== | |||
Optimierung bedeutet Aufwand und komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man darauf verzichten. | |||
[http://www.codermike.com/ccd-red-degree-rule-beware-of-optimizations → mehr dazu] | |||
===== Favour Composition over Inheritance (FCoI) ===== | |||
Komposition ist flexibler als Ableitung. Bevor man von einer Klasse ableitet, sollte man sich daher immer zuerst fragen, ob man dasselbe Ergebnis nicht auch mit Komposition erreichen kann. | |||
[http://blogs.msdn.com/b/steverowe/archive/2008/04/28/prefer-composition-over-inheritance.aspx → mehr dazu] | |||
[http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ → mehr dazu] | |||
[http:// | ===== [http://clean-code-developer.de/die-grade/gelber-grad/#Interface_Segregation_Principle_ISP Interface Segregation Principle (ISP)] ===== | ||
Interfaces sollen so klein wie möglich sein und nur beinhalten was auch wirklich benötigt wird. | |||
===== [http://clean-code-developer.de/die-grade/blauer-grad/#You_Aint_Gonna_Need_It_YAGNI You ain't gonna need it (YAGNI)] ===== | ===== [http://clean-code-developer.de/die-grade/blauer-grad/#You_Aint_Gonna_Need_It_YAGNI You ain't gonna need it (YAGNI)] ===== | ||
Programmiere nur was gebraucht wird und nicht was vielleicht irgendwann mal gebraucht werden könnte. | Programmiere nur was gebraucht wird und nicht was vielleicht irgendwann mal gebraucht werden könnte. | ||
== Praktiken == | |||
===== [http://clean-code-developer.de/die-grade/orangener-grad/#Lesen_Lesen_Lesen Lesen] ===== | ===== [http://clean-code-developer.de/die-grade/orangener-grad/#Lesen_Lesen_Lesen Lesen] ===== | ||
Lesen ist eine der besten Übungen überhaupt und bringt neue Erfahrungen ohne den Aufwand des Schreibens. | Lesen ist eine der besten Übungen überhaupt und bringt neue Erfahrungen ohne den Aufwand des Schreibens. | ||
