|
|
Bugfixes am Forum
Subdomains aktiviert
Counterscript entfernt
|
| |
|
 |
Benutzerhandbuch |
 |
|
Anhang 3
Programmiertechniken
·Namensgebung
·Anmerkungen und Kommentare
·Techniken der strukturierten Programmierung
·Modularisierung
·Nebenbei...
·Lesbarkeit des Programms
Dieses Kapitel enthält eine Reihe von Hinweisen und Tips, die dazu dienen, richtig lauffähige Blitz2-Programme zu schreiben.
Namensgebung
Die Regeln
Bei der Vergabe von Variablennamen und Namen für Labels (Sprungmarken) müssen folgende Regeln beachtet werden:
· Namen können beliebig lang sein
· Namen müssen mit einem Buchstaben (A..Z, a..z) oder einem 'Underscore' (Unterstreichung) beginnen
· Namen dürfen nur alphanumerische Zeichen (Buchstaben und Zahlen) und Underscores enthalten
· Namen dürfen nicht mit den selben Buchstaben beginnen, wie einer der Blitz2-Befehle
Im übrigen wird bei Variablen- und Labelnamen die Groß- und Kleinschreibung berücksichtigt, d.h. die Variablen meinschiff und MeinSchiff haben nichts miteinander zu tun.
Stil
Es gibt viele Methoden der Namensgebung, die das Programmieren erleichtern. Im folgenden werden einige Richtlinien genannt, die dazu dienen, den Überblick zu behalten, wenn das Programm immer weiter anwächst und mehr und mehr Variablen und Labels verwendet werden.
Das wichtigste ist jedoch, den einmal gewählten Stil beizubehalten.
Es ist sinnvoll, Variablen und Labels in Gruppen zusammenzufassen und diese Gruppenzugehörigkeit in die Namensgebung einfließen zu lassen. Dadurch erhöht sich der Informationsgehalt der Namen. Gruppen können folgendermaßen gekennzeichnet werden:
· nur Großbuchstaben "NAME", große Anfangsbuchstaben "Name" oder nur Kleinbuchstaben "name"
· einzelne Buchstaben "l", Worte "Loop" oder Doppelworte "MainLoop"
· Underscore am Anfang "_loop" oder in der Mitte "main_loop"
· numerische Zusätze wie "loop1", loop2" usw.
Die Namensgebung ist eine Frage des persönlichen Stils, aber durch die Beibehaltung eines Stils und die Verwendung von "sinnvollen" Namen kann die Lesbarkeit eines Programms wesentlich erhöht und die Fehlersuche erleichtert werden.
Häufige Probleme bei der Namensgebung
Der folgende Abschnitt beschreibt einige der Probleme, die bei schlechter Namensgebung auftreten können.
Wenn irrtümlich auf eine noch nicht vereinbarte Variable zugegriffen wird (weil der falsche Name verwendet wurde), meldet der Compiler keinen Fehler, sondern legt eine neue Variable an und initialisiert sie mit dem Wert 0. Diese Gefahr kann durch eine einheitliche Namenskonvention verringert werden.
Es verlangsamt die Programmentwicklung, wenn immer wieder zum Anfang des Programmcode zurückgegangen werden muß, weil vergessen wurde, wie die Variablen hießen. Eine handgeschriebene Liste neben der Tastatur erleichtert das Nachschlagen.
Die Verwendung von langen Namen erhöht zwar die Lesbarkeit, birgt aber auch die Gefahr von vermehrten Tippfehlern.
Die Vergabe von vulgären oder obszönen Namen kann zwar ganz lustig sein, sollte aber vermieden werden, wenn andere Leute den Code lesen.
Anmerkungen und Kommentare
Im Gegensatz zu anderen BASIC-Versionen wird bei Blitz2 nicht die Anweisung REM verwendet, um einen Kommentar zu kennzeichnen, sondern das Semikolon. Alles was hinter einem Semikolon bis zum Ende der Zeile folgt, wird als Kommentar betrachtet und vom Compiler ignoriert. Auf diese Weise können Programme dokumentiert werden.
Wenn alle Routinen entsprechend kommentiert sind, können diese in zukünftigen Projekten weiterverwendet werden. Nichts ist so lästig, wie eine früher einmal entwickelte Routine zu finden, und raten zu müssen, was sie wohl macht.
Obwohl es vielleicht ein wenig kleinkariert erscheint, sollte wirklich die Funktionsweise jeder Routine genau beschrieben werden, es lohnt sich.
Außerdem empfiehlt es sich, in einem Abschnitt am Anfang des Programms eine Dokumentation einzufügen. Diese sollte Copyright-Vermerke, eine Liste der vorgenommenen Änderungen (mit Datum) sowie eine Beschreibung sämtlicher Variablen des Programms enthalten.
Techniken der strukturierten Programmierung
Ein wesentliches Merkmal eines strukturierten Programms ist das Einrücken von zusammenhängenden Code-Abschnitten. Hierdurch wird schon optisch eine Struktur des Programms erkennbar.
Dies betrifft vor allem den Inhalt von Schleifen, aber auch andere Kontrollstrukturen.
Der Blitz2 Editor bietet zwei verschiedene Möglichkeiten Programmzeilen einzurücken. Um einzelne Zeilen einzurücken kann die TAB-Taste verwendet. Mit der BLOCK TAB Funktion (A[ und A]) können ganze Bereiche gemeinsam eingerückt werden. Die Positionen der Tabulatorsprünge können im Menü DEFAULTS eingestellt werden.
Die Tastenkombination SHIFT-PfeilLinks dient dazu, den Cursor in die selbe Spalte wie die darüberliegende Zeile zu positionieren.
Modularisierung
Eine sorgfältige Konzeptplanung ist das wichtigste bei der Software-Entwicklung. Diese führt zu einer Zerlegung des Projekts in kleinere Teile, nur so lassen sich alptraumartige Spaghetti-Programme vermeiden.
Nach der Entscheidung darüber, wie das Programm unterteilt werden soll, empfiehlt es sich, mit den schwierigsten Teilen zu beginnen und diese auszutesten, solange das Programm noch klein und überschaubar ist. Denn je größer das Programm ist, desto langwieriger wird die Fehlersuche.
Das gleiche gilt für die Zeit, die man auf den Compiler warten muß, wenn man Fehler sucht oder kleine Änderungen vorgenommen hat und deswegen das gesamte Programm neu compilieren muß. Hier ist es empfehlenswert, den in Frage kommenden Abschnitt aus dem Hauptprogramm herauszunehmen und in einem kleineren Testprogramm auszutesten.
Einige Dinge sollten bei der Entwicklung von Routinen beachtet werden:
· Eine Routine muß mit allen möglichen Situationen fertig werden.
· Der Programmcode sollte effizient sein.
· Modularisierung, d.h. eine Routine kehrt immer dahin zurück, von wo aus sie aufgerufen wurde.
· Ausführlich dokumentieren.
· Besonders den Gebrauch von globalen Variablen und Feldern kommentieren.
· Alle Routinen müssen 'wasserdicht' sein, d.h. sie dürfen nicht abstürzen, wenn sie mit den falschen Parametern gerufen werden.
· Programmabschnitte einrücken und die Zeilenlänge begrenzen, so daß der Code lesbar bleibt.
Nebenbei...
Neben der Kommentierung der einzelnen Routinen im Programm selbst, ist es nützlich, sich eine handgeschriebene Stichwortliste anzulegen, auf der z.B. notiert wird, welche Variablen in mehreren Routinen verwendet werden und welche Routinen noch überarbeitet werden müssen.
Eine solche Liste dient auch dazu, Probleme im voraus zu erkennen.
Einer der größten Fehler beim Programmieren ist es, mit einer Routine zu beginnen, die zum eigenen Funktionieren die Existenz mehrerer anderer Routinen voraussetzt. Es sollten immer zunächst solche Routinen entwickelt werden, die unabhängig getestet werden können. So vermeidet man Situationen wie diese: man hat gerade 5 neue ungetestete Routinen eingebunden und nun muß man versuchen, einen Fehler zu finden, der in jeder dieser Routinen aufgetreten sein kann. Modularität ist auch bei der Entwicklung eines Programmes der effektivste Weg.
Lesbarkeit des Programms
Die Lesbarkeit des Programmcodes ist der nächste Punkt auf der Prioritätenliste bei der Programmentwicklung.
Die beiden wesentlichen Aspekte sind: das Einrücken von geschachtelten Anweisungen und die Minimierung der Zeilenlänge.
Das folgende Beispiel zeigt das Einrücken von verschachteltem Code:
If ReadFile (0,"phonebook.data")
FileInput 0
While NOT Eof(0)
If AddItem(people())
For i=0 To #num-1
\info[i]=Edit$(128)
Next
EndIf
Wend
EndIf
Hierdurch wird es möglich, auf dem ersten Blick zu erkennen, welche Anweisungen innerhalb von welcher Struktur ausgeführt werden. Ebenso kann leicht ermittelt werden, ob für jedes If auch ein EndIf oder für jedes While auch ein Wend vorhanden ist, indem einfach in der entsprechenden Spalte nach dem Gegenstück gesucht wird.
|
|
|
|
|
|
|
