UID:
kobvindex_GFZ591541912
Format:
475 Seiten
,
Illustrationen, Diagramme
,
240 mm x 170 mm
Edition:
1. Auflage
ISBN:
3826655486 (PB.)
,
9783826655487 (PB.)
Uniform Title:
Clean code 〈dt.〉
Note:
Inhaltsverzeichnis
Vorwort
Einführung
1 Sauberer Code
1.1 Code, Code und nochmals Code
1.2 Schlechter Code
1.3 Die Lebenszykluskosten eines Chaos
Das große Redesign in den Wolken
Einstellung
Das grundlegende Problem
Sauberen Code schreiben - eine Kunst?
Was ist sauberer Code?
1.4 Denkschulen
1.5 Wir sind Autoren
1.6 Die Pfadfinder-Regel
1.7 Vorläufer und Prinzipien
1.8 Zusammenfassung
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
Ungarische Notation
Member-Präfixe
Interfaces und Implementierungen
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
3 Funktionen
3.1 Klein!
Blöcke und Einrückungen
3.2 Eine Aufgabe erfüllen
Abschnitte innerhalb von Funktionen
3.3 Eine Abstraktionsebene pro Funktion
Code Top-down lesen: die Stepdown-Regel
3.4 Switch-Anweisungen
3.5 Beschreibende Namen verwenden
3.6 Funktionsargumente
Gebräuchliche monadische Formen
Flag-Argumente
Dyadische Funktionen
Triaden
Argument-Objekte
Argument-Listen
Verben und Schlüsselwörter
3.7 Nebeneffekte vermeiden
Output-Argumente
3.8 Anweisung und Abfrage trennen
3.9 Ausnahmen sind besser als Fehler-Codes
Try/Catch-Blöcke extrahieren
Fehler-Verarbeitung ist eine Aufgabe
Der Abhängigkeitsmagnet Error.java
3.10 Don't Repeat Yourself
3.11 Strukturierte Programmierung
3.12 Wie schreibt man solche Funktionen?
3.13 Zusammenfassung
3.14 SetupTeardownlnduder
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
Juristische Kommentare
Informierende Kommentare
Erklärung der Absicht
Klarstellungen
Warnungen vor Konsequenzen
TODO-Kommentare
Verstärkung
Javadocs in öffentlichen APIs
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
5 Formatierung
5.1 Der Zweck der Formatierung
5.2 Vertikale Formatierung
Die Zeitungs-Metapher
Vertikale Offenheit zwischen Konzepten
Vertikale Dichte
Vertikaler Abstand
Vertikale Anordnung
5.3 Horizontale Formatierung
Horizontale Offenheit und Dichte
Horizontale Ausrichtung
Einrückung
Dummy-Bereiche
5.4 Team-Regeln
5.5 Uncle Bobs Formatierungsregeln
6 Objekte und Datenstrukturen
6.1 Datenabstraktion
6.2 Daten/Objekt-Anti-Symmetrie
6.3 Das Law of Demeter
Zugkatastrophe
Hybride
Struktur verbergen
6.4 Datentransfer-Objekte
Active Record
6.5 Zusammenfassung
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
8 Grenzen
8.1 Mit Drittanbieter-Code arbeiten
8.2 Grenzen erforschen und kennen lernen
8.3 log4J kennen lernen
8.4 Lern-Tests sind besser als kostenlos
8.5 Code verwenden, der noch nicht existiert
8.6 Saubere Grenzen
9 Unit-Tests
9.1 Die drei Gesetze der TDD
9.2 Tests sauber halten
Tests ermöglichen die -heiten und -keiten
9.3 Saubere Tests
Domänenspezifische Testsprache
Ein Doppelstandard
9.4 Ein assert pro Test
Ein Konzept pro Test
9.5 F.I.R.S.T
9.6 Zusammenfassung
10 Klassen
10.1 Klassenaufbau
Einkapselung
10.2 Klassen sollten klein sein!
Fünf Methoden sind nicht zu viel, oder?
Das Single-Responsibility-Prinzip
Kohäsion
Kohäsion zu erhalten, führt zu vielen kleinen Klassen
10.3 Änderungen einplanen
Änderungen isolieren
11 Systeme
11.1 Wie baut man eine Stadt?
11.2 Konstruktion und Anwendung eines Systems trennen
Trennung in main
Factories
Dependency Injection
11.3 Aufwärtsskalierung
Cross-Cutting Concerns
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 nachweisbareinen Mehrwert bieten
11.10 Systeme brauchen domänenspezifische Sprachen
11.11 Zusammenfassung
12 Emergenz
12.1 Saubere Software durch emergentes Design
12.2 Einfache Design-Regel 1: Alle Tests bestehen
12.3 Einfache Design-Regeln 2-4: Refactoring
12.4 Keine Duplizierung
12.5 Ausdrucksstärke
12.6 Minimale Klassen und Methoden
12.7 Zusammenfassung
13 Nebenläufigkeit
13.1 Warum Nebenläufigkeit?
Mythen und falsche Vorstellungen
13.2 Herausforderungen
13.3 Prinzipien einer defensiven Nebenläufigkeitsprogrammierung
Single-Responsibility-Prinzip
Korollar: Beschränken Sie den Gültigkeitsbereich von Daten
Korollar: Arbeiten Sie mit Kopien der Daten
Korollar: Threads sollten voneinander so unabhängig wie möglich sein
13.4 Lernen Sie Ihre Library kennen
Thread-sichere Collections
13.5 Lernen Sie Ihre Ausführungsmodelle kennen
Erzeuger-Verbraucher
Leser-Schreiber
Philosophenproblem
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-Scheitem durch Instrumentierung provozieren
Manuelle Codierung
Automatisiert
13.10 Zusammenfassung
14 Schrittweise Verfeinerung
14.1 Args-Implementierung
Wie habe ich dies gemacht?
14.2 Args: der Rohentwurf
Deshalb hörte ich auf
Über inkrementelle Entwicklung
14.3 String-Argumente
14.4 Zusammenfassung
15 JUnit im Detail
15.1 Das JUnit-Framework
15.2 Zusammenfassung
16 Refactoring von SerialDate
16.1 Zunächst bring es zum Laufen!
16.2 Dann mach es richtig!
16.3 Zusammenfassung
17 Smells und Heuristiken
17.1 Kommentare
C1: Ungeeignete Informationen
C2: Überholte Kommentare
C3: Redundante Kommentare
C4: Schlecht geschriebene Kommentare
C5: Auskommentierter Code
17.2 Umgebung
E1: Ein Build erfordert mehr als einen Schritt
E2: Tests erfordern mehr als einen Schritt
17.3 Funktionen
F1: Zu viele Argumente
F2: Output-Argumente
F3: Flag-Argumente
F4: Tote 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 Bedingunge
Language:
German
Subjects:
Computer Science
Keywords:
Lehrbuch
URL:
https://d-nb.info/992430380/04
Author information:
Martin, Robert C.
Author information:
Feathers, Michael C.
Bookmarklink