CleanCode: Unterschied zwischen den Versionen
Jeremi (Diskussion | Beiträge) |
Jeremi (Diskussion | Beiträge) |
||
| Zeile 22: | Zeile 22: | ||
[http://wolfbyte-net.blogspot.com/2009/03/ccd-red-degree-rule-beware-of.html → mehr dazu] | [http://wolfbyte-net.blogspot.com/2009/03/ccd-red-degree-rule-beware-of.html → mehr dazu] | ||
{{BA|Dietsch|Link tot}} | |||
===== [http://www.clean-code-developer.de/Oranger-Grad.ashx#Single_Responsibility_Principle_SRP_1 Single Responsibility Principle (SRP)] ===== | ===== [http://www.clean-code-developer.de/Oranger-Grad.ashx#Single_Responsibility_Principle_SRP_1 Single Responsibility Principle (SRP)] ===== | ||
Version vom 25. April 2012, 14:26 Uhr
Clean Code Development
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 [1] und [2]. Es wurden absichtlich nicht alle Richtlinien übernommen, da sie umstritten, nicht eindeutig oder sehr schwierig anzuwenden sind.
Prinzipien
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.
Einfache Lösungen sind immer zu bevorzugen. Zerlege komplizierte Probleme in Teilprobleme, bis die Teilprobleme nicht weiter zerlegbar sind.
Optimierung bedeutet Aufwand und komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man darauf verzichten.
Eine Klasse sollte genau eine Aufgabe erfüllen.
Zerteile ein Programm in unterschiedliche Bereiche (eigentlich auf Klassenebene, aber auch auf Komponentenebene anwendbar), die jeweils eine Aufgabe haben und die sich so wenig wie möglich überlappen.
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.
Interfaces sollen so klein wie möglich sein und nur beinhalten was auch wirklich benötigt wird.
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.
Subtypen müssen sich so verhalten wie ihr Basistyp. Z.B. darf eine Methode, die im Basistyp keine Exception wirft, auch im Subtyp keine Exception werfen.
Allgemeiner: Ein Subtyp darf die Funktionalität eines Basistyps lediglich erweitern, aber nicht einschänken.
Eine Klasse sollte nur die für die Schnittstelle notwendigen Methoden und Felder öffentlich zur Verfügung stellen. Durch das Verbergen der Implementierungsdetails wird die Benutzung der Klasse von ihrer Implementierung unabhängig gemacht.
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.
Eine Klasse sollte nicht von außen über ihren internen Zustand befragt werden können. Es ist besser dem Objekt mitzuteilen was es zu tun hat. Das verlagert die Logik zur Benutzung der Klasse in die Klasse selbst und der Benutzer muss sich darüber keine Gedanken mehr machen. Als Ergebnis entstehen Objekte mit Verhalten statt "dummer" Datenhaltungsobjekte.
"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
Programmiere nur was gebraucht wird und nicht was vielleicht irgendwann mal gebraucht werden könnte.
Praktiken
Lesen ist eine der besten Übungen überhaupt und bringt neue Erfahrungen ohne den Aufwand des Schreibens.
Systeme wie Subversion (svn) erlauben verteiltes Arbeiten mit zusätzlichem Rückgriff auf alte Versionen des Projekts.
Verlasse Code immer sauberer als du ihn betrittst. Wenn man beim Lesen von Code Fehler oder Verletzungen dieser Prinzipien bemerkt, sollte man ihn gleich verbessern.
Nicht die Symptome sondern die Ursache bekämpfen. Wenn Probleme auftreten, immer zuerst überlegen, wo diese herkommen können. Nicht der Versuchung erliegen, nur in den zuletzt veränderten Code-Stücken zu suchen.
Referenzen
- ↑ Clean Code Developer
- ↑ Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1 Edition, 2008. Bei Amazon.
