CleanCode: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „= WORK IN PROGRESS = === Clean Code Development === Hierbei handelt es sich um altbewährte Prinzipien und Praktiken in der Objektorientierten Softwareentwicklun…“)
 
Zeile 5: Zeile 5:


==== Prinzipien ====
==== Prinzipien ====
* DRY
===== Don't repeat yourself (DRY) =====
* KISS
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.
* Beware of Optimizations
===== Keep it simple, stupid (KISS) =====
* One level of abstraction
Unnötige Komplexität ist Zeitverschwendung. Einfach ist gut.
* Single responsibility Principle
===== Beware of Optimizations =====
* Seperation of Concerns
Optimierung bedeutet Aufwand und in der Regel auch komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man auf solche Methoden verzichten.
* Code Conventions
===== Single responsibility Principle (SRP) =====
* Information Hiding Principle
Eine Klasse sollte genau eine Aufgabe erfüllen. Das fördert die Lesbarkeit und Übersicht.
* Principle of least astonishment
===== Code Conventions =====
* Tell, don't ask
Unverzichtbar bei Zusammenarbeit mehrerer Entwickler an einem größeren Softwareprojekt. Erhöht die Lesbarkeit und sorgt für Konsistenz im Quellcode.
* Law of Demeter
===== Information Hiding Principle =====
* You ain't gonna need it (YAGNI)
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.
===== 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 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.
===== 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
* 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 ====
==== Praktiken ====

Version vom 3. April 2011, 15:57 Uhr

WORK IN PROGRESS

Clean Code Development

Hierbei handelt es sich um altbewährte Prinzipien und Praktiken in der Objektorientierten Softwareentwicklung, die es sich lohnt zu kennen. Ein reflektiertes verwenden dieser Richtlinien kann zu besserem und vor allem lesbarerem Quellcode führen.

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 den gemeinsamen Code in Funktionen auslagern.

Keep it simple, stupid (KISS)

Unnötige Komplexität ist Zeitverschwendung. Einfach ist gut.

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.

Single responsibility Principle (SRP)

Eine Klasse sollte genau eine Aufgabe erfüllen. Das fördert die Lesbarkeit und Übersicht.

Code Conventions

Unverzichtbar bei Zusammenarbeit mehrerer Entwickler an einem größeren Softwareprojekt. Erhöht die Lesbarkeit und sorgt 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 diesen 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 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.

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

  • 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

  • Versionierung
  • Scout Rule
  • Root cause Analysis
  • Code lesen
  • Code Reviews
  • Mockups