Sauberer Code. A Good Programmer's Handbook - Robert C. Martin - Eingestelltes Produkt

Warnung!

Das Buch wurde durch eine Neuauflage ersetzt - check it out!

Inhalt

Vorwort (13)

Einführung (19)

1. Sauberer Code (23)

• Lass es einen Code geben ... (24)
• Auf der Suche nach dem perfekten Code ... (24)
• Gesamtkosten der Unordnung (25)
  
  • Große Designänderung starten (26)
  • Haltung (27)
  • Das größte Rätsel (28)
  • Die Kunst des sauberen Codes? (28)
  • Was ist Clean-Code? (28)
• Denkschulen (34)
• Wir sind die Autoren (35)
• Pfadfinderprinzip (36)
• Vorgänger und Prinzipien (36)
• Ende (36)
• Bibliographie (37)

2. Bedeutende Namen (39)

• Einführung (39)
• Verwenden Sie Namen, die die Absichten darstellen (40)
• Vermeidung von Desinformation (41)
• Klare Unterschiede schaffen (42)
• Aussprechbare Namen erstellen (43)
• Verwenden von leicht zu findenden Namen (44)
• Kodierung vermeiden
  
  • Ungarische Notation (45)
  • Zutatenpräfixe (46)
  • Schnittstellen und Implementierungen (46)
• Vermeidung von mentalem Mapping (47)
• Klassennamen
• Methodennamen
• Sei nicht lustig (48)
• Wählen Sie ein Wort pro Konzept (48)
• Machen Sie keine Wortspiele! (49)
• Verwenden von Lösungsdomänennamen
• Verwenden problematischer Domänennamen 49
• Sinnvollen Kontext hinzufügen 50
• Redundanter Kontext sollte nicht hinzugefügt werden 51
• Schlusswort (52)

3. Eigenschaften (53)

• Kleine Funktionen! (56)
  
  • Blöcke und Einzüge (57)
• Eine Sache tun (57)
  
  • Abschnitte innerhalb von Funktionen
• Eine Abstraktionsebene in einer Funktion 58
  
  • Lesen von Code von oben nach unten - von oben nach unten (58)
• Switch-Anweisungen
• Beschreibende Namen verwenden 61
• Funktionsargumente
  
  • Häufig verwendete unäre Funktionen 62
  • Tag-Argumente
  • Binäre Funktionen 63
  • Drei Argumentfunktionen
  • Objektorientierte Argumente
  • Argumente
  • Verben und Schlüsselwörter (65)
• Vermeidung von Nebenwirkungen (65)
  
  • Die Ausgangsargumente
• Trennen von Befehlen und Abfragen
• Ausnahmen verwenden, anstatt Fehlercodes zurückzugeben 67
  
  • Try-Catch-Blöcke extrahieren 68
  • Die Fehlerbehandlung ist eine Operation 69
  • Snapping-Abhängigkeiten in Error.java
• Wiederhole dich nicht (69)
• Strukturelle Programmierung (70)
• Wie schreibt man solche Funktionen? (70)
• Ende (71)
• SetupTeardownIncluder (71)
• Bibliographie (73)

4. Kommentare (75)

• Kommentare sind kein Lippenstift für einen schlechten Code (77)
• Lesbarer Code erfordert keine Kommentare (77)
• Gute Kommentare (77)
  
  • Rechtliche Hinweise (77)
  • Informative Kommentare (78)
  • Klärung der Absichten (78)
  • Erklären (79)
  • Folgewarnungen (80)
  • TODO-Kommentare (80)
  • Stärkung (81)
  • Javadoc-Kommentare in der öffentlichen API
• Schlechte Kommentare (81)
  
  • Geplapper (81)
  • Sich wiederholende Kommentare (82)
  • Verwirrende Kommentare (84)
  • Kommentare erforderlich (85)
  • Zeitschriftenkommentare (85)
  • Lärm Einleitende Bemerkungen (86)
  • Gruseliger Rummel (87)
  • Verwenden Sie keine Kommentare, wenn eine Funktion oder Variable verwendet werden kann 88
  • Positionsmarker (88)
  • Schließende Klammer Kommentare (88)
  • Attribute und Anmerkungen (89)
  • Kommentierter Code (89)
  • HTML-Kommentare (90)
  • Nicht-lokale Informationen (91)
  • Informationsüberflutung (91)
  • Nicht offensichtliche Verbindungen (91)
  • Funktionsüberschriften (92)
  • Javadoc-Kommentare in nicht öffentlichem Code
  • Beispiel (92)
• Bibliographie (95)

5. Formatierung (97)

• Zweck der Formatierung
• Hochformat (98)
  
  • Zeitungsmetapher (99)
  • Vertikaler Abstand zwischen Codesegmenten (99)
  • Vertikale Dichte (101)
  • Höhenabstand (101)
  • Vertikale Anordnung 105
• Horizontale Formatierung (106)
  
  • Horizontaler Abstand und Dichte (106)
  • Horizontale Anordnung (107)
  • Vertiefungen (109)
  • Leere Bereiche (110)
• Teamprinzipien (110)
• Onkel Bobs Formatierungsregeln (111)

6. Datenobjekte und Strukturen (113)

• Datenabstraktion 113
• Daten- und Objektantisymmetrie
• Demetergesetz (117)
  
  • Zugwracks (118)
  • Hybriden (118)
  • Struktur verbergen 119
• Datenübertragungsobjekte
  
  • Aktiver Datensatz (120)
• Ende (121)
• Bibliographie (121)

7. Fehlerbehandlung (123)

• Verwenden von Ausnahmen anstelle von Rückgabecodes 124
• Beginnen Sie mit dem Schreiben einer Try-Catch-Finally-Anweisung 125
• Verwenden von unkontrollierten Ausnahmen 126
• Bereitstellung von Kontext mithilfe von Ausnahmen 127
• Ausnahmeklassen gemäß den Anforderungen des Anrufers definieren 127
• Definition des normalen Flusses 129
• Wir geben nicht null zurück (130)
• Nicht null übergeben (131)
• Ende (132)
• Bibliographie (132)

8. Grenzen (133)

• Anwendung von Fremdcode (134)
• Grenzen sehen und lernen
• Verwenden des log4j-Pakets 136
• Die Vorteile von Lehrtests 138
• Verwenden von nicht vorhandenem Code 138
• Saubere Grenzen (139)
• Bibliographie (140)

9. Einheitentests (141)

• Die drei Gesetze von TDD 142
• Tests sauber halten (143)
  
  • Tests erhöhen die Möglichkeiten (144)
• Saubere Tests (144)
  
  • Domänenspezifische Testsprachen
  • Doppelmoral (147)
• Eine Behauptung pro Test
  
  • Ein Konzept pro Test (150)
• ERSTER (151)
• Ende (152)
• Bibliographie (152)

10. Klassen (153)

• Unterrichtsorganisation (153)
  
  • Verkapselung (154)
• Klassen sollten klein sein! (154)
  
  • Grundsatz der Einzelverantwortung (156)
  • Zusammenhalt (158)
  • Das Aufrechterhalten der Konsistenz erzeugt viele kleine Klassen 158
• Veränderung managen 164
  
  • Codemodule von Änderungen isolieren
• Bibliographie (167)

11. Systeme (169)

• Wie würdest du eine Stadt bauen? (170)
• Trennen des Systemaufbaus von der Systemnutzung 170
  
  • Isolierung des Hauptmoduls 171
  • Fabriken (172)
  • Abhängigkeitsinjektion 172
• Hochskalieren (173)
  
  • Probleme isolieren (zerlegen) 176
• Java-Vermittler
• Reine Java-AOP-Bibliotheken
• AspektJ Aspekte (181)
• Testen der Systemarchitektur 182
• Optimierung der Entscheidungsfindung (183)
  
  • Verwenden Sie Standards, wenn sie echten Wert bringen 183
• Systeme erfordern Domänensprachen
• Ende (184)
• Bibliographie (185)

12. Erstellung des Projekts (187)

• Sauberes Design durch Entwickeln (187)
• Regel Nummer 1 für ein einfaches Design – das System besteht alle Tests (188)
• Regel Nummer 2 - 4 für ein einfaches Projekt - Sanierung (188)
• Keine Wiederholungen (189)
• Code-Klarheit 191
• Minimale Klassen und Methoden 192
• Ende (192)
• Bibliographie (192)

13. Gleichzeitigkeit 193

• Warum Parallelität verwenden? (194)
  
  • Mythen und Missverständnisse (195)
• Herausforderungen (196)
• Grundsätze zur Verteidigung der Parallelität (196)
  
  • Grundsatz der Einzelverantwortung (197)
  • Schlussfolgerung - Datenbeschränkung (197)
  • Schlussfolgerung – Verwendung einer Kopie der Daten (197)
  • Fazit - Threads sollten so unabhängig wie möglich sein 198
• Benutzte Bibliothek kennenlernen (198)
  
  • Threadsichere Sammlungen
• Lernen Sie die Ausführungsmodelle kennen (199)
  
  • Erzeuger-Verbraucher (199)
  • Leser-Schreiber (200)
  • Speisephilosophen (200)
• Achten Sie auf die Abhängigkeiten zwischen synchronisierten Methoden
• Erstellen kleiner synchronisierter Abschnitte 201
• Schreiben eines gültigen Deaktivierungscodes 202
• Testen Ihres Thread-Codes 202
  
  • Wir behandeln zufällige Abstürze als potenzielle Multithreading-Probleme
  • Zuerst führen wir den Non-Threading-Code aus (203)
  • Unser Thread-Code sollte aktiviert werden
  • Unser Thread-Code sollte abstimmbar 204 sein
  • Wir führen mehr Threads aus, als wir verfügbare Prozessoren haben (204)
  • Wir führen Tests auf verschiedenen Plattformen durch (204)
  • Wir rüsten unseren Code mit Elementen aus, die versuchen, Fehler zu verursachen und Fehler zu erzwingen (205)
  • Handinstrumente (205)
  • Automatische Instrumentierung (206)
• Fertigstellung (207)
• Bibliographie (208)

14. Erfolgreiche Codebereinigung (209)

• Eine Implementierung der Args-Klasse 210
• Args - Grobe Skizze (216)
• Argumente vom Typ String 228
• Ende (261)

15. Die Struktur der JUnit-Bibliothek 263

• Die JUnit-Bibliothek (264)
• Ende (276)

16. Neuaufbau der SerialDate-Klasse 277

• Zunächst führen wir (278)
• Jetzt korrigieren wir (280)
• Ende (293)
• Bibliographie (294)

17. Code Scents und Heuristiken (295)

• Kommentare (296)
  
  • C1. Falsche Informationen (296)
  • C2. Veraltete Kommentare (296)
  • C3. Redundante Kommentare (296)
  • C4. Schlecht geschriebene Kommentare (297)
  • C5. Kommentierter Code (297)
• Umwelt (297)
  
  • E1. Es braucht mehr als einen Schritt, um 297 zu bauen
  • E2. Tests erfordern mehr als einen Schritt 297
• Eigenschaften (298)
  
  • F1. Argumente zu viel
  • F2. Die Ausgangsargumente 298
  • F3. Markierungsargumente 298
  • F4. Tote Funktionen (298)
• Allgemein (298)
  
  • G1. Mehrere Sprachen in einer Quelldatei (298)
  • G2. Offensichtliche Operation ist nicht implementiert 299
  • G3. Fehlfunktion unter Randbedingungen (299)
  • G4. Sicherheit entfernt (299)
  • G5. Wiederholungen (300)
  • G6. Code auf der falschen Abstraktionsebene 300
  • G7. Basisklassen abhängig von ihren abgeleiteten Klassen 301
  • G8. Zu viele Informationen (302)
  • G9. Toter Code (302)
  • G10. Vertikale Trennung (303)
  • G11. Inkonsistenz (303)
  • G12. Stromausfall (303)
  • G13. Künstliches Feedback (303)
  • G14. Funktionseifer (304)
  • G15. Wählen Sie Argumente 305 aus
  • G16. Verdunkelung der Absichten (305)
  • G17. Falsche Verantwortung (306)
  • G18. Falsche statische Methoden 306
  • G19. Verwenden von beschreibenden Variablen 307
  • G20. Funktionsnamen sollten Ihnen sagen, was sie tun (307)
  • G21. Verstehen des Algorithmus 308
  • G22. Konvertieren von logischen in physische Abhängigkeiten 308
  • G23. Verwenden von Polymorphismus anstelle einer if-else- oder Switch-Case-Anweisung 309
  • G24. Verwenden von Standardkonventionen 310
  • G25. Magische Zahlen in benannte Konstanten umwandeln 310
  • G26. Präzision (311)
  • G27. Struktur vor der Konvention 312
  • G28. Einkapselungsbedingungen
  • G29. Negative Bedingungen vermeiden 312
  • G30. Funktionen sollten eine Operation ausführen 312
  • G31. Versteckte zeitliche Kopplungen
  • G32. Willkürliche Handlungen vermeiden
  • G33. Randbedingungen Kapselung
  • G34. Funktionen sollten eine Abstraktionsebene 315 absteigen
  • G35. Konfigurierbarer Datenspeicher auf hoher Ebene 316
  • G36. Tournavigation vermeiden
• Java (317)
  
  • J1. Vermeidung langer Importlisten durch Verwendung von Wildcards 317
  • J2. Wir erben keine Konstanten (318)
  • J3. Konstanten versus Aufzählungen 319
• Namen (320)
  
  • N1. Auswahl aussagekräftiger Namen
  • N2. Auswahl von Namen auf geeigneten Abstraktionsebenen 321
  • N3. Verwenden der Standardnomenklatur, wo möglich (322)
  • N4. Eindeutige Namen (322)
  • N5. Lange Namen für lange Bereiche verwenden 323
  • N6. Kodierung vermeiden
  • N7. Namen sollten Nebenwirkungen beschreiben 323
• Tests (324)
  
  • T1. Unzureichende Tests (324)
  • T2. Verwenden der Coverage Control Tools
  • T3. Einfache Tests nicht überspringen (324)
  • T4. Ein ignorierter Test ist ein Mehrdeutigkeitsindikator (324)
  • T5. Randbedingungen
  • T6. Gründliches Testen von Fehlern in der Nähe
  • T7. Fehlermuster verraten viel
  • T8. Testabdeckungsmuster verraten viel
  • T9. Tests sollten schnell sein
• Ende (325)
• Bibliographie (325)

A: Parallelität II

• Client-Server-Beispiel
  
  • Server (327)
  • Fäden hinzufügen (329)
  • Servernotizen
  • Ende (331)
• Mögliche Ausführungspfade
  
  • Anzahl der Titel (332)
  • Wir graben tiefer (333)
  • Ende (336)
• Benutzte Bibliothek kennenlernen (336)
  
  • Executor-Bibliothek (336)
  • Nicht blockierende Lösungen (337)
  • Sichere Klassen ohne Threads
• Abhängigkeiten zwischen Methoden können Concurrent Code 339 beschädigen
  
  • Fehlertoleranz (340)
  • Sperren des Clients
  • Sperren auf dem Server
• Steigerung des Durchsatzes
  
  • Berechnen des Singlethread-Durchsatzes
  • Berechnen des Multithread-Durchsatzes
• Deadlock (345)
  
  • Gegenseitiger Ausschluss (346)
  • Sperren und Warten 346
  • Keine Enteignung (346)
  • Zyklisches Warten 346
  • Gegenseitigen Ausschluss verhindern (347)
  • Sperren und Warten verhindern 347
  • Enteignung ermöglichen 348
  • Zyklisches Warten verhindern 348
• Testen von Multithread-Code 349
• Tools zur Unterstützung von Thread-Code-Tests 351
• Ende (352)
• Lernprogramm. Der vollständige Code der Beispiele 352
  
  • Client-Server ohne Threads 352
  • Client-Server mit Threads

B: org.jfree.date.SerialDate (357)

C: Verweise auf Heuristik 411

Epilog (413)