CleanCode: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 2: Zeile 2:


== Clean Code Development ==
== Clean Code Development ==
Hierbei handelt es sich um bewährte Prinzipien und Praktiken aus der objektorientierten Softwareentwicklung. Sie wurden von <ref>[http://www.clean-code-developer.de/ Clean Code Developer]</ref> und aus <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.


[http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 Bei Amazon.]</ref> verkürzt übernommen. Ein reflektiertes Verwenden dieser Richtlinien kann zu besserem und vor allem lesbarerem Quellcode führen.
[http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 Bei Amazon.]</ref>. Es wurden absichtlich nicht alle Richtlinien übernommen, da stark verkürzt übernommen.  


=== Prinzipien ===
=== Prinzipien ===
===== Don't 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 den gemeinsamen Code in Funktionen 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.
 
===== Keep it simple, stupid (KISS) =====
===== Keep it simple, stupid (KISS) =====
Unnötige Komplexität ist Zeitverschwendung. Einfach ist gut.
Einfache Lösungen sind immer zu bevorzugen. Zerlege komplizierte Probleme in Teilprobleme, bis die Teilprobleme nicht weiter zerlegbar sind.  
 
===== Beware of Optimizations =====
===== Beware of Optimizations =====
Optimierung bedeutet Aufwand und in der Regel auch komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man auf solche Methoden verzichten.
Optimierung bedeutet Aufwand und komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man darauf verzichten. Eine erste Implementierung darf nie optimiert sein.
 
===== Single responsibility Principle (SRP) =====
===== Single responsibility Principle (SRP) =====
Eine Klasse sollte genau eine Aufgabe erfüllen. Das fördert die Lesbarkeit und Übersicht.
Eine Klasse sollte genau eine Aufgabe erfüllen.  
===== Code Conventions =====
 
Unverzichtbar bei Zusammenarbeit mehrerer Entwickler an einem größeren Softwareprojekt. Erhöht die Lesbarkeit und sorgt für Konsistenz im Quellcode.
===== 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.
 
===== Information Hiding Principle =====
===== Information Hiding Principle =====
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 diesen unabhängig gemacht.
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.
 
===== 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.
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.
 
===== Tell, don't ask =====
===== Tell, don't ask =====
Eine Klasse sollten nicht von aussen ü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.
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.
 
===== Law of Demeter (Don't talk to strangers) =====
===== Law of Demeter (Don't talk to strangers) =====
Lange Abhängigkeitsketten zwischen den Klassen eines Projekts führen zu einer engen Kopplung. Das Law of Demeter schlägt vor, dass eine Methode nur folgende andere Methoden verwendet
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 eigenen Klasse
* Methoden der Parameter
* Methoden der Parameter
* Methoden assozierter Klassen
* Methoden assozierter Klassen  
* Methoden selbst erzeugter Objekte
* Methoden selbst erzeugter Objekte
===== You ain't gonna need it (YAGNI) =====
===== You ain't gonna need it (YAGNI) =====
Was man nicht braucht sollte man nicht programmieren.
Was man nicht braucht sollte man nicht programmieren.
Zeile 39: Zeile 48:
===== Versionierung =====
===== Versionierung =====
Systeme wie Subversion (svn) erlauben verteiltes Arbeiten mit zusätzlichem Rückgriff auf alte Versionen des Projekts.
Systeme wie Subversion (svn) erlauben verteiltes Arbeiten mit zusätzlichem Rückgriff auf alte Versionen des Projekts.
===== Scout Rule =====
===== Scout Rule =====
Wenn der Quellcode immer Stück sauberer verlassen wird als man ihn vorgefunden hat, verbessert er sich iterativ.
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.  
===== Root cause Analysis =====
 
Nicht die Symptome sondern die Ursache bekämpfen. Debugging Regel Nummer 1.
===== Root Cause Analysis =====
Nicht die Symptome sondern die Ursache bekämpfen. Wenn Fehler auftreten, immer zuerst überlegen, wo diese herkommen können. Nicht der Versuchung erliegen, sie nur in den zuletzt veränderten Code-Stücken zu suchen.  


== Referenzen ==  
== Referenzen ==  
<references />
<references />

Version vom 1. Mai 2011, 14:59 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 stark verkürzt übernommen.

Prinzipien

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.

Keep it simple, stupid (KISS)

Einfache Lösungen sind immer zu bevorzugen. Zerlege komplizierte Probleme in Teilprobleme, bis die Teilprobleme nicht weiter zerlegbar sind.

Beware of Optimizations

Optimierung bedeutet Aufwand und komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man darauf verzichten. Eine erste Implementierung darf nie optimiert sein.

Single responsibility Principle (SRP)

Eine Klasse sollte genau eine Aufgabe erfüllen.

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.

Information Hiding Principle

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.

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.

Tell, don't ask

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.

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
You ain't gonna need it (YAGNI)

Was man nicht braucht sollte man nicht programmieren.

Praktiken

Code lesen

Lesen ist eine der besten Übungen überhaupt und bringt neue Erfahrungen ohne den Aufwand des Schreibens.

Versionierung

Systeme wie Subversion (svn) erlauben verteiltes Arbeiten mit zusätzlichem Rückgriff auf alte Versionen des Projekts.

Scout Rule

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.

Root Cause Analysis

Nicht die Symptome sondern die Ursache bekämpfen. Wenn Fehler auftreten, immer zuerst überlegen, wo diese herkommen können. Nicht der Versuchung erliegen, sie nur in den zuletzt veränderten Code-Stücken zu suchen.

Referenzen

  1. Clean Code Developer
  2. Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1 Edition, 2008. Bei Amazon.