Weniger schlecht programmieren (eBook)

Kathrin Passig, Johannes Jander (Autoren)

eBook Download: PDF | EPUB

2013 | 1. Auflage
456 Seiten
O'Reilly Verlag
978-3-95561-568-0 (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.

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-95561-568-5 / 3955615685
• ISBN-13: 978-3-95561-568-0 / 9783955615680