CleanCode: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
Zur Navigation springen Zur Suche springen
(25 dazwischenliegende Versionen von 6 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Review}}
== 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? ===
Als Clean Code bezeichnet man intuitiv verständlichen Programmcode. Die Idee von Clean Code basiert auf der Beobachtung, dass ein Großteil der Arbeitszeit in einem Projekt auf der Arbeit mit bereits bestehendem Programmcode basiert (Wartung, Erweiterung, Debugging). Programmcode der „clean“ ist unterstützt diese Arbeit durch seine Verständlichkeit und Struktur. Umgekehrt ist arbeiten mit nicht „clean“ Code oft eine zeitaufwändig und fehleranfällige Übung in Geduld während man versucht das Werk eines anderen (oder eines jüngeren Selbst) nachzuvollziehen.
 
=== 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:


== Clean Code Development ==
* '''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 7: 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.   


=== Prinzipien ===
===== [http://clean-code-developer.de/die-grade/orangener-grad/#Source_Code_Konventionen Coding Conventions] =====
===== [http://www.clean-code-developer.de/Roter-Grad.ashx#Don%C2%B4t_Repeat_Yourself_DRY_0 Don't repeat yourself (DRY)] =====
[[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 &rarr; 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 &rarr; mehr dazu]
 
===== [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://programmer.97things.oreilly.com/wiki/index.php/Don%27t_Repeat_Yourself &rarr; mehr dazu]
===== [http://clean-code-developer.de/die-grade/roter-grad/#Keep_it_simple_stupid_KISS Keep it simple, stupid (KISS)] =====
 
===== [http://www.clean-code-developer.de/Roter-Grad.ashx#Keep_it_simple_stupid_KISS_1 Keep it simple, stupid (KISS)] =====
Einfache Lösungen sind immer zu bevorzugen. Zerlege komplizierte Probleme in Teilprobleme, bis die Teilprobleme nicht weiter zerlegbar sind.
Einfache Lösungen sind immer zu bevorzugen. Zerlege komplizierte Probleme in Teilprobleme, bis die Teilprobleme nicht weiter zerlegbar sind.


[http://people.apache.org/~fhanik/kiss.html &rarr; mehr dazu]
[http://people.apache.org/~fhanik/kiss.html &rarr; mehr dazu]


===== [http://www.clean-code-developer.de/Roter-Grad.ashx#Vorsicht_vor_Optimierungen!_2 Beware of Optimizations] =====
===== [http://clean-code-developer.de/die-grade/gruener-grad/#Law_of_Demeter Law of Demeter] =====
Optimierung bedeutet Aufwand und komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man darauf verzichten.
"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://wolfbyte-net.blogspot.com/2009/03/ccd-red-degree-rule-beware-of.html &rarr; mehr dazu]
===== [http://clean-code-developer.de/die-grade/orangener-grad/#Single_Responsibility_Principle_SRP Single Responsibility Principle (SRP)] =====
 
===== [http://www.clean-code-developer.de/Oranger-Grad.ashx#Single_Responsibility_Principle_SRP_1 Single Responsibility Principle (SRP)] =====
Eine Klasse sollte genau eine Aufgabe erfüllen.
Eine Klasse sollte genau eine Aufgabe erfüllen.


[http://programmer.97things.oreilly.com/wiki/index.php/The_Single_Responsibility_Principle &rarr; mehr dazu]
===== [http://clean-code-developer.de/die-grade/orangener-grad/#Separation_of_Concerns_SoC Separation of Concerns (SoC)] =====
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.


===== [http://www.clean-code-developer.de/Oranger-Grad.ashx#Separation_of_Concerns_SoC_2 Separation of Concerns (SoC)] =====
[http://weblogs.asp.net/arturtrosin/archive/2009/01/26/separation-of-concern-vs-single-responsibility-principle-soc-vs-srp.aspx &rarr; mehr dazu]
Zerteile ein Programm in unterschiedliche Bereiche (sowohl auf Klassen- als auch auf Komponentenebene), die jeweils eine Aufgabe haben und die sich so wenig wie möglich überlappen.


[http://weblogs.asp.net/arturtrosin/archive/2009/01/26/separation-of-concern-vs-single-responsibility-principle-soc-vs-srp.aspx &rarr; mehr dazu]
===== [http://clean-code-developer.de/die-grade/gelber-grad/#Liskov_Substitution_Principle Liskov Substitution Principle (LSP)] =====
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.


===== [http://www.clean-code-developer.de/Oranger-Grad.ashx#Source_Code_Konventionen_3 Coding Conventions] =====
[http://www.oodesign.com/liskov-s-substitution-principle.html &rarr; mehr dazu]
[[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.


[http://en.wikipedia.org/wiki/Coding_conventions &rarr; mehr dazu]
===== [http://clean-code-developer.de/die-grade/gelber-grad/#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 ihrer Implementierung unabhängig gemacht.


===== [http://www.clean-code-developer.de/Gelber-Grad.ashx#Interface_Segregation_Principle_ISP_0 Interface Segregation Principle (ISP)] =====
[http://en.wikipedia.org/wiki/Information_hiding &rarr; mehr dazu]
Interfaces sollen so klein wie möglich sein und nur beinhalten was auch wirklich benötigt wird.


[http://ifacethoughts.net/2006/03/28/interface-segregation-principle/ &rarr; mehr dazu]
===== [http://clean-code-developer.de/die-grade/gruener-grad/#Tell_dont_ask 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. Als Ergebnis entstehen Objekte mit Verhalten statt "dummer" Datenhaltungsobjekte.


===== [http://www.clean-code-developer.de/Gelber-Grad.ashx#Dependency_Inversion_Principle_1 Dependency Inversion Principle (DIP)] =====
[http://pragprog.com/articles/tell-dont-ask &rarr; mehr dazu]
 
===== [http://clean-code-developer.de/die-grade/gelber-grad/#Dependency_Inversion_Principle Dependency Inversion Principle (DIP)] =====
Entkopple Module über Interfaces:
Entkopple Module über Interfaces:
* Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Abstraktionen abhängen.
* Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Abstraktionen abhängen.
Zeile 50: Zeile 79:
[http://lostechies.com/gabrielschenker/2009/01/30/the-dependency-inversion-principle/ &rarr; mehr dazu]
[http://lostechies.com/gabrielschenker/2009/01/30/the-dependency-inversion-principle/ &rarr; mehr dazu]


===== [http://www.clean-code-developer.de/Gelber-Grad.ashx#Liskov_Substitution_Principle_2 Liskov Substitution Principle (LSP)] =====
===== [http://clean-code-developer.de/die-grade/roter-grad/#Vorsicht_vor_Optimierungen Beware of Optimizations] =====
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.
Optimierung bedeutet Aufwand und komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man darauf verzichten.


Allgemeiner: Ein Subtyp darf die Funktionalität eines Basistyps lediglich erweitern, aber nicht einschänken.
[http://www.codermike.com/ccd-red-degree-rule-beware-of-optimizations &rarr; mehr dazu]
 
[http://www.oodesign.com/liskov-s-substitution-principle.html &rarr; mehr dazu]


===== [http://www.clean-code-developer.de/Gelber-Grad.ashx#Information_Hiding_Principle_4 Information Hiding Principle] =====
===== Favour Composition over Inheritance (FCoI) =====
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.
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://information-hiding.co.tv/ &rarr; mehr dazu]
[http://blogs.msdn.com/b/steverowe/archive/2008/04/28/prefer-composition-over-inheritance.aspx &rarr; mehr dazu]


===== [http://www.clean-code-developer.de/Gelber-Grad.ashx#Principle_of_Least_Astonishment_3 Principle of Least Astonishment] =====
[http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ &rarr; mehr dazu]
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 &rarr; mehr dazu]
===== [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://www.clean-code-developer.de/Gr%c3%bcner-Grad.ashx#Tell_don%C2%B4t_ask_1 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. Als Ergebnis entstehen Objekte mit Verhalten statt "dummer" Datenhaltungsobjekte.


[http://pragprog.com/articles/tell-dont-ask &rarr; mehr dazu]
===== [http://clean-code-developer.de/die-grade/blauer-grad/#You_Aint_Gonna_Need_It_YAGNI You ain't gonna need it (YAGNI)] =====
 
===== [http://www.clean-code-developer.de/Gr%c3%bcner-Grad.ashx#Law_of_Demeter_2 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://www.aspiringcraftsman.com/tag/law-of-demeter/ &rarr; mehr dazu]
 
===== [http://www.clean-code-developer.de/Blauer-Grad.ashx#You_Ain%C2%B4t_Gonna_Need_It_YAGNI_2 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.


[http://www.xprogramming.com/Practices/PracNotNeed.html &rarr; mehr dazu]
== Praktiken ==
 
===== [http://clean-code-developer.de/die-grade/orangener-grad/#Lesen_Lesen_Lesen Lesen] =====
=== Praktiken ===
===== [http://www.clean-code-developer.de/Oranger-Grad.ashx#Lesen_Lesen_Lesen_6 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.


===== [http://www.clean-code-developer.de/Roter-Grad.ashx#Ein_Versionskontrollsystem_einsetzen_6 Versionierung] =====
===== [http://clean-code-developer.de/die-grade/roter-grad/#Ein_Versionskontrollsystem_einsetzen Versionierung] =====
Systeme wie Subversion (svn) erlauben verteiltes Arbeiten mit zusätzlichem Rückgriff auf alte Versionen des Projekts.
Systeme wie [[Git]] erlauben verteiltes Arbeiten mit zusätzlichem Rückgriff auf alte Versionen des Projekts.


===== [http://www.clean-code-developer.de/Roter-Grad.ashx#Die_Pfadfinderregel_beachten_4 Scout Rule] =====
===== [http://clean-code-developer.de/die-grade/roter-grad/#Die_Pfadfinderregel_beachten 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.  
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.  


===== [http://www.clean-code-developer.de/Roter-Grad.ashx#Root_Cause_Analysis_5 Root Cause Analysis] =====
===== [http://clean-code-developer.de/die-grade/roter-grad/#Root_Cause_Analysis Root Cause Analysis] =====
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.
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.



Version vom 5. Mai 2019, 10:19 Uhr

Clean Code Development

Clean Code ist ein von Robert C. Martin in seinem gleichnamigen Buch [1] geprägter Begriff aus der Softwareentwicklung welcher in erster Linie Quellcode aber auch andere Dokumente und Konzepte bezeichnet welche intuitiv verständlich sind. [2]

Warum Clean Code?

Als Clean Code bezeichnet man intuitiv verständlichen Programmcode. Die Idee von Clean Code basiert auf der Beobachtung, dass ein Großteil der Arbeitszeit in einem Projekt auf der Arbeit mit bereits bestehendem Programmcode basiert (Wartung, Erweiterung, Debugging). Programmcode der „clean“ ist unterstützt diese Arbeit durch seine Verständlichkeit und Struktur. Umgekehrt ist arbeiten mit nicht „clean“ Code oft eine zeitaufwändig und fehleranfällige Übung in Geduld während man versucht das Werk eines anderen (oder eines jüngeren Selbst) nachzuvollziehen.

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
    fileAgeInDays statt age
  • Such freundliche Namen
    days statt d
  • Keine humoristischen Namen
    deleteItem statt destroyEverything
  • Eine Bezeichnung pro Konzept
    set[Name], get[Name], create[Name], ...
  • Keine Abkürzungen
    timeStamp statt tmp
  • Keine Artikel
    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 [3] und [4]. Es wurden absichtlich nicht alle Richtlinien übernommen, da sie umstritten, nicht eindeutig oder sehr schwierig anzuwenden sind.

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.

→ mehr dazu

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.

→ mehr dazu

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.

→ mehr dazu

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
Single Responsibility Principle (SRP)

Eine Klasse sollte genau eine Aufgabe erfüllen.

Separation of Concerns (SoC)

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.

→ mehr dazu

Liskov Substitution Principle (LSP)

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.

→ mehr dazu

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.

→ mehr dazu

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. Als Ergebnis entstehen Objekte mit Verhalten statt "dummer" Datenhaltungsobjekte.

→ mehr dazu

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.

→ mehr dazu

Beware of Optimizations

Optimierung bedeutet Aufwand und komplexeren Code. Solange es nicht WIRKLICH notwendig ist, sollte man darauf verzichten.

→ 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.

→ mehr dazu

→ mehr dazu

Interface Segregation Principle (ISP)

Interfaces sollen so klein wie möglich sein und nur beinhalten was auch wirklich benötigt wird.

You ain't gonna need it (YAGNI)

Programmiere nur was gebraucht wird und nicht was vielleicht irgendwann mal gebraucht werden könnte.

Praktiken

Lesen

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

Versionierung

Systeme wie Git 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 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

  1. Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1 Edition, 2008. Bei Amazon.
  2. 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)
  3. Clean Code Developer
  4. Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1 Edition, 2008. Bei Amazon.