Programm schreiben
3.1 Struktur:
3.1.1 Strukturüberlegungen auf Papier anstellen
Grundsätzlich sollte man immer vor dem eigentlichen Programm ein Konzept auf Papier erstellen. Dieses Konzept sollte
alle wichtigen Informationen über das Programm an sich als auch weitere Probleme enthalten. Zu den weiteren Problemen
kann man z.B. zählen, wie man etwas realisieren will. Da NIKI ein Programm ist, in dem man etwas Graphisches darstellt,
ist es nützlich, die Karte in ihrer Grundform sauber abzuzeichnen bzw. auszudrucken (z.B. durch Erstellung eines
Screenshots).
Man sollte immer die Karte zuerst genau studieren und sich dann stichpunktartig wichtige Kleinigkeiten vermerken. So ist
z.B. unser lager1.rob von der Grundform her sehr gleichmäßig und einfach. Die Gleichmäßigkeit werden
wir uns schon im folgenden Kapitel 4 zu Nutze machen.
Das Konzeptblatt sollte übersichtlich sein. Kommentare helfen es zu verstehen. Da jeder Mensch anders ist, ist die
Form eines solchen Konzeptblattes sehr individuell und daher nicht weiter vordefiniert. Man kann sogar ganze Rubriken machen
und darunter dann in Stichpunkten alles vermerken, was ein- und auffällt. Da unser lager1.rob relativ klein ist,
dürfte sich das Konzeptblatt in einem Umfang von etwa einer Seite befinden.
3.1.2 Überlegungen aus 3.1.1 auf ein Programm übertragen (theoretisch)
Nachdem wir ein Konzeptblatt haben, sollten wir uns darüber Gedanken machen, wie wir die Sache anpacken können.
Mit unserem bisherigen Wissen ist das noch schwer zu erledigen, aber von der Grundidee her kann man davon ausgehen, dass
man das gesamte Programm schreiben könnte, wenn man die Befehle zur Fortbewegung kennt (folgen). Im Moment wollen wir
ja nichts Weltbewegendes schaffen, sondern einfach nur das Programm schreiben, was der Teachin-Modus bereits geschrieben
hatte. Daher sehen wir uns einmal die Karte genauer an:
Ich habe bereits mit roten Pfeilen den Weg dargestellt, der zurückgelegt werden muss. Jeder Punkt heißt ein
Feld vor. An den Pfeilspitzen müssen wir entweder Gegenstände aufnehmen oder abgeben. Die letzte Pfeilspitze
ist das Zielfeld. Und schon haben wir den Weg, den wir programmieren wollen.
3.2 Befehle:
3.2.1 Standard-Fortbewegungsbefehle
Bevor wir ein Programm bauen, müssen wir erst einmal wissen, wie die Befehle lauten. Wie schon im vorigen Kapitel gezeigt sind Befehle in NIKI denkbar einfach (noch). In Kapitel 1 ging es um die Handsteuerung, in der wir vier Aktionen machen konnten: nach vorne gehen, nach links drehen, aufnehmen und abgeben. Genau diese Funktionen gibt es auch als Befehl, und zwar (gleiche Reihenfolge wie eben): vor, drehe_links, nimm_auf und gib_ab, wobei die Unterstriche (_) nicht optional sondern Teil des Befehls sind! Mit diesen vier Aktionen können wir uns wie in der Handsteuerung problemlos fortbewegen.
3.2.2 Ein einfaches Programm zur Fortbewegung schreiben
Zuerst geht es nur darum, dass wir uns fortbewegen können. Wir werden jetzt erst einmal das Grundgerüst eines Programms aufbauen. Die Erklärung werden wir uns später ansehen. Doch zuvor werden wir das lager1.rob laden. Im Moment (vgl. Zeichnung oben) haben wir momentan kaum Bewegungsfreiraum. Das ändern wir aber noch.
In der MS-DOS-Version müssen wir erst einmal ein leeres Editor-Fenster öffnen. Dazu gehen wir im Unterpunkt Roboterfeld auf New. Schon haben wir es. In der Windows-Version geht es ebenfalls einfach. Im Menü Datei finden wir den Eintrag Datei Neu und klicken ihn an.
Zuerst wollen wir aus dem Feld heraus. Daher ist oben links keine Wand und wir können raus. Bitte schreiben Sie das folgende Programm erst einmal ab:
PROGRAM laufen;
BEGIN
drehe_links;
vor;
vor;
drehe_links;
vor;
drehe_links;
drehe_links;
drehe_links;
vor;
drehe_links;
drehe_links;
drehe_links;
vor;
vor;
vor;
END.
Die Aufgabe besteht darin, ein wenig in der Karte herumzulaufen. Am besten ist es, wenn Sie ein wenig spielen und mal alle Befehle ausprobieren, ohne Rücksicht auf Verluste. Die Befehle können zwischen dem letzten vor; und dem END. eingesetzt werden. Bauen Sie auch einmal nimm_auf oder gib_ab ein, um die Fehlermeldungen kennen zu lernen. Hinter jedem Befehl kommt ein Semikolon, wie im letzten Kapitel schon gesagt.
3.3 Programm:
3.3.1 Programmaufbau
In 3.2.2 haben wir schon unser erstes Programm kennen gelernt. Wir werden noch in diesem Kapitel lernen, dass ein Programm nicht nur aus Befehlen bestehen muss, sondern auch aus so genannten Prozeduren. Der formale Aufbau eines Programms sieht folgendermaßen aus:
PROGRAM programmname;
{ Deklarationen von Prozeduren }
BEGIN
{ Befehle }
END.
Und wieder haben wir alte Bekannte getroffen: BEGIN und END.! Wie schon gesagt sind das ständige Begleiter in Programmiersprachen.
Aber dazu kommen wir erst gleich. Im Programm steht ja noch mehr. Jedes NIKI-Programm wird mit dem Schlüsselwort PROGRAM eingeleitet. Darauf folgt dann der Name des Programms und das Wichtigste: ein Semikolon. Jedes vergessene Semikolon verursacht einen Compilerfehler, daher ist es wichtig, sich anzueignen, an (fast) jedes Zeilenende eines zu setzen. Man muss sich dann nur merken, wo keins hingehört, wie z.B. hinter das BEGIN oder das letzte END im Programm. Dem Compiler wird also schon in der ersten Zeile klar gemacht, dass es sich um ein Programm handelt und dass das Programm einen Namen hat. Der Name an sich ist relativ variabel. Er muss jedoch mit einem Buchstaben beginnen und darf keine Sonderzeichen, erst recht kein Semikolon, enthalten. Namen wie a123 oder gerd sind daher absolut in Ordnung.
3.3.2 BEGIN...END. begreifen und anwenden
Der Programmrumpf wird zwischen BEGIN und END zusammengefasst. Alle Befehle, die dazwischen stehen, werden von NIKI ausgeführt. Steht z.B. dreimal vor; zwischen BEGIN und END, so geht NIKI drei Schritte vor. Das haben wir ja schon vorhin bei unserem Beispiel zur Fortbewegung gesehen. Aber zwischen den beiden Worten müssen nicht unbedingt Befehle stehen. Hier können auch Namen von vorher deklarierten Prozeduren stehen. Und diese Prozeduren werden wir uns doch gleich mal ansehen:
3.4 Prozeduren:
3.4.1 Was sind Prozeduren?
Weiter oben haben wir ja schon einen kleinen Einblick in Prozeduren gewonnen. Wie gesagt sind Prozeduren einfach nur eine Reihe von Befehlen. Die Prozeduren haben Namen, die ihnen vom Programmierer gegeben werden. Diese Namen können dann im Programmrumpf eingebettet werden und werden dann auch wie gewünscht ausgeführt. Prozeduren erleichtern dem Programmierer oft Arbeit und sind daher sehr beliebt. Wir werden noch in diesem Kapitel zwei Prozeduren schreiben, die uns das Arbeiten erleichtern.
3.4.2 Aufbau von Prozeduren Der formale Aufbau von Prozeduren ist dem eines Programms sehr ähnlich. Daher wird die Erklärung auch relativ dürftig ausfallen. Eine Prozedur wird folgendermaßen deklariert, also aufgebaut:
PROCEDURE prozedurname;
BEGIN
{ Befehle }
END;
Wie gesagt ist der Aufbau sehr einfach und dem eines Programms sehr ähnlich. Bitte beachten: hinter dem END steht ein Semikolon (;)!!! Ein Punkt wäre an dieser Stelle absolut falsch und führt zu einem Compilerfehler. Der Punkt ist wie schon gesagt zur Beendigung des gesamten Programms gedacht. Alles, was nach dem Punkt steht, wird nicht mehr mit übersetzt (compiliert)!
3.4.3 Prozeduren deklarieren
Lange Rede, verdammt viel Sinn: jetzt kommt der praktische Teil!!! Wie gesagt sollen uns Prozeduren das Leben vereinfachen. Denken wir mal kurz nach, was NIKI noch nicht kann, aber können sollte... Na gut, da gibt es einiges, aber realisierbar ist nicht viel. Aber da kommt einem doch gleich der Gedanke: NIKI kann sich nicht nach rechts drehen! Ja, nicht mal umdrehen kann er sich ohne zwei Mal nach links zu drehen! Bringen wir das mal in eine Prozedur. Will man NIKI nach rechts drehen, muss man drei mal drehe_links schreiben, will man NIKI umdrehen nur zwei mal. Also sollten wir das Umdrehen zuerst deklarieren (warum, sehen wir gleich). Wir deklarieren also:
PROCEDURE drehe_um;
BEGIN
drehe_links;
drehe_links;
END;
Nun scheint es ja so, als hätten wir mehr Arbeit gehabt als hätten wir nur zwei mal drehe_links geschrieben! Aber nur Geduld, das lohnt sich schon!
Jetzt wird auch klar, warum wir zuerst das Umdrehen (drehe_um) deklariert haben: das Rechtsdrehen besteht doch aus einmal umdrehen und ein weiteres Mal nach links drehen! Also können wir jetzt deklarieren:
PROCEDURE drehe_rechts;
BEGIN
drehe_um;
drehe_links;
END;
So, jetzt ist das schon mal klar. Aber das sieht immer noch so aus, als ob wir mehr gearbeitet hätten, als wir brauchen! Daher werden wir das jetzt mal in ein Programm einbinden, in dem sich NIKI fünfmal umdrehen soll und danach fünfmal nach rechts drehen soll. Ist zwar Unsinn, aber es geht ja ums Beispiel!!!
PROGRAM nonsense;
PROCEDURE drehe_um;
BEGIN
drehe_links;
drehe_links;
END;
PROCEDURE drehe_rechts;
BEGIN
drehe_um;
drehe_links;
END;
BEGIN
drehe_um;
drehe_um;
drehe_um;
drehe_um;
drehe_um;
drehe_rechts;
drehe_rechts;
drehe_rechts;
drehe_rechts;
drehe_rechts;
END.
Und jetzt sollte klar sein, was wir uns an Arbeit gespart haben: wir hätten 25-mal drehe_links eingeben müssen, um das zu erreichen! Gut, in diesem Beispiel wären das nur fünf Zeilen mehr als sonst, aber wie gesagt, es kommt ja darauf an, dass wir uns zu unserer Freude Arbeit erspart haben!
Im Beispiel haben wir übrigens gleich gesehen, dass man Prozeduren über deren Namen im Programmrumpf aufruft. Daher ist es auch sinnvoll, möglichst aussagekräftige Namen zu vergeben. Mit einem Namen wie xka23 kann man nicht viel anfangen und wenn man alle Prozeduren in der Art benannt hat, kommt man nicht wirklich mehr zurecht.
Noch was Wichtiges: hat man eine Prozedur einmal deklariert, dann kann man nicht eine neue Prozedur mit dem gleichen Namen deklarieren. Das führt zu einem Compilerfehler, weil der nicht weiß, welche Prozedur er ausführen soll. Auch daher ist es sinnvoll, den Prozeduren aussagekräftige Namen zu geben.
Eine letzte Sache noch: es fällt ja auf, dass ich einige Worte groß und andere klein geschrieben habe. Das ist im Programmieren so üblich. Auch die Tatsache, dass einige Zeilen eingerückt ist, ist keineswegs ein Fehler meinerseits, sondern zählt zum Programmierstil. Dazu wird es weiteres zu lesen geben im Kapitel 9, welches sich ausschließlich mit Stil befasst.
3.2 Befehle:
3.2.1 Standard-Fortbewegungsbefehle
Bevor wir ein Programm bauen, müssen wir erst einmal wissen, wie die Befehle lauten. Wie schon im vorigen Kapitel gezeigt sind Befehle in NIKI denkbar einfach (noch). In Kapitel 1 ging es um die Handsteuerung, in der wir vier Aktionen machen konnten: nach vorne gehen, nach links drehen, aufnehmen und abgeben. Genau diese Funktionen gibt es auch als Befehl, und zwar (gleiche Reihenfolge wie eben): vor, drehe_links, nimm_auf und gib_ab, wobei die Unterstriche (_) nicht optional sondern Teil des Befehls sind! Mit diesen vier Aktionen können wir uns wie in der Handsteuerung problemlos fortbewegen.
3.2.2 Ein einfaches Programm zur Fortbewegung schreiben
Zuerst geht es nur darum, dass wir uns fortbewegen können. Wir werden jetzt erst einmal das Grundgerüst eines Programms aufbauen. Die Erklärung werden wir uns später ansehen. Doch zuvor werden wir das lager1.rob laden. Im Moment (vgl. Zeichnung oben) haben wir momentan kaum Bewegungsfreiraum. Das ändern wir aber noch.
In der MS-DOS-Version müssen wir erst einmal ein leeres Editor-Fenster öffnen. Dazu gehen wir im Unterpunkt Roboterfeld auf New. Schon haben wir es. In der Windows-Version geht es ebenfalls einfach. Im Menü Datei finden wir den Eintrag Datei Neu und klicken ihn an.
Zuerst wollen wir aus dem Feld heraus. Daher ist oben links keine Wand und wir können raus. Bitte schreiben Sie das folgende Programm erst einmal ab:
PROGRAM laufen;
BEGIN
drehe_links;
vor;
vor;
drehe_links;
vor;
drehe_links;
drehe_links;
drehe_links;
vor;
drehe_links;
drehe_links;
drehe_links;
vor;
vor;
vor;
END.
Die Aufgabe besteht darin, ein wenig in der Karte herumzulaufen. Am besten ist es, wenn Sie ein wenig spielen und mal alle Befehle ausprobieren, ohne Rücksicht auf Verluste. Die Befehle können zwischen dem letzten vor; und dem END. eingesetzt werden. Bauen Sie auch einmal nimm_auf oder gib_ab ein, um die Fehlermeldungen kennen zu lernen. Hinter jedem Befehl kommt ein Semikolon, wie im letzten Kapitel schon gesagt.
3.3 Programm:
3.3.1 Programmaufbau
In 3.2.2 haben wir schon unser erstes Programm kennen gelernt. Wir werden noch in diesem Kapitel lernen, dass ein Programm nicht nur aus Befehlen bestehen muss, sondern auch aus so genannten Prozeduren. Der formale Aufbau eines Programms sieht folgendermaßen aus:
PROGRAM programmname;
{ Deklarationen von Prozeduren }
BEGIN
{ Befehle }
END.
Und wieder haben wir alte Bekannte getroffen: BEGIN und END.! Wie schon gesagt sind das ständige Begleiter in Programmiersprachen.
Aber dazu kommen wir erst gleich. Im Programm steht ja noch mehr. Jedes NIKI-Programm wird mit dem Schlüsselwort PROGRAM eingeleitet. Darauf folgt dann der Name des Programms und das Wichtigste: ein Semikolon. Jedes vergessene Semikolon verursacht einen Compilerfehler, daher ist es wichtig, sich anzueignen, an (fast) jedes Zeilenende eines zu setzen. Man muss sich dann nur merken, wo keins hingehört, wie z.B. hinter das BEGIN oder das letzte END im Programm. Dem Compiler wird also schon in der ersten Zeile klar gemacht, dass es sich um ein Programm handelt und dass das Programm einen Namen hat. Der Name an sich ist relativ variabel. Er muss jedoch mit einem Buchstaben beginnen und darf keine Sonderzeichen, erst recht kein Semikolon, enthalten. Namen wie a123 oder gerd sind daher absolut in Ordnung.
3.3.2 BEGIN...END. begreifen und anwenden
Der Programmrumpf wird zwischen BEGIN und END zusammengefasst. Alle Befehle, die dazwischen stehen, werden von NIKI ausgeführt. Steht z.B. dreimal vor; zwischen BEGIN und END, so geht NIKI drei Schritte vor. Das haben wir ja schon vorhin bei unserem Beispiel zur Fortbewegung gesehen. Aber zwischen den beiden Worten müssen nicht unbedingt Befehle stehen. Hier können auch Namen von vorher deklarierten Prozeduren stehen. Und diese Prozeduren werden wir uns doch gleich mal ansehen:
3.4 Prozeduren:
3.4.1 Was sind Prozeduren?
Weiter oben haben wir ja schon einen kleinen Einblick in Prozeduren gewonnen. Wie gesagt sind Prozeduren einfach nur eine Reihe von Befehlen. Die Prozeduren haben Namen, die ihnen vom Programmierer gegeben werden. Diese Namen können dann im Programmrumpf eingebettet werden und werden dann auch wie gewünscht ausgeführt. Prozeduren erleichtern dem Programmierer oft Arbeit und sind daher sehr beliebt. Wir werden noch in diesem Kapitel zwei Prozeduren schreiben, die uns das Arbeiten erleichtern.
3.4.2 Aufbau von Prozeduren Der formale Aufbau von Prozeduren ist dem eines Programms sehr ähnlich. Daher wird die Erklärung auch relativ dürftig ausfallen. Eine Prozedur wird folgendermaßen deklariert, also aufgebaut:
PROCEDURE prozedurname;
BEGIN
{ Befehle }
END;
Wie gesagt ist der Aufbau sehr einfach und dem eines Programms sehr ähnlich. Bitte beachten: hinter dem END steht ein Semikolon (;)!!! Ein Punkt wäre an dieser Stelle absolut falsch und führt zu einem Compilerfehler. Der Punkt ist wie schon gesagt zur Beendigung des gesamten Programms gedacht. Alles, was nach dem Punkt steht, wird nicht mehr mit übersetzt (compiliert)!
3.4.3 Prozeduren deklarieren
Lange Rede, verdammt viel Sinn: jetzt kommt der praktische Teil!!! Wie gesagt sollen uns Prozeduren das Leben vereinfachen. Denken wir mal kurz nach, was NIKI noch nicht kann, aber können sollte... Na gut, da gibt es einiges, aber realisierbar ist nicht viel. Aber da kommt einem doch gleich der Gedanke: NIKI kann sich nicht nach rechts drehen! Ja, nicht mal umdrehen kann er sich ohne zwei Mal nach links zu drehen! Bringen wir das mal in eine Prozedur. Will man NIKI nach rechts drehen, muss man drei mal drehe_links schreiben, will man NIKI umdrehen nur zwei mal. Also sollten wir das Umdrehen zuerst deklarieren (warum, sehen wir gleich). Wir deklarieren also:
PROCEDURE drehe_um;
BEGIN
drehe_links;
drehe_links;
END;
Nun scheint es ja so, als hätten wir mehr Arbeit gehabt als hätten wir nur zwei mal drehe_links geschrieben! Aber nur Geduld, das lohnt sich schon!
Jetzt wird auch klar, warum wir zuerst das Umdrehen (drehe_um) deklariert haben: das Rechtsdrehen besteht doch aus einmal umdrehen und ein weiteres Mal nach links drehen! Also können wir jetzt deklarieren:
PROCEDURE drehe_rechts;
BEGIN
drehe_um;
drehe_links;
END;
So, jetzt ist das schon mal klar. Aber das sieht immer noch so aus, als ob wir mehr gearbeitet hätten, als wir brauchen! Daher werden wir das jetzt mal in ein Programm einbinden, in dem sich NIKI fünfmal umdrehen soll und danach fünfmal nach rechts drehen soll. Ist zwar Unsinn, aber es geht ja ums Beispiel!!!
PROGRAM nonsense;
PROCEDURE drehe_um;
BEGIN
drehe_links;
drehe_links;
END;
PROCEDURE drehe_rechts;
BEGIN
drehe_um;
drehe_links;
END;
BEGIN
drehe_um;
drehe_um;
drehe_um;
drehe_um;
drehe_um;
drehe_rechts;
drehe_rechts;
drehe_rechts;
drehe_rechts;
drehe_rechts;
END.
Und jetzt sollte klar sein, was wir uns an Arbeit gespart haben: wir hätten 25-mal drehe_links eingeben müssen, um das zu erreichen! Gut, in diesem Beispiel wären das nur fünf Zeilen mehr als sonst, aber wie gesagt, es kommt ja darauf an, dass wir uns zu unserer Freude Arbeit erspart haben!
Im Beispiel haben wir übrigens gleich gesehen, dass man Prozeduren über deren Namen im Programmrumpf aufruft. Daher ist es auch sinnvoll, möglichst aussagekräftige Namen zu vergeben. Mit einem Namen wie xka23 kann man nicht viel anfangen und wenn man alle Prozeduren in der Art benannt hat, kommt man nicht wirklich mehr zurecht.
Noch was Wichtiges: hat man eine Prozedur einmal deklariert, dann kann man nicht eine neue Prozedur mit dem gleichen Namen deklarieren. Das führt zu einem Compilerfehler, weil der nicht weiß, welche Prozedur er ausführen soll. Auch daher ist es sinnvoll, den Prozeduren aussagekräftige Namen zu geben.
Eine letzte Sache noch: es fällt ja auf, dass ich einige Worte groß und andere klein geschrieben habe. Das ist im Programmieren so üblich. Auch die Tatsache, dass einige Zeilen eingerückt ist, ist keineswegs ein Fehler meinerseits, sondern zählt zum Programmierstil. Dazu wird es weiteres zu lesen geben im Kapitel 9, welches sich ausschließlich mit Stil befasst.