Clean Code Developer (CCD) Software professionell entwickeln Erste Schritte ... 22.05.2009 Ralf Schoch

Clean Code Developer (CCD) Woher kommt CCD? Was ist die Idee von CCD? Agenda Clean Code Developer (CCD) Woher kommt CCD? Was ist die Idee von CCD? Was sind die CCD Grade? 1. Grad – Rot Literatur Links Woher kommt Clean Code Developer? Was ist die Idee von CCD? Was sind die CCD Grade? 1. Grad – Rot Literatur Links 22.05.2009 Ralf Schoch

Autor: Bücher und Artikel im .NET Umfeld Clean Code Developer Woher kommt Clean Code Developer? Die Verursacher Ralf Westphal Autor: Bücher und Artikel im .NET Umfeld Sprecher bei Entwicklerveranstaltungen Workshops .NET TV Stephan Lieser .NET User Group Bonn Autor: Artikel im .NET Umfeld Ralf Westphal Autor: Bücher und Artikel im .NET Umfeld Sprecher bei Entwicklerveranstaltungen Workshops .NET TV Stephan Lieser .NET User Group Bonn Autor: Artikel im .NET Umfeld 22.05.2009 Ralf Schoch

Das Buch „Clean Code“ von „Robert C. Martin“. Clean Code Developer Woher kommt Clean Code Developer? Das Buch „Clean Code“ von „Robert C. Martin“. Lernen Sie, guten Code von schlechtem zu unterscheiden. Sauberen Code schreiben und schlechten Code in guten umwandeln. Aussagekräftige Namen sowie gute Funktionen, Objekte und Klassen erstellen. Code so formatieren, strukturieren und kommentieren, dass er bestmöglich lesbar ist. Ein vollständiges Fehler-Handling implementieren, ohne die Logik des Codes zu verschleiern. Unit-Tests schreiben und Ihren Code testgesteuert entwickeln. Das Buch „Clean Code“ von „Robert C. Martin“. Lernen Sie, guten Code von schlechtem zu unterscheiden. Sauberen Code schreiben und schlechten Code in guten umwandeln. Aussagekräftige Namen sowie gute Funktionen, Objekte und Klassen erstellen. Code so formatieren, strukturieren und kommentieren, dass er bestmöglich lesbar ist. Ein vollständiges Fehler-Handling implementieren, ohne die Logik des Codes zu verschleiern. Unit-Tests schreiben und Ihren Code testgesteuert entwickeln. 22.05.2009 Ralf Schoch

Professionalität = Bewusstheit + Prinzipien Clean Code Developer Was ist die Idee von CCD? Die Idee Professionalität = Bewusstheit + Prinzipien Softwareentwicklung braucht Profis! Was sind Profis? Ein professioneller Softwareentwickler setzt sich mit dem Metier bewusst auseinander. Ein professioneller Softwareentwickler hat ein inneres Wertesystem. Qualitätsmaßstab oder zumindest einen Erwartungshorizont für Professionalität Kriterien (Software Team, Diplom) Professionalität = Bewusstheit + Prinzipien Softwareentwicklung braucht Profis! Was sind Profis? Ein professioneller Softwareentwickler setzt sich mit dem Metier bewusst auseinander. Ein professioneller Softwareentwickler hat ein inneres Wertesystem. Qualitätsmaßstab oder zumindest einen Erwartungshorizont für Professionalität Kriterien (Software Team, Diplom) 22.05.2009 Ralf Schoch

Professionalität = Bewusstheit + Prinzipien Clean Code Developer Was ist das ? Professionalität = Bewusstheit + Prinzipien Softwareentwicklung braucht Profis. Was aber sind Profis? Menschen die mit der Softwareentwicklung Geld verdienen? Nein, das CcdTeam meint, es gehört mehr und anderes dazu. Professionalität in der Softwareentwicklung hat nichts mit Geld zu tun. Sie hat auch nur bedingt mit einem bestimmten Aus-bildungsweg zu tun. Wir kennen professionelle Software-entwickler, die wenig oder gar kein Geld mit ihrer Software verdienen und wir kennen professionelle Softwareentwickler, die weder Diplom noch Doktortitel haben. 22.05.2009 Ralf Schoch

Sind Grundsätze wie etwas gemacht werden soll. Regeln Clean Code Developer Grundlagen Prinzipien Sind Grundsätze wie etwas gemacht werden soll. Regeln Sind Festlegung, dass etwas gemacht werden soll. Praktien Beschreiben grundlegende Arbeitsweisen. Schwarz Man interessiert sich dafür, setzt sich damit auseinander, aber setzt es noch nicht um. Rot Erster Schritt in die Praxis. Nur die unverzichtbarsten Dinge. Zielsetzung ist die Bildung der richtigen Einstellung zur Softwareentwicklung und hin zum CCD. 22.05.2009 Ralf Schoch

Clean Code Developer Grade der CCD 0. Grad – Schwarz Den schwarze Grad hat jeder, der sich noch nicht auf den Weg gemacht hat. Ein schwarzes Armband signalisiert deshalb nur, dass man sich für CCD interessiert. Man kann es tragen, wenn für den ersten richtigen Grad noch nicht alle Voraussetzungen erfüllt sind. 1. Grad – Rot Der wirkliche Weg zum Clean Code Developer beginnt mit dem roten Grad. Mit dem roten Grad setzt die Übungspraxis ein. Er enthält deshalb nur Elemente des CCD-Wertesystems, die absolut unverzichtbar sind. Der Einstieg soll so leicht wie möglich sein. Auf dieser Stufe geht es deshalb noch nicht so sehr um Softwareentwicklungsprinzipien, als vielmehr um den Aufbau einer fundamentalen Haltung zur Softwareentwicklung und zum Clean Code Developer. Schwarz Man interessiert sich dafür, setzt sich damit auseinander, aber setzt es noch nicht um. Rot Erster Schritt in die Praxis. Nur die unverzichtbarsten Dinge. Zielsetzung ist die Bildung der richtigen Einstellung zur Softwareentwicklung und hin zum CCD. 1.Prinzipien 1.Don´t Repeat Yourself (DRY) 2.Keep it simple, stupid (KISS) 2.Regeln 1.Die Pfadfinderregel beachten 2.Vorsicht vor Optimierungen! 3.Root cause analysis 3.Praktiken 1.Ein Versionskontrollsystem einsetzen 2.Erste Refaktorisierungsmuster anwenden 3.Täglich reflektieren 22.05.2009 Ralf Schoch

Clean Code Developer 2. Grad – Orange Grade der CCD 2. Grad – Orange Nachdem im roten Grad die Grundlagen für den Prozess der kontinuierlichen Verbesserung geschaffen wurden, geht es im orangen Grad darum, einige fundamentale Prinzipien auf den Code anzuwenden und erste Erfahrungen mit dem Mittel Nr. 1 zur Produktivitätssteigerung zu gewinnen: der Automatisierung von Abläufen. Da nur korrekter Code guter Code ist, dient die Automatisierung der Korrektheitsprüfung. Es geht also nicht um eine nice-to-have Eigenschaft von Code, sondern um seine Essenz. Orange Basis ist mir Rot geschaffen 1.Prinzipien 1.One level of abstraction 2.Single Responsibility Principle 3.Separation of Concerns 2.Regeln 1.Source Code Konventionen 3.Praktiken 1.Issue Tracking 2.Automatisierte Integrationstests 3.Lesen, Lesen, Lesen 4.Reviews 22.05.2009 Ralf Schoch

Clean Code Developer 3. Grad – Gelb Grade der CCD 3. Grad – Gelb Der gelbe Grad steht ganz im Zeichen automatisierter Tests. Beim orangen Grad ging es noch um die von außen ansetzbaren Integrationstests. Für sie war nicht unbedingt ein Eingriff in den Code nötig. Ab dem gelben Grad allerdings geht es nicht mehr ohne Tests unter der Oberfläche. Und nicht nur das: getestet werden sollen die kleinstmöglichen Einheiten, nicht nur funktionale Durchstiche. Das bedeutet ein Änderung der Codierungspraxis, denn sonst lassen sich einzelne Klassen nicht isoliert, d.h. unabhängig von genutzten Diensten prüfen. Deshalb gehören zum gelben Grad auch objektorientierte Prinzipien, denn nur mit ihnen ist eine Ablösung von zu testendem Code von seinem "Untergrund" möglich. 1.Prinzipien 1.Interface Segregation Principle 2.Dependency Inversion Principle 3.Dependency Injection (ohne Locator oder Container) 4.Liskov Substitution Principle 2.Praktiken 1.Automatisierte Unit Tests 2.Mockups (Testattrappen) 3.Code Coverage Analyse 4.Teilnahme an Fachveranstaltungen 22.05.2009 Ralf Schoch

Clean Code Developer 4. Grad – Grün Grade der CCD 4. Grad – Grün Im grünen Grad geht es weiter mit der Automatisierung. Die ist einfach der Schlüssel zur Produktivität und Reaktionsfähigkeit. Nur wenn maximal viele Tätigkeiten in der Softwareentwicklung automatisiert sind, kann sich der CCD auf das Wesentliche konzentrieren: die Implementation von Kundenanforder-ungen. Ohne Automatisierung hängt die Entwicklung sonst oft an Kleinigkeiten - das kostet Zeit. Korrektheitsprüfungen und Releases sind dann mehr Strafe denn Mittel zum Erfolg. Nach der Automatisierung der Tests steht jetzt allerdings die Produktion auf dem Plan. Code am Entwicklerarbeits-platz zu testen, ist eine Sache. Ihn auf einem unabhängigen Rechner erfolg-reich zu übersetzen und zu testen, eine andere. Nur so lassen sich mehr oder weniger subtile Abhängigkeiten von den einzelnen Entwicklerarbeitsplätzen finden. Garniert wird diese Praxis dann noch mit weiteren Prinzipien zur Codestrukturierung und einem Werkzeug für bessere Architekturen. 1.Prinzipien 1.Open Closed Principle 2.Tell, don´t ask 3.Law of Demeter 2.Praktiken 1.Continuous Integration I 2.Statische Codeanalyse (Metriken) 3.Dependency Injection 4.Erfahrung weitergeben 22.05.2009 Ralf Schoch

Clean Code Developer 5. Grad – Blau Grade der CCD 5. Grad – Blau Mit dem blauen Grad geht es in die Zielgerade des CCD-Wertesystems. Die Automatisierung ist noch einen Schritt weiter zu treiben. Nach Übersetzung und Test steht jetzt das Deployment auf dem Programm. Vor allem geht es im blauen Grad aber nun um Aspekte der Softwareentwicklung jenseits von Code und Tools: CCD kümmern sich nicht nur um gute Strukturen im Kleinen, sondern planen sie von vornherein im Großen. Es geht also um Architektur. Da wir uns jedoch bewusst sind, dass keine Planung eine perfekte Lösung definieren kann, gehört nicht nur zur Architektur, sondern zur Software-entwicklung insgesamt auch ein passendes Vorgehensmodell. Das ist iterativ und soll während der Arbeit am blauen Grad nun auch eingeübt werden. 1.Prinzipien 1.Entwurf und Implementation überlappen nicht 2.Implementation spiegelt Entwurf 3.Principle of least astonishment 2.Regeln 1.You Ain´t Gonna Need It (YAGNI) 3.Praktiken 1.Continuous Integration II 2.Iterative Entwicklung 3.Komponentenorientierung 4.Test first 22.05.2009 Ralf Schoch

Clean Code Developer 6. Grad – Weiß Grade der CCD 6. Grad – Weiß Im weißen Grad fließen alle Prinzipien, Regeln und Praktiken zusammen. So wie im weißen Licht alle Farben enthalten sind, so enthält der weiße Grad alle anderen Grade. Auf der Ebene des weißen Grades arbeitet ein CCD nur, wenn er ständig das ganze CcdWertesystem im Blick hat. Das macht klar, dass nur wirklich fortgeschrittene Softwareentwickler mit mehreren Jahren Erfahrung und in einer geeigneten Umgebung mit dem weißen Grad arbeiten können. 22.05.2009 Ralf Schoch

Clean Code Developer Bedeutung der Grade Grade der CCD Bedeutung der Grade Die Grade drücken keinen Wert aus. Wer am blauen Grad arbeitet ist nicht "besser" oder "weiter" als jemand, der am orangen Grad arbeitet. Die Grade sind nur ein didaktisches Hilfsmittel, um die Gesamtheit des Wertesystems "einfacher verdaubar" zu machen. Die vielen Werte lassen sich schlicht in kleinen Happen besser aneignen, als in einem Anlauf. Deshalb ist es uns auch wichtig, dass jeder Interessent mit dem roten Grad beginnt. Aus didaktischen Gründen ist es der beste Einstieg - auch wenn man meint, man würde doch auch schon in der täglichen Arbeit andere Werte umsetzen. Denn unabhängig von der heutigen Projektpraxis ist es sicherlich neu, sich so bewusst mit Werten auseinanderzusetzen. Insbesondere die tägliche Reflektion darüber ist wahrscheinlich noch nicht Gewohnheit. Um sie im Kontext "einfacher" Werte zu üben, eignet sich dann der rote Grad. 22.05.2009 Ralf Schoch

Clean Code Developer Bedeutung der Grade Grade der CCD Bedeutung der Grade Auch wenn wir verstehen, dass jeder, der das CcdWertesystem zum ersten Mal sieht, abhaken will, was er davon schon beherzigt, so ist das letztlich unerheblich. Die bewusste Praxis im Rahmen des Wertesystems ist immer neu - und sollte auch wer meint, er "verdiene" eigentlich den weißen Grad, beim roten Grad beginnen. Es geht eben nicht um "Verdienst", sondern um Iterationen und kleine Happen. Grade sind Gucklöcher auf das große Ganze. Wer das erste Armband bestellt, bestelle also am besten das rote Armband. 22.05.2009 Ralf Schoch

Bedeutung der Armbänder Clean Code Developer Grade der CCD – Die Armbänder Bedeutung der Armbänder Arbeitsmittel Täglich Reflektion Verstoß gegen Prinzip des Grades oder vorhergehende Ziel Bewusstes Handeln Wahrnehmung 22.05.2009 Ralf Schoch

Don‘t Repeat Yourself (DRY) Keep it simple, stupid (KISS) Regeln Clean Code Developer 1. Grad der CCD Roter Grad Prinzipien Don‘t Repeat Yourself (DRY) Keep it simple, stupid (KISS) Regeln Die Pfadfinderregel beachten Vorsicht vor Optimierungen! Root cause analysis (Ursachenanalyse) Praktiken Ein Versionskontrollsystem benutzen Erste Refaktorisierungsmuster anwenden Täglich reflektieren Prinzipien Don‘t Repeat Yourself (DRY) Keep it simple, stupid (KISS) Regeln Die Pfadfinderregel beachten Vorsicht vor Optimierungen! Root cause analysis Praktiken Ein Versionskontrollsystem benutzen Erste Refaktorisierungsmuster anwenden Täglich reflektieren 22.05.2009 Ralf Schoch

DRY – Don‘t repeat your self Erstes Prinzip: Nicht wiederholen Clean Code Developer 1. Grad der CCD - Prinzipien DRY – Don‘t repeat your self Erstes Prinzip: Nicht wiederholen Inkonsistenzen & Fehler werden vermieden Unterprogramme, Klassen, Methoden etc. Kein Paste & Copy Immer beachten Wiederholungen von sich und anderen erkennen Bereinigung von Wiederholungen durch Refactoring DRY – Don‘t repeat your self Erstes Prinzip: Nicht wiederholen Inkonsistenzen & Fehler werden vermieden Unterprogramme, Klassen, Methoden etc. Kein Paste & Copy Immer beachten Wiederholungen von sich und anderen erkennen Bereinigung von Wiederholungen durch Refactoring 22.05.2009 Ralf Schoch

KISS – Keep it simple, stupid Verständlichkeit des Codes Clean Code Developer 1. Grad der CCD - Prinzipien KISS – Keep it simple, stupid Verständlichkeit des Codes Voraussetzung für Evoluierbarkeit Alarm! Wenn man eigenen Code nicht mehr versteht! Andere Entwickler müssen den Code verstehen. Fehleranfälligkeit bei komplexen Lösungen höher Reviews & Pair Programming KISS – Keep it simple, stupid Verständlichkeit des Codes Voraussetzung für Evoluierbarkeit Alarm! Wenn man eigenen Code nicht mehr versteht! Andere Entwickler müssen den Code verstehen. Fehleranfälligkeit bei komplexen Lösungen höher Reviews & Pair Programming 22.05.2009 Ralf Schoch

Vermeidet „Broken Window“ Phänomen Clean Code Developer 1. Grad der CCD - Regeln Pfadfinderregel „Hinterlasse einen Ort immer in einem besseren Zustand als Du ihn vorgefunden hast.“ Vermeidet „Broken Window“ Phänomen CCD geht nicht von einem Tag auf den anderen Schritt für Schritt Bsp.: Code ausserhalb VV wird eingecheckt Wiederholungen werden entfernt. Pfadfinderregel „Hinterlasse einen Ort immer in einem besseren Zustand als Du ihn vorgefunden hast.“ Vermeidet „Broken Window“ Phänomen CCD geht nicht von einem Tag auf den anderen Schritt für Schritt Bsp.: Code ausserhalb VV wird eingecheckt Wiederholungen werden entfernt. 22.05.2009 Ralf Schoch

Vorsicht vor Optimierung Warum? Es funktioniert doch! Clean Code Developer 1. Grad der CCD - Regeln Vorsicht vor Optimierung Warum? Es funktioniert doch! Optimieren ist eine Veränderung an der Funktion oder am Prozess. Optimieren kostet immer Aufwand. Ziel ist Verständlichkeit und Evolierbarkeit des Codes. Meist Widerspruch zu optimiertem Code! Muss guten Grund für Optimierung geben: Kundenwunsch! Optimierung nur nach detaillierter Analyse. (Profiler) Vorsicht vor Optimierung Warum? Es funktioniert doch! Optimieren ist eine Veränderung an der Funktion oder am Prozess. Optimieren kostet immer Aufwand. Ziel ist Verständlichkeit und Evolierbarkeit des Codes. Meist Widerspruch zu optimiertem Code! Muss guten Grund für Optimierung geben: Kundenwunsch! Optimierung nur nach detaillierter Analyse. (Profiler) M.A. Jackson: Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. 22.05.2009 Ralf Schoch

Sympthome behandeln bringt oft schnelle Lösung. Clean Code Developer 1. Grad der CCD - Regeln Ursachenforschung Sympthome behandeln bringt oft schnelle Lösung. Behebt aber nicht das Problem. Problem immer nach der wahren Wurzel des Übels suchen. Aufwand bei Sympthomebehandlung oft höher. Ursachenforschung ist Dienst an Verständlichkeit und Aufwand. Prinzipien Don‘t Repeat Yourself (DRY) Keep it simple, stupid (KISS) Regeln Die Pfadfinderregel beachten Vorsicht vor Optimierungen! Root cause analysis Praktiken Ein Versionskontrollsystem benutzen Erste Refaktorisierungsmuster anwenden Täglich reflektieren 22.05.2009 Ralf Schoch

Versionskontrollsystem Warum? „Never Touch a Running System“. Clean Code Developer 1. Grad der CCD - Praktiken Versionskontrollsystem Warum? „Never Touch a Running System“. Angst davor ein laufendes System zu beschädigen. Versionsverwaltung befreit von Angst. Angstfreiheit ist Voraussetzung für Änderungen. Zeitmaschine für Code Basis für Lernen Lernen aus Fehlern Mit Versionsverwaltung darf man Fehler machen! Sie können jederzeit wieder rückgängig gemacht werden. Versionskontrollsystem Warum? „Never Touch a Running System“. Angst davor ein laufendes System zu beschädigen. Versionsverwaltung befreit von Angst. Angstfreiheit ist Voraussetzung für Änderungen. Zeitmaschine für Code Basis für Lernen Lernen aus Fehlern Mit Versionsverwaltung darf man Fehler machen! Sie können jederzeit wieder rückgängig gemacht werden. 22.05.2009 Ralf Schoch

Methoden extrahieren (DRY) Methode umbenennen (Pfadfinderregel) Clean Code Developer 1. Grad der CCD - Praktiken Refactoringmuster Einfache Muster Methoden extrahieren (DRY) Methode umbenennen (Pfadfinderregel) Pflichtlektüre: Clean Code Refactoringmuster Einfache Muster Methoden extrahieren Methode umbenennen Einfach, aber nicht verbindlich für Rote Stufe Schnittstellen extrahieren Oberklasse extrahieren Unterklasse extrahieren Methode nach oben verschieben Methode verschieben 22.05.2009 Ralf Schoch

Warum: Keine Verbesserung, keine Lernen ohne Reflektion Clean Code Developer 1. Grad der CCD - Praktiken Täglich reflektieren Warum: Keine Verbesserung, keine Lernen ohne Reflektion Einplanen in Tagesprozess Kleinschrittige Planung („Teile & Herrsche“) Reflexion nach jedem Schritt Tagesplanung für Entwickler („Scrum“) Keine Arbeit mit in den Feierabend nehmen Reflektion, ob alle Schritte des Grades eingehalten wurden Bei Verstoß nachbessern od. Aufgabe für den nächsten Tag Wird beides nicht gemacht: Wechsel des Armbands auf den anderen Arm! 21 Tage kein Wechsel, dann nächstes Armband Täglich reflektieren Warum: Keine Verbesserung, keine Lernen ohne Reflektion Einplanen in Tagesprozess Kleinschrittige Planung („Teile & Herrsche“) Reflexion nach jedem Schritt Tagesplanung für Entwickler („Scrum“) Keine Arbeit mit in den Feierabend nehmen Reflektion, ob alle Schritte des Grades eingehalten wurden Bei Verstoß nachbessern od. Aufgabe für den nächsten Tag Wird beides nicht gemacht: Wechsel des Armbands auf den anderen Arm! 21 Tage kein Wechsel, dann nächstes Armband (Arbeitsweise wurde verinnerlicht) 22.05.2009 Ralf Schoch

Praxis Clean Code Developer Aus der Praxis … 22.05.2009 Ralf Schoch Prinzipien Don‘t Repeat Yourself (DRY) Keep it simple, stupid (KISS) Regeln Die Pfadfinderregel beachten Vorsicht vor Optimierungen! Root cause analysis Praktiken Ein Versionskontrollsystem benutzen Erste Refaktorisierungsmuster anwenden Täglich reflektieren 22.05.2009 Ralf Schoch

Clean Code Developer Beispiel: Bessere Lösung: Aus der Praxis: Aussagekräftige Namen Beispiel: int d; // elapsed time in days Bessere Lösung: int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays; Aussagekräftige Namen So viel Informationen wie möglich! Eindeutig! 22.05.2009 Ralf Schoch

Clean Code Developer Beispiel: Bessere Lösung: accountList Aus der Praxis: Aussagekräftige Namen – Fehlinformationen vermeiden Beispiel: accountList Eine Liste hat für einen Entwickler eine spezielle Bedeutung. accountList muss aber nicht zwingend eine Liste im Sinn von Progarmmierung sein. Bessere Lösung: accountGroup; bunchOfAccounts Accounts Sinnvolle Bezeichnungen wählen. Keine 22.05.2009 Ralf Schoch

Clean Code Developer Beispiel: int a = l; if (O == l) a = O1; else Aus der Praxis: Aussagekräftige Namen – Fehlinformationen vermeiden Beispiel: int a = l; if (O == l) a = O1; else l = 01; Kleine “L” und grosses “o” sind keine sinnvollen Variablennamen. Führen leicht zu Verwechslungen mit 1 und 0. 22.05.2009 Ralf Schoch

Clean Code Developer Beispiel: Bessere Lösung: Aus der Praxis: Aussagekräftige Namen – Namen ohne Aussagekraft Beispiel: Public void copychars( char a1[], char a2[]){ for (int i=0; i<a1.length; i++){ a2[i] = a1[i]; } } Bessere Lösung: Public void copychars( char source[], char destination[]){ for (int i=0; i<source.length; i++){ destination[i] = source[i]; } } 22.05.2009 Ralf Schoch

Clean Code Developer Beispiel: Aus der Praxis: Aussagekräftige Namen – Bedeutungslose Namen Beispiel: class Product; class ProductInfo; class ProductData; Zusätze wie “Info” oder “Data” sind ziemlich nichts sagend bzw. Redundant. Solche Zusätze besser weg lassen. Das gleiche gilt für Prefixe wie a, an, the. Ausnahme ist, wenn diesen eine Bedeutung zugeordnet ist. z.B. Alle lokalen Variablen fangen mit a an, alle functions Parameter mit the. 22.05.2009 Ralf Schoch

Clean Code Developer Beispiel: Aus der Praxis: Aussagekräftige Namen – Bedeutungslose Namen Beispiel: Customer; CustomerObject; Name; NameString; Zusätze wie “Object” oder “String” sind in bestimmten Programmiersprachen (z.B. Java, C#) nicht sinnvoll. 22.05.2009 Ralf Schoch

Clean Code Developer Beispiel: Bessere Lösung: Aus der Praxis: Aussagekräftige Namen – Sprechbare Namen Beispiel: class DtaRcrd102 { private Date genymdhms; private Date modymdhms; private final String pszyint = “102”; } Bessere Lösung: class Customer { private Date generationTimeStamp; private Date modificationTimeStamp; private final String recordID = “102”; } 22.05.2009 Ralf Schoch

Clean Code Developer Beispiel: Aus der Praxis: Aussagekräftige Namen – Suchbare Namen Beispiel: for (int j=0; j<34; j++) { S += (t[j]*4/5) } Es ist nicht möglich nach den obigen Variablen zu suchen! Bei der Suche nach “5” werden alle vorkommen von 5 gefunden. Hier wären sprechende Namen besser um bei Änderungen gezielt danach Suchen zu können. 22.05.2009 Ralf Schoch

Clean Code Developer Bessere Lösung: Aus der Praxis: Aussagekräftige Namen – Suchbare Namen Bessere Lösung: int realDaysPerIdealDay = 4; const int WORK_DAYS_PER_WEEK = 5; int sum = 0; for (int j=0; j<NUMBER_OF_TASKS; j++){ int realTaskDays = TasksEstimate[j]*realDaysPerIdealDay; int realTaskWeeks = (realdays / WORK_DAYS_PER_WEEK) ; sum += realTaskWeeks; } Es ist einfacher nach WORK_DAYS_PER_WEEK zu suchen. 22.05.2009 Ralf Schoch

Demo „VariablesWithClearContect.cs“ Clean Code Developer Etwas Praxis … Sinnvoller Context Demo „VariablesWithClearContect.cs“ Beispiel aus „Clean Code“ auf C# adaptiert 22.05.2009 Ralf Schoch

Clean Code (eng), Robert C. Martin ISBN 0132350882 Clean Code Developer Literatur Clean Code (eng), Robert C. Martin ISBN 0132350882 Clean Code (ger), Robert C. Martin ISBN 3826655486 Refactoring to Patterns, Joshua Kerievsky  ISBN 3827322626 22.05.2009 Ralf Schoch

Clean Code Developer http://clean-code-developer.de/ Links Clean Code Developer http://clean-code-developer.de/ CCD Grade http://clean-code-developer.de/wiki/CcdGrade Tools http://clean-code-developer.de/wiki/CcdWerkzeugliste Ralf Westphal http://ralfw.de Stephan Lieser http://www.lieser-online.de 22.05.2009 Ralf Schoch

Clean Code Developer Fragen 22.05.2009 Ralf Schoch