Programmiertechnik

Wer sich mit dem Gedanken trägt, auch selbst einmal zu programmieren, muss zunächst einmal eine Programmiersprache erlernen.

Weit mehr, als so mancher Hobby-Programmierer sich träumen lässt, entscheidet aber die individuelle Grundlagen: ProgrammiertechnikProgrammiertechnik, die Methode, mit der man ein neues Programm angeht, über Erfolg und Misserfolg beim Programmieren.

Je größer die Probleme werden, die man mit seinem Computer zu lösen gedenkt, um so sorgfaeltiger, geplanter muss man an's Werk gehen. Wer das nicht tut, produziert mit Sicherheit chaotische Programmtexte, in denen es in aller Regel vor Fehlern nur so wimmelt. Es gibt nur sehr wenige Menschen, die scheinbar ohne Konzept drauflos programmieren können und trotzdem übersichtliche, verständliche und weitgehend fehlerfreie Programme produzieren.

ABER GLAUBEN SIE NICHT, DASS AUSGERECHNET SIE ZU DIESEN GENIES GEHOEREN!

Die Mittel, deren man sich in der Vorphase bedient, können recht unterschiedlich sein. Sicher kann man dabei auch nicht alle Menschen über einen Kamm scheren. So, wie sich die einzelnen Menschen in ihrem Naturell unterscheiden, werden auch die Methoden, mit denen sie Programme angehen, voneinander abweichen. 'Die' richtige Programmier-Technik gibt es nicht. Hier spielen zuviele Faktoren hinein: Eigene Mentalität, Anzahl der an einem Projekt beteiligten Personen, Art der Aufgabenstellung und so weiter und so fort.

Es gibt aber einige Methoden, 'System' in das Ganze hineinzubringen, die von vielen (erfolgreichen) Programmierern angewendet werden. Was man aber auch macht, meist handelt es sich um eine Spielart des Satzes: "Ordnung ist das halbe Leben."

Pflichtenliste

Zunächst muss man sich überhaupt einmal klar werden, was das Programm machen, bzw. können soll. Eine Programmiertechnik: PflichtenlistePflichtenliste, schriftlich abgefasst, ist ratsam. Dabei sollte man die einzelnen Anforderungen schon etwas systematisieren. Eine Programmiertechnik: PflichtenlistePflichtenliste ist dabei nicht so endgültig, wie man vielleicht denken könnte.

Neben den unbedingten Anforderungen kann man noch eine ganze Menge aufnehmen, was man nur 'ganz gerne' auch noch verwirklicht sähe. Während der Programm-Entwickung entscheidet sich dann, was man davon fallen lässt (weil zu umständlich) und ob man andere Punkte neu aufnimmt (weil es sich gerade so günstig ergibt).

Gliederung

Dann geht man das Problem am besten von oben her an. Man zergliedert das Gesamtpaket in einzelne Unterprobleme, die, hätte man sie alle schon gelöst, das gesamte Programm enthalten würden. Diese Unterprobleme lassen sich natürlich wieder untergliedern, die so erhaltenen Unter-Unterprobleme auch und so weiter, bis man irgendwann der Meinung ist, jetzt habe man lange genug aufgedröselt, und ein Problemhaeppchen direkt löst.

Dabei darf der Zusammenhalt zwischen den einzelnen Teilproblemen nicht verloren gehen. Es empfiehlt sich also auch hier, seine Geistesblitze in irgendeiner schriftlichen Form festzuhalten. Ob man auf eine grafische Methode zurückgreift (Flussdiagramme o. AE.) oder das ganze in verständliche, leserliche Worte fasst, ist dabei weitgehend egal.

Programm-Bibliotheken

Bei dieser Problem-Teilerei sollte man auch immer mit einem Auge auf die benachbarten Probleme schielen (vielleicht lässt sich eine Routine ja vielfach verwerten) und mit dem anderen Auge auf alte Programme (vielleicht hat man so 'was ja schon 'mal gehabt). Viele Programmierer stellen sich deshalb ganze Programmiertechnik: Programm-BibliothekenProgramm-Bibliotheken mit fertigen Grundlagen: UnterprogrammeUnterprogrammen für die verschiedensten Probleme zusammen. Mit jedem neu geschriebenen Programm wächst mit Sicherheit auch die Bibliothek.

Modularisierung

Am wichtigsten von allen Methoden ist aber die klare Programmiertechnik: GliederungGliederung eines Problems. Umfangreiche Probleme lassen sich nur bewältigen, indem man sie zergliedert und die einzelnen Probleme getrennt löst.

Um den Die Firmware des Schneider CPC: ÜberblickÜberblick zu behalten, muss man die einzelnen Bruchstücke (ob nun schon gelöst oder nicht) als 'black box' betrachten. Nicht, wie ein Grundlagen: UnterprogrammeUnterprogramm die ihm übertragenen Die Fließkomma-Routinen: FunktionenFunktionen ausführt, nur das, was nach außen sichtbar wird, ist interessant. Damit wird aus einem popeligen Grundlagen: UnterprogrammeUnterprogramm ein 'Modul'.

Die Vektoren des Betriebssystems im RAM stellen in diesem Sinne über 200 Programm-Module bereit. Genau definierte Probleme sind im Betriebssystem gelöst, und können über die Vektoren aufgerufen werden. Für den Programmierer ist es völlig unwichtig zu verstehen, wie man die einzelnen Probleme bei Amstrad gelöst hat. Ihn interessiert nur die Schnittstellen-Beschreibung: 'Eingaben', 'Ausgaben' und 'Wirkung' der einzelnen Routinen.

Kommentare

Nicht zu unterschätzen ist auch eine gute Dokumentation: Ob man nachher Der Linien-Algorithmus: Fehler 3Fehler sucht, das Programm nach einem Jahr (oder auch bereits nach einer Woche) umstricken will oder wissen muss, was ein Grundlagen: UnterprogrammeUnterprogramm nun ganz genau macht: Überall sind Kommentarzeilen unerlässlich. Je niedriger die Programmiersprache gewählt ist, umso höher wird der Anteil der 'Remarks'. In Basic-Programmen sind sie zwar verpoent, weil sie die Programmgeschwindigkeit herabsetzen. Das ist aber kein wirklicher Grund. Während der Z80-Relocalisitor: Programm-EntwicklungProgramm-Entwicklung sollte man seinen Programmtext mit Programmiertechnik: KommentareKommentaren spicken, die man in der Arbeitsversion ja wieder herausnehmen kann.