Programmieren in C

| ### Programmieren in C von Prof. Jürgen Plate

Programmieren ist wie Küssen:
Man kann darüber reden,
man kann es beschreiben,
aber man weiß erst was es bedeutet,
wenn man es getan hat.

Andree Beaulieu-Green

# Vorwort

Dies Skript unterstützt die Vorlesungen "Algorithmen und Datenstrukturen" sowie "Programmieren in C" im Grundstudium. Beide Vorlesungen sind miteinander verwoben, da die Bearbeitung von Daten mit geeigneten Verfahren in einem Computer zwangsläfig da Schreiben von Programmen nach sich zieht. Daher wird auch im ersten Semester schon programmiert werden und auch im zweiten Semester weitere Algorithmen und Datenstrukturen behandelt.

Der wichtigste Aspekt ist in jedem Fall, den Studenten zu vermitteln, wie sie ingenieurgemäß von einer abstrakten Problemstellung zur konkreten Lösung als Computerprogramm gelangen. Die Beschreibung der Problemstellung (Kundenanforderungen) ist hier meistens bereits vorgegeben, das Kundengespräch entfällt. Grundlegende Methodiken des systematischen Softwareentwurfs und die Programmiersprache C dienen dabei als notwendige Vehikel.

Warum ist das wichtig? Jeder Elektrotechnik-Ingenieur, gleich welcher Fachrichtung, erstellt heutzutage mehr oder minder komplexe Programme; und sei es, daß er 'nur' sein Tabellenkalkulations- oder Texterstellungsprogramm um spezielle Funktionen erweitert.

Das Inhaltsverzeichnis ist - wie das Skript - eine lineare Aufschreibung der Inhalte, wohingegen die Vorlesung dynamisch die jeweils notwendigen Abschnitte und Konstrukte der Sprache C herausgreift. Parallel zu diesem Skript ist eine Referenz der Sprache C zugreifbar. Auf diese, bzw. entsprechende Literatur, kann zurückgegriffen werden, wenn es um spezielle Einzelheiten der Programmiersprache C geht.

Dieses Skript paßt nicht geradlinig zur Vorlesung. Mann könnte es eher als "nebenläufig" bezeichen. Es enthält Redundanz, Hintergrundinfos und Dinge, die ich in der Vorlesung nur streife. Dafür gibt's in der Vorlesung Dinge, die nicht im Skript stehen.
Das Skript will Ihnen auch einige grundlegende Algorithmen mitgeben. Auch diese werden nicht alle in der Vorlesung behandelt. Sie helfen aber dabei, Techniken der Programmierung "abzuschauen". Denn durch Üben und durch das Studium von Beispielen begreift man ein neues Fachgebiet am schnellsten. Programmieren macht da keine Ausnahme, es ist wie Auto fahren oder Hochseilartistik hauptsächlich eine Sache der Übung.

Die Informatik und Softwaretechnik sind recht junge Ingenieurwissenschaften. Die meisten Informatik-Fachbereiche entstanden erst nach 1980 und der Weg vom Probieren und Basteln hin zu einer systematischen Form der Softwareerstellung ist längst noch nicht abgeschlossen. Beim Softwareentwickler ist oftmals noch die Versuchung riesengroß einfach 'drauflos' zu programmieren:

Die zu lösende Problemstellung, sprich die Kundenanforderungen, werden oftmals ungenügend und unvollständig erfaßt. An Stelle einer wohlüberlegten technischen Lösung in Form eines zeitgemäßen Softwareentwurfs stürzt sich der Programmierer auf das, was eigentlich erst sehr viel später kommt: das Programmieren. Es wird 'wild' drauf los programmiert und manchmal das Programm, sobald es zum ersten Mal funktioniert, auf die Seite gelegt und in 'Rohfassung' dem Kunden ausgeliefert. Das Erwachen folgt in der Regel schnell: der Kunde fühlt sich mißverstanden und mißbraucht. Er bekommt eine Software, die oftmals nicht das tut was er wirklich braucht, zu 'ineffizient' ist und er fühlt sich als 'Versuchskanninchen' weil die Qualität nicht stimmt und er unfreiwillig zum Fehlerfinder wird. Das Geld ist ausgegeben und Änderungen bzw. Erweiterungen an der Software sind in diesen Fällen am Besten nur durch Wegwerfen und Neuerstellung machbar. Ein Zustand der auf Dauer nicht tragbar (finanzierbar) ist.

In den letzten Jahren wurden beachtliche Fortschritte in der Methodik der Softwareerstellung gemacht. Es entstand die Disziplin des Softwareengineerings (Softwaretechnik), die auch von wissenschaftlicher Seite erforscht und behandelt wird. Prägend in den letzten zwei Dekanden im Bereich Programmiertechniken waren Ideen, wie die der strukturierten Programmierung, die sich später zur modularen Programmierung wandelte, und seit Anfang der neunziger Jahre die der objektorientierten Programmierung. Aber heute kann festgestellt werden: Keine brachte letztendlich die ultimative Lösung. Wenn man heute Programme analysiert, manchmal sogar aus führenden Firmen, so sind sie oftmals kaum besser als das, was man bereits früher als Bastelei abqualifiziert hat.

Woran liegt das? Es gibt keine einfache Antwort auf diese Frage. Einerseits sind z.B. strukturierte Programmiersprachen heute wenig gefragt, außer vielleicht in Ausbildungsstätten. Die Hardware hat in ihrer Leistung und Speicherkapazität in den letzten 10 Jahren derart enorm zugenommen, daß dieser Rückschritt in der Software scheinbar kompensiert wird. Die Rechner wachsen, haben also für komplexere und dickere Software Platz. Es ist nicht zu kritisieren, daß die Software umfangreich ist, sondern daß sie umübersichtlich und somit fehlerbehaftet ist. Man weiß, wie es besser zu machen ist, aber man tut es nicht. "Es lohnt sich nicht, saubere Software zu schreiben", so bekommt man zu hören, "es erfordert zuviel Denkarbeit von hochbezahltem Personal".

Was kann man ändern? Besser ausbilden! Softwareentwickler ist ein 'Handwerker' kein Künstler; und 'Übung macht den Meister'. Sinn dieser Vorlesung ist es daher, Ihnen die für eine erfolgreiche Softwareentwicklung notwendige 'Denke' und das grundlegende Programmierhandwerk unter Verwendung der Programmiersprache C nahezubringen.

Dazu gehört auch,

- daß Sie nachdenken, bevor sie in die Tasten hacken.
- daß Sie sich einen halbwegs klaren Stil aneignen.
- daß Sie lernen, Fallstricke und Unsauberkeiten der Sprache richtig zu behandeln.

Noch drei Lebensregeln für Programmierer:

- Die besten Programme entstehen beim Spazierengehen mit oder ohne Hund, am Strand oder sonst irgendwo, nur nicht vor dem Bildschirm. Nachdenken bringt immer bessere Ergebnisse als die so oft anzutreffende "Try and Error-Methode".
- Wenn Sie glauben, Sie haben den Algorithmus begriffen, erklären Sie ihn Ihrem Teddybären. Der hört geduldig und aufmerksam zu und beim Erklären finden Sie Ihre Denkfehler - oder Sie kommen erst in diesem Moment drauf, wie der Algorithmus als Programm aussehen muss.
- Schreiben Sie erst den (Kopf-)Kommentar einer Funktion/Methode, die Sie programmieren wollen, und dann erst den Code, dann haben Sie noch einmal zusammengefasst, was Sie nun programmieren wollen.

Ein Skript wie dieses ist meist aus dem Team heraus entstanden. Darum möchte ich mich an dieser Stelle bei den Kollegen und Mitarbeitern bedanken, die zum Skriptum und zum Aufbau des vorlesungsbegleitenden Praktikums beigetragen haben: Dr. Heribert Kristl, Dr. Walter Ries, Dr. Rainer Seck, Dr. Rainer Thomas, Jörg Holzmann und Walter Tasin.

## Nachruf

Edsger Wybe Dijkstra
Programmierer und Mathematiker
Geboren am 11. Mai 1930 in Rotterdam
Gestorben am 6. August 2002 in Nuenen

Der Akademikersohn genoss eine gute Schulbildung, Latein und Altgriechisch inklusive. Er studierte Physik und Mathematik, begann 1951, während eines Sommerkurses in Cambridge, mit dem Programmieren. Mit 32 Jahren wurde er Mathematik-Professor in Eindhoven. Dijkstra, ein Pionier der Informatik, sah Logik als Basis der Programmlerkunst an. Er predigte die Eleganz der Einfachheit, getreu eines Satzes seiner Mutter, einer Mathematikerin: "Wer mehr als fünf Zeilen braucht, um etwas zu beweisen, ist auf dem falschen Weg." Als er bei seiner Heirat 1957 als Beruf Programmierer angab, monierte das Standesamt: So etwas gebe es nicht.
Im Jahr zuvor hatte er eines Morgens in einem Amsterdamer Cafä den später nach ihm benannten Dijkstra-Algorithmus entdeckt, der die kürzeste Entfernung zweier Punkte voneinander verlässlich bestimmt. Er widmete sich auch dem "dining philosophers problem": Fünf Denker sitzen mit je einer Schale Reis und je nur einem Essstäbchen am Tisch. Wie muss der Ablauf aussehen, damit keiner verhungert? Die Lösung des Rätsels half bei der Architektur von Betriebssysthemen und Netzwerken. Große Resonanz hatte seine 1968 veröffentlichte Kritik an Programmiersprachen wie Fortran, Cobol und Basic, die "den Geist verkrüppeln". Den Studenten riet Dijkstra: "Tue nur, was nur Du tun kannst."
Der"Guru des strukturierten Codes" erhielt eine Fülle von Preisen und Ehrun gen, 1972 etwa den Turing Award. Experten in aller Welt beglückte er mit reger Korrespondenz. Über 1300 dieser Notizen, nach seinen Initialen "EWDs" genannt, hält die Universität Texas, wo Dijkstra von 1984 bis 1999 lehrte, im Internet bereit (http://www.cs.utexas.edu/users/EWD). Die Kollegen riefen ihm nach,was Phaidon einst zum Tod des Sokrates sagte: Dass er "der Trefflichste war und auch sonst der Vernünftigste und Gerechteste".
Tim Murphy

Zum Inhaltsverzeichnis | Zum nächsten Abschnitt

###### Copyright © FH München, FB 04, Prof. Jürgen Plate

###### Letzte Aktualisierung: 15. Mai 2010