Fallunterscheidungen durchzutesten sowie eigene einfache un- sofern vorhanden - kompliziertere Literaturbeispiele durchzurech­ nen. Auch schon während des Studiums sollte man sich klar darüber sein, daß der spätere Auftraggeber den Programmierer zur Rechen­ schaft ziehen wird, wenn durch Nachlässigkeit unvollkommene und falsche Programme ihn ein unverantwortliches Mehr an Zeit und Geld kosten. Es wird in der späteren Praxis auch der Fall sein können, daß ein Fremder Ihr Programm rechnen will - oder daß Sie selbst nach einigen Monaten durch veränderte Spezifikationen Ihr eigenes Pro­ gramm abändern müssen - oder ein anderer Mitarbeiter sich durch Ihr Programm, das mehrere Seiten umfassen kann, hindurchkämpfen muß. Dann muß es mit wenig Zeitaufwand möglich sein, sich dieses fremd gewordene oder fremde Programm inhaltlich wie strukturell (wieder) anzueignen. Die notwendigen Informationen enthält eine Programmbeschreibung, die man beim Einordnen des Programmes in die Bibliothek als Dokumentation hinterlegt. Sie sollte minde­ stens enthalten: 1. Programm - Name und - Typ (HP/UP) 2. Mathematische Grundlagen 3. Eingabe / Ausgabe Daten und zugehörige Formate 4. Abweichungen von Typ - Vereinbarung (Complex, Logical usw. ) 5. Bereiche (Dimension, Common, Equivalence) 6. (ggf. ) Parameterliste 7. Programmablaufplan / Struktogramm 8. Beispiel Auch an die Anfertigung einer Programmbeschreibung sollte man sich recht frühzeitig gewöhnen. Jede sprachliche Formulierung trägt einen signifikanten Akzent, mal kurz und bündig, mal detailliert informativ, mal mit dieser, mal mit jener Wortwahl - auch bei Programmiersprachen. Diese Nuancierungen lassen sich auch in den vorliegenden Programm­ Vorschlägen erkennen.