Book description
- Kommentare, Formatierung, Strukturierung
- Fehler-Handling und Unit-Tests
- Zahlreiche Fallstudien, Best Practices, Heuristiken und Code Smells
- 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
Table of contents
- Impressum
- Vorwort
- Einführung
- Kapitel 1: Sauberer Code
-
Kapitel 2: Aussagekräftige Namen
- 2.1 Einführung
- 2.2 Zweckbeschreibende Namen wählen
- 2.3 Fehlinformationen vermeiden
- 2.4 Unterschiede deutlich machen
- 2.5 Aussprechbare Namen verwenden
- 2.6 Suchbare Namen verwenden
- 2.7 Codierungen vermeiden
- 2.8 Mentale Mappings vermeiden
- 2.9 Klassennamen
- 2.10 Methodennamen
- 2.11 Vermeiden Sie humorige Namen
- 2.12 Wählen Sie ein Wort pro Konzept
- 2.13 Keine Wortspiele
- 2.14 Namen der Lösungsdomäne verwenden
- 2.15 Namen der Problemdomäne verwenden
- 2.16 Bedeutungsvollen Kontext hinzufügen
- 2.17 Keinen überflüssigen Kontext hinzufügen
- 2.18 Abschließende Worte
-
Kapitel 3: Funktionen
- 3.1 Klein!
- 3.2 Eine Aufgabe erfüllen
- 3.3 Eine Abstraktionsebene pro Funktion
- 3.4 Switch-Anweisungen
- 3.5 Beschreibende Namen verwenden
- 3.6 Funktionsargumente
- 3.7 Nebeneffekte vermeiden
- 3.8 Anweisung und Abfrage trennen
- 3.9 Ausnahmen sind besser als Fehler-Codes
- 3.10 Don’t Repeat Yourself
- 3.11 Strukturierte Programmierung
- 3.12 Wie schreibt man solche Funktionen?
- 3.13 Zusammenfassung
- 3.14 SetupTeardownIncluder
-
Kapitel 4: Kommentare
- 4.1 Kommentare sind kein Ersatz für schlechten Code
- 4.2 Erklären Sie im und durch den Code
- 4.3 Gute Kommentare
-
4.4 Schlechte Kommentare
- Geraune
- Redundante Kommentare
- Irreführende Kommentare
- Vorgeschriebene Kommentare
- Tagebuch-Kommentare
- Geschwätz
- Beängstigendes Geschwätz
- Verwenden Sie keinen Kommentar, wenn Sie eine Funktion oder eine Variable verwenden können
- Positionsbezeichner
- Kommentare hinter schließenden Klammern
- Zuschreibungen und Nebenbemerkungen
- Auskommentierter Code
- HTML-Kommentare
- Nicht-lokale Informationen
- Zu viele Informationen
- Unklarer Zusammenhang
- Funktions-Header
- Javadocs in nicht-öffentlichem Code
- Beispiel
- Kapitel 5: Formatierung
- Kapitel 6: Objekte und Datenstrukturen
-
Kapitel 7: Fehler-Handling
- 7.1 Ausnahmen statt Rückgabe-Codes
- 7.2 Try-Catch-Finally-Anweisungen zuerst schreiben
- 7.3 Unchecked Exceptions
- 7.4 Ausnahmen mit Kontext auslösen
- 7.5 Definieren Sie Exception-Klassen mit Blick auf die Anforderungen des Aufrufers
- 7.6 Den normalen Ablauf definieren
- 7.7 Keine Null zurückgeben
- 7.8 Keine Null übergeben
- 7.9 Zusammenfassung
- Kapitel 8: Grenzen
- Kapitel 9: Unit-Tests
- Kapitel 10: Klassen
-
Kapitel 11: Systeme
- 11.1 Wie baut man eine Stadt?
- 11.2 Konstruktion und Anwendung eines Systems trennen
- 11.3 Aufwärtsskalierung
- 11.4 Java-Proxies
- 11.5 Reine Java-AOP-Frameworks
- 11.6 AspectJ-Aspekte
- 11.7 Die Systemarchitektur testen
- 11.8 Die Entscheidungsfindung optimieren
- 11.9 Standards weise anwenden, wenn sie nachweisbar einen Mehrwert bieten
- 11.10 Systeme brauchen domänenspezifische Sprachen
- 11.11 Zusammenfassung
- Kapitel 12: Emergenz
-
Kapitel 13: Nebenläufigkeit
- 13.1 Warum Nebenläufigkeit?
- 13.2 Herausforderungen
- 13.3 Prinzipien einer defensiven Nebenläufigkeitsprogrammierung
- 13.4 Lernen Sie Ihre Library kennen
- 13.5 Lernen Sie Ihre Ausführungsmodelle kennen
- 13.6 Achten Sie auf Abhängigkeiten zwischen synchronisierten Methoden
- 13.7 Halten Sie synchronisierte Abschnitte klein
- 13.8 Korrekten Shutdown-Code zu schreiben, ist schwer
-
13.9 Threaded-Code testen
- Behandeln Sie gelegentlich auftretende Fehler als potenzielle Threading-Probleme
- Bringen Sie erst den Nonthreaded-Code zum Laufen
- Machen Sie Ihren Threaded-Code pluggable
- Schreiben Sie anpassbaren Threaded-Code
- Den Code mit mehr Threads als Prozessoren ausführen
- Den Code auf verschiedenen Plattformen ausführen
- Code-Scheitern durch Instrumentierung provozieren
- Manuelle Codierung
- Automatisiert
- 13.10 Zusammenfassung
- Kapitel 14: Schrittweise Verfeinerung
- Kapitel 15: JUnit im Detail
- Kapitel 16: Refactoring von SerialDate
-
Kapitel 17: Smells und Heuristiken
- 17.1 Kommentare
- 17.2 Umgebung
- 17.3 Funktionen
-
17.4 Allgemein
- G1: Mehrere Sprachen in einer Quelldatei
- G2: Offensichtliches Verhalten ist nicht implementiert
- G3: Falsches Verhalten an den Grenzen
- G4: Übergangene Sicherungen
- G5: Duplizierung
- G6: Auf der falschen Abstraktionsebene codieren
- G7: Basisklasse hängt von abgeleiteten Klassen ab
- G8: Zu viele Informationen
- G9: Toter Code
- G10: Vertikale Trennung
- G11: Inkonsistenz
- G12: Müll
- G13: Künstliche Kopplung
- G14: Funktionsneid
- G15: Selektor-Argumente
- G16: Verdeckte Absicht
- G17: Falsche Zuständigkeit
- G18: Fälschlich als statisch deklarierte Methoden
- G19: Aussagekräftige Variablen verwenden
- G20: Funktionsname sollte die Aktion ausdrücken
- G21: Den Algorithmus verstehen
- G22: Logische Abhängigkeiten in physische umwandeln
- G23: Polymorphismus statt If/Else oder Switch/Case verwenden
- G24: Konventionen beachten
- G25: Magische Zahlen durch benannte Konstanten ersetzen
- G26: Präzise sein
- G27: Struktur ist wichtiger als Konvention
- G28: Bedingungen einkapseln
- G29: Negative Bedingungen vermeiden
- G30: Eine Aufgabe pro Funktion!
- G31: Verborgene zeitliche Kopplungen
- G32: Keine Willkür
- G33: Grenzbedingungen einkapseln
- G34: In Funktionen nur eine Abstraktionsebene tiefer gehen
- G35: Konfigurierbare Daten hoch ansiedeln
- G36: Transitive Navigation vermeiden
- 17.5 Java
- 17.6 Namen
-
17.7 Tests
- T1: Unzureichende Tests
- T2: Ein Coverage-Tool verwenden
- T3: Triviale Tests nicht überspringen
- T4: Ein ignorierter Test zeigt eine Mehrdeutigkeit auf
- T5: Grenzbedingungen testen
- T6: Bei Bugs die Nachbarschaft gründlich testen
- T7: Das Muster des Scheiterns zur Diagnose nutzen
- T8: Hinweise durch Coverage-Patterns
- T9: Tests sollten schnell sein
- 17.8 Zusammenfassung
-
Anhang A: Nebenläufigkeit II
- A.1 Client/Server-Beispiel
- A.2 Mögliche Ausführungspfade
- A.3 Lernen Sie Ihre Library kennen
- A.4 Abhängigkeiten zwischen Methoden können nebenläufigen Code beschädigen
- A.5 Den Durchsatz verbessern
- A.6 Deadlock
- A.7 Multithreaded-Code testen
- A.8 Threadbasierten Code mit Tools testen
- A.9 Zusammenfassung
- A.10 Tutorial: kompletter Beispielcode
- Anhang B: org.jfree.date.SerialDate
- Anhang C: Literaturverweise
- Epilog
Product information
- Title: Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code
- Author(s):
- Release date: March 2009
- Publisher(s): mitp Verlag
- ISBN: 9783826655487
You might also like
book
Clean Coder - Verhaltensregeln für professionelle Programmierer
Erfolgreiche Programmierer haben eines gemeinsam: Die Praxis der Software-Entwicklung ist ihnen eine Herzensangelegenheit. Auch wenn sie …
book
Refactoring -- Wie Sie das Design bestehender Software verbessern
Umfassend überarbeitete und aktualisierte Neuauflage des Standardwerks in vollständig neuer Übersetzung Verbesserungsmöglichkeiten von bestehender Software anhand …
book
Design Patterns - Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software
Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software Der Bestseller von Gamma und Co. in komplett neuer Übersetzung …
book
C++ - Lernen und professionell anwenden
Gezielter Lernerfolg durch überschaubare Kapiteleinheiten Vollständige Darstellung – Schritt für Schritt Konsequent objektorientiert programmieren Sie möchten …