Weniger schlecht programmieren (eBook)

Kathrin Passig, Johannes Jander (Autoren)

eBook Download: PDF

2013 | 1. Auflage
456 Seiten
O'Reilly Verlag
978-3-89721-568-9 (ISBN)

Infos

Kathrin Passig gilt als Meisterin des unorthodoxen Blickwinkels, und wenn sie sich zusammen tut mit einem gestandenen Entwickler, um ein Programmierbuch zu schreiben, darf man gespannt sein. Mit Sachverstand und Witz widmen sich die beiden den Holzwegen, Fehleinschätzungen und Irrtümern, die insbesondere Programmier-Neulingen und Hobby-Entwicklern das Leben schwer machen. Ein Buch für alle, die ahnen, dass ein besserer Programmierer in ihnen steckt. Hätte ich das früher gewusst! Auch wenn es nicht unbedingt auf der Hand liegt: Programmieren hat viel mit Kommunikation zu tun. Programmierstil, Namensgebung, Umgang mit Kommentaren oder mit Fremdcode - oftmals haben sich gerade dort Konventionen etabliert, wo eine Sprache keine strengen Vorgaben macht. Lernen Sie die unterschiedlichen Traditionen der verschiedenen Sprachen kennen und erfahren Sie, wie Sie sich auf diesem unsicheren Terrain halbwegs unfallfrei bewegen. Vom Umgang mit Fehlern - Wer hat nicht schon Stunden damit verbracht, nach einem Fehler im Programm zu suchen, um herauszufinden, warum etwas nicht so funktioniert, wie eigentlich geplant? Es gibt eine Menge Anzeichen, die darauf schließen lassen, wo genau etwas im Code nicht stimmt. Lernen Sie, wie Sie solche Roststellen erkennen, wie Sie mit systematischem Debugging Fehler finden und durch Tests dauerhaft bändigen. Die Qual der Wahl - Nicht jede Programmiersprache eignet sich gleich gut für jede Aufgabe, Daten lassen sich auf unterschiedliche Weise vorhalten, Entwicklungsumgebungen und Versionskontrollsysteme gibt es viele - auf technischer Ebene gilt es jede Menge Entscheidungen zu treffen, deren Konsequenzen schwer zu überreißen sind. Universell gültige Empfehlungen kann niemand abgeben, aber mit den Erfahrungswerten und Entscheidungshilfen der Autoren fahren Sie für den Anfang nicht schlecht.

Kathrin Passig ist bekannt geworden als Sachbuchautorin (unter anderem 'Internet - Fluch oder Segen', zusammen mit Sascha Lobo oder 'Lexikon des Unwissens', zusammen mit Aleks Scholz). Sie blickt aber auch auf fünfzehn Jahre Erfahrung mit wirklich schlechter Programmierung zurück. Johannes Jander hat schon als Jugendlicher begeistert programmiert, musste aber erst auf einem Umweg über die Biologie zur Softwareentwicklung zurückfinden. Inzwischen arbeitet er hauptberuflich als Entwickler in einem großen Unternehmen.

Inhalt

Cover 1
Inhalt 5
Vorwort 13
Warum dauert es so lange, bis der Mensch klüger wird? 15
Spezialprobleme schlechter Programmierer 16
Die sieben gebräuchlichsten Argumente schlechter Programmierer 17
Wenige Jahre später 18
Die nächsten 422 Seiten 19
Teil 1: Hallo Wels Hallo Welt 21
Kapitel 1: Bin ich hier richtig? 23
Kapitel 2: Zwischen Hybris und Demut 27
Schwächen als Stärken 29
Richtiges muss nicht schwierig sein 32
Kapitel 27: Wie geht es weiter? 439
Was ist ein guter Programmierer? 440
Zum Weiterlesen 441
Danksagungen 442
Teil 2: Programmieren als Verständigung 35
Kapitel 3: Du bist wie die andern 37
Kapitel 4: Konventionen 39
Englisch oder nicht? 40
Die Steinchen des Anstoßes 43
Konventionen im Team 46
Kapitel 5: Namensgebung 49
Namenskonventionen 49
Von Byzanz über Konstantinopel nach Istanbul 51
Was Namen können sollten 53
Der Stoff, aus dem die Namen sind 60
Boolesche Variablen 70
Objektorientierte Programmierung 72
Datenbanken 73
Falsche Freunde 75
Wie es weitergeht 78
Kapitel 6: Kommentare 81
Mehr ist manchmal mehr 83
Zur äußeren Form von Kommentaren 84
Dokumentationskommentare 86
Wann und was soll man kommentieren? 87
Anzeichen, dass ein Kommentar eine gute Idee wäre 89
Problematische Kommentare 94
Kapitel 7: Code lesen 97
Muss ich wirklich? 97
Zuerst die Dokumentation lesen 99
Sourcecode ausdrucken 100
Zeichnen Sie schematisch auf, was einzelne Programmteile tun 101
Von oben nach unten, von leicht nach schwer 102
Lernen Sie Spurenlesen 102
80/20 ist gut genug (meistens) 103
Vergessen Sie die Daten nicht 104
Der Beweis ist das Programm 104
Gemeinsames Code-Lesen 105
Kapitel 8: Hilfe suchen 107
Der richtige Zeitpunkt 108
An der richtigen Stelle fragen 111
Die Anfrage richtig strukturieren 111
An den Leser denken 114
Nicht zu viel erwarten 115
Keine unbewussten Fallen stellen 116
Höflich bleiben – egal, was passiert 116
Kapitel 9: Lizenz zum Helfen 119
Der falsche Anlass 119
Die eigennützige Motivation 121
Die fehlende Einfühlung 122
Zu viel auf einmal 123
Antworten auf konkrete Fragen 125
Wenn Sie selbst keine Antwort wissen 126
Wenn Sie mit schlechteren Programmierern zusammenarbeiten 127
Schlechten Code gefasst ertragen 128
Kapitel 10: Überleben im Team 131
Ich war's nicht! 133
Der Bus-Faktor 134
Zusammenarbeit mit Anwendern 136
Zusammenarbeit mit Freiwilligen 137
Aussprache von Begriffen 137
Teil 3: Programmieren als Verständigung 141
Kapitel 11: Unrecht haben für Anfänger 143
Im Irrtum zu Hause 144
Fehlerforschung im Alltag 145
Der Hund hat die Datenbank gefressen! 146
Der gepolsterte Helm 147
Kapitel 12: Debugging I: Fehlersuche als Wissenschaft 151
Systematische Fehlersuche 153
Beobachtung 155
Was das Beobachten erschwert 156
Analyse und Hypothesenbildung 158
Was das Bilden von Hypothesen erschwert 158
Test der Hypothesen 159
Was das Testen von Hypothesen erschwert 160
Kapitel 13: Debugging II: Finde den Fehler 163
Fehlermeldungen sind unsere Freunde 163
Wer will da was von mir? 164
Diagnosewerkzeuge und -strategien 167
Wenn sonst nichts hilft 180
Wenn auch das nicht hilft 182
Die häufigsten Fehlerursachen schlechter Programmierer 183
Kapitel 14: Schlechte Zeichen oder Braune M & Ms
Zu große Dateien 186
Sehr lange Funktionen 187
Zu breite Funktionen 187
Tief verschachtelte if/then-Bedingungen 188
Mitten im Code auftauchende Zahlen 190
Komplexe arithmetische Ausdrücke im Code 190
Globale Variablen 191
Reparaturcode 192
Eigene Implementierung vorhandener Funktionen 193
Sonderfälle 194
Inkonsistente Schreibweisen 194
Funktionen mit mehr als fünf Parametern 194
Code-Duplikation 195
Zweifelhafte Dateinamen 196
Leselabyrinth 196
Ratlose Kommentare 196
Sehr viele Basisklassen oder Interfaces 197
Sehr viele Methoden oder Member-Variablen 197
Auskommentierte Codeblöcke und Funktionen 198
Browservorschriften 198
Verdächtige Tastaturgeräusche 199
Kapitel 15: Refactoring 201
Neu schreiben oder nicht? 202
Wann sollte man refakturieren? 203
Eins nach dem anderen 206
Code auf mehrere Dateien verteilen 211
Ein Codemodul in kleinere aufspalten 211
Nebenwirkungen entfernen 214
Code zusammenfassen 215
Bedingungen verständlicher gestalten 218
Die richtige Schleife für den richtigen Zweck 221
Schleifen verständlicher gestalten 221
Variablen kritisch betrachten 223
Refactoring von Datenbanken 224
Was man nebenbei erledigen kann 226
Ist das jetzt wirklich besser? 228
Wann man auf Refactoring besser verzichtet 228
Ein Problem und seine Lösung 231
Kapitel 16: Testing 233
Warum testen? 233
Testverfahren 234
Datenvalidierungen 240
Performancetests 242
Richtig testen 245
Kapitel 17: Warnhinweise 247
GET und POST 248
Zeichenkodierung 249
Zeitangaben 250
Kommazahlen als String, Integer oder Decimal speichern 252
Variablen als Werte oder Referenzen übergeben 253
Der schwierige Umgang mit dem Nichts 256
Rekursion 257
Usability 258
Kapitel 18: Kompromisse 261
Trügerische Tugenden 263
Absolution: Wann Bad Practice okay ist 267
Teil4: Wahl der Mittel 273
Kapitel 19: Mach es nicht selbst 275
Der Weg zur Lösung 277
Bibliotheken 278
Umgang mit Fremdcode 281
Was man nicht selbst zu machen braucht 282
Kapitel 20: Werkzeugkasten 293
Editoren 294
Welche Programmiersprache ist die richtige? 295
REPL 299
Diff und Patch 302
Paketmanager 304
Frameworks 306
Entwicklungsumgebungen 309
Kapitel 21: Versionskontrolle 317
Alternativen 319
Arbeiten mit einem VCS 320
Konflikte auflösen 322
Welches Versionskontrollsystem? 323
Gute Ideen beim Arbeiten mit Versionskontrolle 325
Schlechte Ideen beim Arbeiten mit Versionskontrolle 326
Versionskontrollsysteme als Softwarebausteine 327
Kapitel 22: Command and Conquer – vom Überleben auf der Kommandozeile 329
Mehr Effizienz durch Automatisierung 330
Unsere langbärtigen Vorfahren 332
Windows 333
Was jeder Programmierer wissen sollte 333
Navigation 338
Dateien 338
Betrachten 341
Suchen und Finden 342
Ressourcen schonen 345
Zusammenarbeit 346
Zeitsteuerung 346
Editieren auf dem Server 348
Internet 348
Muss ich mir das alles merken? 350
Not the whole Shebang! 350
Kapitel 23: Objektorientierte Programmierung 353
Vorteile der objektorientierten Programmierung 355
Die Prinzipien objektorientierter Programmierung 357
Sinnvoller Einsatz von OOP 364
Nachteile und Probleme 367
Unterschiedliche Objektmodelle, je nach Sprache 368
Objektorientierte Programmierung und Weltherrschaftspläne 368
Kapitel 24: Aufbewahrung von Daten 371
Dateien 372
Versionskontrollsysteme 377
Datenbanken 377
Kapitel 25: Sicherheit 385
Wichtige Konzepte 386
Vor- und Nachteile der Offenheit 388
Vom Umgang mit Passwörtern 390
Authentifizierungsverfahren 391
SQL Injection und XSS – die Gefahren in User-Content 395
Weiße Listen sind besser als schwarze 400
Alle Regler nach links 401
Auch die Hintertür abschließen 403
Penetration Testing 404
Die Fehler der anderen 405
Sicherheit ist ein Prozess 406
Kapitel 26: Nützliche Konzepte 409
Exceptions 409
Error Handling 412
State und Statelessness 416
IDs, GUIDs, UUIDs 417
Sprachfamilien 419
Variablentypen 421
Trennung von Inhalt und Präsentation 424
Trennung von Entwicklungs- und Produktivserver 425
Selektoren 426
Namespaces 428
Scope von Variablen 430
Assertions 431
Transaktionen und Rollbacks 434
Hashes, Digests, Fingerprints 435
CRUD und REST 437
Index 443

Textauszug

»In der Informatik gibt es nur zwei echte Probleme: Cache-Verwaltung und Namensgebung.«

—Phil Karlton, Netscape-Programmierer

Viele nicht so gute Programmierer weigern sich, ihre wertvolle Lebenszeit auf das Ausdenken von Variablen- oder Funktionsnamen zu verwenden. Sie wollen schnell ein Ergebnis sehen und auf dem Weg dorthin nicht aufgehalten werden. Also wählen sie einen Namen, der gerade gut zu passen scheint und kurz und knapp ist, zum Beispiel tmp oder var1. Notfalls sogar dings.

Andere stutzen, wenn sie eine Variable oder Funktion benennen sollen. Sie fühlen, dass hier etwas Großes passieren soll, etwas, das den Fortgang des Projekts beeinflussen wird. Die Entscheidung fällt ihnen schwer, der gewählte Funktionsname könnte ja unvorteilhaft sein. Bei der nächsten Funktion wiederholt sich das gleiche Spiel. Tage später stellt sich dann heraus, dass der erste Name gar nicht so recht zum zweiten passen will, es drückt und kneift alles. Aber jetzt ist es zu spät, eine Angleichung der Namen würde vermutlich Probleme verursachen.

Wer schon einmal mit sich gerungen hat, ob die Umbenennung einer Variable wirklich den Aufwand lohnt, wer sich gefragt hat, ob er lieber ganz kurze oder lieber aussagekräftigere Namen verwenden soll, und wer in fremdem Code Namensmonstern wie lpszStreetNameKey begegnet, hat vermutlich das nagende Gefühl, dass eine Auseinandersetzung mit diesem Thema eine gute Sache sein könnte.

Die Namen von Klassen und Exceptions stehen also in CamelCase, für globale Variablen verwendet man Großbuchstaben, alles andere schreibt man klein und mit Unterstrichen getrennt.

Ein Problem, das auch besseren Programmierern immer wieder zu schaffen macht, ist der konsistente Umgang mit Komposita, d.h. mit Begriffen, die aus mehreren Wörtern bestehen. Im Deutschen schreibt man Begriffe wie Dateiname oder Hintergrundfarbe zusammen. Im Englischen jedoch heißt es korrekt: file name und background color. Während Letzteres in der freien Wildbahn als backgroundColor oder background_color auftaucht, also immer getrennt geschrieben wird, ist die Sache im Fall von file name weniger eindeutig: Die Schreibweisen getFileName und getFilename bzw. get_filename und get_file_name ringen um die Vormachtstellung. Wenn man jedoch eine Ausnahme für filename macht, wie schreibt man dann filePath? Und wie heißt die Variable, die den Namen des Lieblingstiers beinhaltet, favoriteAnimalname?

Dieses Problem berührt den Grundsatz, dass Funktionsnamen und Variablennamen einem konsequenten Schema folgen sollten, damit sie erratbar sind und der Programmierer Zeit spart. Man orientiert sich dann generell an einem bestimmten Prinzip und merkt sich nur noch das Prinzip anstelle der Namensdetails. Im Sinne dieser Konsequenz empfehlen wir, alles, was sich als eigenes Wort verstehen lässt, mit einem Großbuchstaben bzw. Unterstrich abzuteilen, also getFileHandleForPathName bzw. get_file_handle_for_path_name zu schreiben.

Auch auf die Frage, ob Variablennamen im Singular oder im Plural stehen sollten, gibt es keine allgemein akzeptierte Antwort. Wenn eine Sammlung benannt werden soll, also zum Beispiel ein Array, das die Farben red, green, blue und yellow enthält, liegt es nahe, dieser Sammlung einen Namen im Plural zu geben, denn schließlich enthält sie mehrere Dinge. Andererseits verwendet man die Einzelteile dieser Sammlung später oft im Singular: if (isPrimaryColor(colors[$i])) ... Manche Programmierer argumentieren, dass ein Singularname sich hier grammatikalisch ordentlicher anfühlt, andere ziehen es vor, dem Namen der Variable direkt entnehmen zu können, dass sie mehrere Dinge enthält. Versuchen Sie auch hier, sich für eine Variante zu entscheiden (oder die Ihres Teams zu übernehmen) und dann konsequent dabei zu bleiben.

Wie ein Funktions- oder Variablenname geschrieben wird und formal aufgebaut sein soll, ist ein vergleichsweise kleines Problem, das sich – inklusive der Suche nach einer sprachspezifischen Anleitung – in einer halben Stunde für immer lösen lässt. Die Suche nach passenden Namen hingegen ist schwieriger und beschäftigt Programmierer ein Leben...

Produkt-Details

• Erscheint lt. Verlag: 5.12.2013
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge
• Schlagworte: Best Practices • Code • Qualität • Softwareentwicklung • Testen
• ISBN-10: 3-89721-568-3 / 3897215683
• ISBN-13: 978-3-89721-568-9 / 9783897215689