ALBERT

All Library Books, journals and Electronic Records Telegrafenberg

Language
Number of Hits per Page
Default Sort Criterion
Default Sort Ordering
Size of Search History
Default Email Address
Default Export Format
Default Export Encoding
Facet list arrangement
Maximum number of values per filter
Auto Completion
Topics (search only within journals and journal articles that belong to one or more of the selected topics)
Feed Format
Maximum Number of Items per Feed
feed icon rss

Your email was sent successfully. Check your inbox.

An error occurred while sending the email. Please try again.

Proceed reservation?

Export
Filter
Collection
Publisher
Language
Years
  • 1
    Call number: M 21.94521
    Type of Medium: Monograph available for loan
    Pages: 475 Seiten , Illustrationen, Diagramme , 240 mm x 170 mm
    Edition: 1. Auflage
    ISBN: 3826655486 (PB.) , 9783826655487 (PB.)
    Uniform Title: Clean code 〈dt.〉
    Language: German
    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
    Location: Upper compact magazine
    Branch Library: GFZ Library
    Location Call Number Expected Availability
    BibTip Others were also interested in ...
Close ⊗
This website uses cookies and the analysis tool Matomo. More information can be found here...