•  Back 
  •  Inhalt 
  •  Index 
  •  Tree View 
  •  Cross references 
  •  Hilfe 
  •  Show info about hypertext 
  •  View a new file 
Topic       : Dokumentation zum Library-Maker
Author      : Karsten Lüdersen @ HH
Version     : MKlib.hyp 2.49
Subject     : Programmieren/Basic
Nodes       : 162
Index Size  : 5558
HCP-Version : 4
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : 
@help       : Hilfe
@options    : +g -i +y +z -t4 -d24
@width      : 75
View Ref-FileAnforderungen an die Struktur von Libraries
Erste Hilfe
Tips für die Library-Programmierung                          Library-Maker

Falls der Library-Maker eine Library übersetzt und der Basic-Editor sie
ohne Fehlermeldung einlädt und auch der Compiler das Programm klaglos
übersetzt und das Programm (im Interpreter oder Compiler) trotzdem abstürzt
oder sonstwie merkwürdig verhält lesen Sie bitte auf jeden Fall die Seite
Erste Hilfe.

1. Vergessen Sie GOTO und GOSUB. Es gibt nichts, was sich nicht mit
anderen Konstruktionen auch erledigen läßt. Sämtliche GOTO/GOSUB-
Befehle in Verbindung mit ON lassen sich mindestens durch
entsprechende GEM-Aufrufe sauberer realisieren.

2. Die globale Fehlerbehandlungsroutine sollte nicht in der Library
stehen, damit sie bei der Programmierung am Hauptprogramm leicht
zugänglich ist. Außerdem sollte sie grundsätzlich mit COMPILER OFF/ON
geklammert sein, denn in Compilaten hat sie nichts zu suchen.

3. Benutzen Sie so wenig wie möglich globale Variablen. Jede globale
Variable ist eine potentielle Fehlerquelle. Das gilt erst recht für in
Libraries verwendete globale Variablen. Variablen, die Sie in mehreren
Library-Funktionen/Prozeduren benötigen, können Sie jetzt auch
Library-lokal definieren. Machen Sie davon Gebrauch, wenn die
BenutzerInnen der Library auf diese Variable keinen Zugriff haben
müssen.

4. Wenn die Library unbedingt globale Variablen benötigt (z.B. um sich
die Adresse eines RAM-Blocks zu merken), dann sollten diese einen
aussagekräftigen Namen bekommen. Es sollte also am Namen erkennbar
sein, wozu die Variable dient. Außerdem sollten die Namen so gewählt
werden, daß nicht die Gefahr besteht, daß sie in einem Programmtext
zufällig für einen anderen Zweck verwendet werden. Sie sollten auch
genau überlegen, welche Variablen für die AnwenderInnen der Library
überhaupt notwendig sind.

5. Dokumentieren sie alle in einer Library verwendeten globalen
Variablen, damit die AnwenderInnen der Library nicht von merkwürdigen
Seiteneffekten überrascht werden.

6. Jede Library die bestimmte Datenstrukturen voraussetzt sollte eine
INIT-Prozedur haben, in der sämtliche globalen Variablen initialisiert
und Arrays angelegt werden und insgesamt die Library in einen
definierten Grundzustand versetzt wird.

7. Wenn die notwendigen Datenstrukturen für eine Library RAM
beanspruchen sollte die Library auch eine EXIT-Prozedur haben, in der
z.B. belegte RAM-Blöcke freigegeben werden und Arrays auf ihre
Minimalgröße verkleinert werden.

8. Die leere Prozedur am Anfang einer Library sollte bei Aufruf eine
Versionsnummer und eventuell ein Erstellungsdatum ausgeben.

9. Nutzen Sie die LIB-ID für eine nähere Kennzeichnung Ihrer Library,
z.B. eine Versionsnummer bzw. nutzen Sie die Möglichkeit des
Zeitstempels in der LIBRARY CODE-Zeile.

10. Falls Sie das nicht ohnehin schon tun: Gewöhnen Sie sich an, in
jede Zeile nur einen Befehl zu schreiben und bei Schleifen und IF-
Strukturen die dazugehörigen Zeilen einzurücken.

11. Bevor Sie eine Library erzeugen, mit der Sie länger arbeiten
wollen oder die Sie auch veröffentlichen wollen, sollten Sie im Basic-
Editor "Aufräumen" aus dem Programm-Menü aufrufen. Der Editor löscht
dann alle nicht mehr benötigten Bezeichnernamen aus dem Quelltext der
Library. Nicht nur der Quelltext, auch die Library wird dadurch
kürzer. Der Library-Maker überprüft nämlich nicht, ob ein Bezeichner
in der Library überhaupt verwendet wird.

12. Lesen Sie die Seite Erste Hilfe.