Wertvolle Tipps rund um das Programmieren und Vertiefungsthemen

Wenn Sie vielleicht schon seit ein, zwei Jahren programmieren, oder vielleicht seit ein paar Monaten, je nach Intensität, dann kennen Sie bereits die meisten Kniffe Ihrer Sprache. An dieser Stelle sind Sie wahrlich kein Einsteiger des Programmierens mehr. Herzlichen Glückwunsch! Sie haben’s geschafft!

Sie werden sich dann vielleicht fragen: war’s das schon? Die meisten Elemente Ihrer Sprache sind Ihnen bekannt oder können jederzeit in der Hilfe nachgeschlagen werden (niemand erwartet ernsthaft, alles auswendig zu wissen!). Mit diesem Wissen ausgestattet sind Sie ohne weiteres in der Lage, leistungsstarke Astronomieprogramme zu erstellen. Dennoch bietet die Welt des Programmierens sehr viel Interessantes, was über die Details der Programmiersyntax hinausgeht und die Dinge von einer anderen Ebene, der Designebene, betrachtet.

Unser Ziel ist es, Ihnen einen Leitfaden in die Hand zu geben, in welche Richtung man weiter recherchieren könnte und auf welche Punkte es sich besonders zu achten lohnt. Mit Hilfe dieser Tips können Sie Ihre eigenen Programme fehlerfreier und robuster machen, sie mit ungeahnten Funktionen ausstatten oder sich sogar eine ganze Menge Arbeit ersparen!

Wie vermeide ich ganz allgemein Programmierfehler?

Access Violations und ähnliche Fehlermeldungen sind unschön, besonders dann, wenn sie in den eigenen Programmen auftreten. Ebenso kann man sich das Erweitern seines Programms unnötig selbst verbauen. Dabei gibt es einiges an Handwerkszeug, das von findigen Programmieren zusammengestellt wurde, die einem das Leben leichter machen können. Es ist möglich, solche Fehler zu 80 bis 90% (!) allein durch die Aneignung bestimmter Programmiertechniken von vornherein zu vermeiden!

Die meisten Fehlerquellen sind systematischer Natur und wiederkehrend. Programmierer haben diese Probleme zusammengetragen und sie in Anlehnung an die Design Patterns Antipattern genannt. Dabei handelt es sich um Kollektionen häufig anzutreffender programmiertechnischer Mängel. Beim Durcharbeiten der klassischen Antipattern bekommt man schon ein recht gutes Gefühl, worauf man bei der eigenen Programmierung achten könnte, um Probleme a priori zu vermeiden.

Mit untenstehenden Literaturhinweisen und Links mit unterschiedlichem Kontext wird versucht, dem Programmierer weitere wichtige Werkzeuge in die Hand zu geben, um nicht nur einigermaßen funktionierende, sondern sogar richtig gute Software zu erstellen.

Warum das Rad neu erfinden?

Häufig hat man es mit Aufgabenstellungen zu tun, die anderen Programmierern seit Jahren ebenfalls begegnet sind. Weshalb sollte man das Rad neu erfinden, wenn andere Entwickler so freundlich waren, ihre Lösungen in Form von Programmcode ins Netz zu stellen?

Ganz gleich, ob man Bilder exportieren, Office-Dokumente erstellen oder leistungsfähige Grafikroutinen nutzen möchte – für viele wiederkehrende Aufgaben finden sich hervorragende Codebibliotheken, die einem erhebliche Arbeit abnehmen können. Auf der anderen Seite kann man mit den Codebibliotheken eigene Programme mit professioneller Funktionalität ausstatten und so mehr Attraktivität verleihen. [mehr…]

Codebibliotheken haben den Nachteil, daß man sich mit fremden Code auseinander setzen muß – eine Tätigkeit, die unter Programmierern weniger beliebt ist. Die Arbeitsersparnis ist jedoch immens: eine Eigenprogrammierung kann Wochen oder gar länger dauern. Außerdem sind fertige Lösungen aus dem Netz häufig ausgefeilter.

Beispiele:

• Dislin ist eine Bibliothek zur graphischen Darstellung wissenschaftlicher Daten und beherrscht eine Vielzahl von Darstellungsmöglichkeiten: 2D- und 3D-Graphen, Balken- und Tortendiagramme, Vektorfelder, geographische Karten und einiges mehr. Diese Codebibliothek bietet viele Annehmlichkeiten: Legenden, Achsbeschriftungen, Skalierungen (linear/logarithmisch), Überlagerungen von Grafiken, uvm. Sie liegt unter C++ vor und kann unter www.dislin.de heruntergeladen werden
• Zlib ist eine Library zum Erstellen und Auslesen von gepackten Zip-Dateien aus eigenen Anwendungen heraus. ZLib ist Open Source.
• OpenGL ist eine leistungsfähige Grafikbibliothek für die 3-D-Darstellung von Objekten, die auch im professionellen Bereich Verwendung findet. OpenGL kümmert sich um das perspektivische Zeichnen ebenso wie um Verdeckungsrechnung und Schattenwürfe (Jupitermondereignisse!). Entwicklungsumgebungen sind häufig schon mit einer OpenGL-Anbindung ausgestattet. Ansonsten gibt es mit Mesa eine freie Implementierung der OpenGL-Bibliothek.
• Es ist ohne großen Aufwand möglich, aus eigenen Programmen auf Office-Funktionen zuzugreifen, z.B. zum Einlesen und Abspeichern von Daten in den gängigen Office-Formaten (Word, Excel). Dies basiert nicht auf Codebibliotheken, sondern man nutzt vielmehr den COM-Mechanismus aus.

Dies Auflistung ist nur ein Beispiel und soll dazu ermutigen, sich selbst auf die Suche nach Möglichkeiten zur Codewiederverwendung, sei es für PDF-Export, Mathematikroutinen oder FITS-Import, zu begeben.

Weitere Infos zu Codebibliotheken finden sich unter den Zirkularen der Fachgruppe.

Goldene Regeln für die Programmierung astronomischer Problemstellungen

Eine häufige Fehlerquelle beim Erstellen astronomischer Software ist z.B. die uneinheitliche Verwendung von Maßeinheiten. Dies ist sicherlich nur ein herausgegriffenes Beispiel, aber beim Betreiben einer Fehleranalyse wird man feststellen, daß man stets mit dieselben Fehlertypen konfrontiert wird. Aus diesem Grund sind hier ein paar Goldene Regeln für die Programmierung zusammengestellt. Sie sollen es dem Programmierer ermöglichen, Code zu schreiben, der weniger fehleranfällig, leichter zu warten und erweiterbar ist. Wir beschränken uns auf Hinweise mit ausdrücklichem Bezug auf die Programmierung astronomischer Problemstellungen. s. Goldene Regeln

Softwaredesign

Softwaredesign ist die Kunst, den Quelltext einer Anwendung geschickt zu strukturieren. Ziel der Strukturierung ist es, die Erstellung, Pflege und Erweiterbarkeit von Software zu verbessern. Bei 500 Zeilen Quelltext ist gutes Softwaredesign sicherlich nicht wichtig, aber für größere Projekte werden hier einige der wichtigsten Elemente kurz vorgestellt.

Schichtenmodell

In der Regel wird Quelltext auf mehrere Dateien (Module, Klassen) aufgeteilt. Bei vielen Anwendungen wird man eine Dreiteilung einer Aufgabe vorfinden: die Anzeige (Benutzeroberfläche, Fenster), die Programmlogik (eigentliche Berechnung/Verarbeitung) und die Datenhaltung (Datei, Datenbank). Man gibt dieser Unterteilung eine vertikale Struktur (die Benutzoberfläche ist „oben“ und die Datenhaltung „unten“) und spricht von Schichten. Bei manchen Programmen gibt es auch mehr als drei Schichten.

Es ist äußerst sinnvoll, keine schichtübergreifende Module zu programmieren. Es sollte unbedingt vermieden werden, daß innerhalb eines Moduls Programmcode für Benutzoberfläche und Programmlogik, Programmlogik und Datenhaltung oder gar alle drei Bereiche enthalten ist.

Model View Controller (MVC)

Gutes Software-Design beinhaltet, daß die Art der Darstellung von Daten in einer Software nicht die Form der Datenhaltung beeinflussen oder gar bestimmen sollte. Die internen Datenstrukturen sind demnach vollständig von der Darstellung in Fenstern abgekoppelt.

Um dies zu erreichen, wurde das Schema des Model-View-Controllers (kurz MVC) ersonnen; eine Dreiteilung der Software bei der Datenrepräsentation.

• Zum Model gehören diejenigen Softwaremodule, welche die zentrale Datenhaltung samt logischer Struktur beinhalten.
• Der View bezeichnet die Module zur Anzeige der Daten in Fenstern und anderen GUI-Elementen.
• Der Controller vermittelt zwischen Model und View. Im Wesentlichen werden die Daten für die Anzeige aufbereitet.

Hintergedanke ist, daß es in einer Anwendung mehr als eine Sicht auf einen Datenbestand geben könnte. Mit MVC werden die typischen „Stolperfallen“ ganz von allein vermieden. Auch die Selektion der darzustellenden Daten (z.B. welche Spalten eine Tabelle angezeigt werden sollen) gestaltet sich einfacher.

Software zuerst modellieren, dann implementieren

Wenn man beim Programmieren größerer Projekte völlig umständlich auf Variablen oder Methoden zugreifen muss, dann ist dies ein klarer Hinweis für ein schlechtes Softwaredesign. Oft ist die Ursache, dass viel zu früh mit der Implementation begonnen wurde. Stellt man während des Programmierens fest, dass das Gesamtkonzept der Software nachteilig ist, so muss der gesamte Quelltext geändert werden – dagegen sträuben sich jedoch die meisten Programmierer. Die Folge ist, dass schlechtes Design weiterlebt und fortan „drumherum“ programmiert wird. Doch irgendwann werden die Programme fehleranfällig und unwartbar. Dies führt oft zum Tod des Softwareprojekts.

Wichtiger Tipp: bei größeren Softwareprojekten empfiehlt es sich, das Konzept vollständig zu erstellen, bevor auch nur die erste Codezeile geschrieben wird. Hierbei kann man Anleihen bei der Unified Modelling Language (UML) machen. UML ist ein Standardverfahren in der professionellen Programmierung und beinhaltet eine ganze Auswahl an Diagrammtypen wie z.B. Objekt-, Anwendungsfall- und Ablaufdiagramme, mit der eine Anwendung vor ihrer Programmierung zunächst modelliert wird.

Es geht bei der UML keineswegs darum, alle diese Diagrammtypen vorzuschreiben oder ein starres Regelwerk einzuführen, das sklavisch zu befolgen ist und einen bei der Arbeit nur behindert. UML hat schon seinen Zweck erfüllt, wenn man sich möglichst viele Gedanken zum Programm vor Beginn der Programmierung macht.

Die UML-Syntax übersteigt sicherlich die Bedürfnisse des Hobbyprogrammierers. Wer das Programmieren für Beruf oder Studium (Naturwissenschaften, Ingenieure, Wirtschaftswissenschaften) braucht, kann durchaus einen Blick über den Tellerrand werfen. Es geht ja auch in erster Linie um eine geeignete Systematik, mit der man die Anforderungen an das Programm zu Beginn möglichst gut zu beschreiben versucht, und einige UML-Diagramme können da wertvolle Dienste leisten.

Hier ein Vorschlag für die Diagrammauswahl:

• Anwendungsfälle: hierbei werden alle verschiedenen Transaktionsmöglichkeiten aufgeschrieben, die der Benutzer zur Programmbedienung haben soll. Ein Anwendungsfall ist eine in sich abgeschlossene Benutzeraktion. Für ein Planetariumsprogramm wären z.B. Karte exportieren, Karte speichern, Karte verschieben, Objekt anwählen, Zeitpunkt setzen, usw. jeweils ein eigener Anwendungsfall. Die Voraussetzungen und Ergebnisse eines jeden Anwendungsfalls sollten mit angegeben werden.
• Beim Klassenmodell werden die (Fach-)Klassen der Software identifiziert. Es wird versucht, die Dinge der realen Welt als Datenstrukturen in der Software (Klassen bei der objektorientierten Programmierung bzw. Module in der prozeduralen Programmierung) 1:1 nachzubilden. Sehr viele Aspekte der Programmierung, z.B. welche Methoden oder Funktionen implementiert werden müssen oder wie diese Gegenstände miteinander in Beziehung stehen, ergeben sich dann von selbst. Das Schichtenmodell sollte ebenso wie MVC darin Berücksichtigung finden. Selbst Dinge, die noch zu klären sind, können dort vermerkt werden.
• Beim Ablaufdiagramm (kann auch durch ein Flussdiagramm erfolgen) werden alle Pfade, die eine Benutzertransaktion gehen kann, aufgezeichnet. Dabei sind auch alle Fehlerfälle zu erfassen, die vorkommen können (Benutzer macht ungültige Eingabe, Datei nicht vorhanden, Voraussetzung nicht erfüllt, etc.).

Diese Vorgehensweise hilft, Fehler und Probleme schon sehr frühzeitig zu erkennen und von vornherein richtig darauf zu reagieren. Dies gilt umso mehr, wenn man schon ein wenig Übung darin hat. Man erkennt hier auch das Prinzip: es ist ein Top-Down-Verfahren. Man beginnt mit sehr allgemeinen Anforderungen und geht mit jedem neuen Diagramm immer weiter ins Detail. Eine Ordnung des Systems ergibt sich schon fast von selbst

Durch die Trennung von Modellierung der Software und ihrer Programmierung wird auch die Komplexität des Problems erheblich herabgesetzt.

Wann kann ich endlich mit dem Programmieren meines Projekts beginnen?

Der günstigste Zeitpunkt, mit dem Programmieren zu starten, ist, wenn sich das Softwaremodell kaum noch ändert, also wenn es einen gewissen Reifegrad erlangt hat. Das heißt allerdings nicht, dass das Modell schon in Stein gemeißelt ist – es kann sich immer noch ändern.

Für weitere Information sei an die Literatur verwiesen.

Entwurfsmuster

Entwurfsmuster (oder auch Design Patterns) sind praxisbewährte Standardlösungen für wiederkehrende Aufgabenstellungen der Softwareentwicklung. Sie beinhalten meist textuelle Anweisungen zur Implementierung eines Teilproblems, für welches man ein Entwurfsmuster als passend identifiziert hat. Der Vorteil der Anwendung eines Entwurfsmusters ist, daß man von der Erfahrung anderer Programmierer profitieren kann, da Entwurfsmuster robust sind, d.h. oftmals schon Lösungen mitbringen für Effekte oder Unwägbarkeiten, an die der anwendende Programmierer vielleicht noch gar nicht gedacht hatte, als er auf das Problem stieß.

Teile und herrsche

ist ein gängiges Prinzip, bei dem ein zu schwierig erscheinendes Problem solange in mehrere kleinere Probleme zerteilt wird, bis die Teilprobleme leichter zu lösen sind. Dieses Prinzip ist auf beinahe alle Problemfälle anwendbar.

Ausblick

Falls Sie ein größeres Softwareprojekt in Angriff nehmen und darin Neuland betreten, so hoffen wir, mit obenstehenden Punkten einige wichtige Hinweise gegeben zu haben und dass Sie mit dem notwendigen Handwerkszeug ausgestattet sind. Falls sich bzgl. dieser Tipps oder auch in anderer Hinsicht Fragen ergeben, so zögern Sie nicht, sich mit uns in Verbindung zu setzen.

Literatur und Linklisten

Wie vermeide ich ganz allgemein Programmierfehler:

• Kernighan/Pike: Programmierpraxis (Addison-Wesley, 2000), Gibt sehr viele Hinweise zur Vermeidung logischer Programmierfehler und zum "guten Stil".
• Scott Myers: Effective C++
• Scott Myers: More Effective C++, für C++ wärmstens zu empfehlen.
• C++ portability guide. Eine Zusammenstellung von Richtlinien für C++ mit der Intention der Portierung auf möglichst viele Maschinen
• C++/Java coding guidelines Richtlinien für Java, C++ und C unter dem Aspekt "Guter Stil" (Lesbarkeit, Fehleranfälligkeit und Wartbarkeit)
• C++ language coding guidelines, Richtlinien für C++ mit Schwerpunkt auf Lesbarkeit
• Tips for maintainable Java code, Richtlinien für Java unter Design-Gesichtspunkten mit einigen hintergründigen Kommentaren
• Code conventions for the Java programming language, Enthält allgemeine Codierkonventionen für Java

Entwurfsmuster:

• Thinking in patterns, http://www.mindview.net/Books/TIPatterns/
• Gamma et al: Entwurfsmuster
• Freeman et al: Entwurfsmuster von Kopf bis Fuß

Software zuerst modellieren, dann implementieren:

Oestereich, Analyse und Design in UML 2

Model-View-Controller

• http://de.wikipedia.org/wiki/MVC
• http://www.dpunkt.de/java/Programmieren_mit_Java/Oberflaechenprogrammierung/40.html

Schichtenmodell:

http://de.wikipedia.org/wiki/Schichtenmodell