Ergänzungen zum Visual Basic Crash Kursus

Inzwischen gibt es 5 Lektionen im Visual Basic Crashkursus. Wir haben verschiedenste Möglichkeiten kennengelernt, Lichtsteuerung über eine DMX Karte zu betreiben. Der Kursus richtet sich überwiegend an Techniker, Beleuchter, Theateraktive und Musiker, die innerhalb ihres Budgets interessante Beleuchtung verwirklichen wollen und nicht viel Geld für eine umfangreiche Steuerung ausgeben wollen. Viele von Ihnen haben vielleicht noch keine große Programmiererfahrung und freuen sich nur, daß man auch mit einfachen Mitteln einiges erreichen kann. Wahrscheinlich ist Ihnen bei jedem Projekt etwas eingefallen, wie man es verändern und erweitern kann, um dem persönlichen Bedarf besser gerecht zu werden. Hier möchte ich nun ansetzen und einige Grundlagen zum Programmieren besprechen, damit man seine Projekt übersichtlich und schnell programmieren kann.

Visual Basic ermuntert einen, erst einmal drauflos zu arbeiten wenn vielleicht eine genauere Analyse des Problems und des daraus entstehenden Projektes sinnvoller wäre. Öfter habe ich meine Layouts komplett ändern müssen, weil ich am Anfang nur mal eben so eine Aufgabe angefangen habe. So möchte verschiedene Hinweise zum strukturierten Programmieren geben und dies anhand der Scanner Steuerung verschiedene Möglichkeiten zu zeigen.

Im ersten Teil werde ich überwiegend Ideen aus dem Buch "Basic with Style" von Paul Nagin und Henry F. Ledgard aufgreifen. Das Buch ist schon 1978 im Hayden Verlag erschienen, meine Ausgabe war von 1986. Obwohl es in Bezug auf die Computertechnik schon uralt ist und die Entwicklung der Programmiersprache Basic gravierende Änderungen durchlaufen hat, hat es für mich seine Aktualität behalten. Die Zitate sind von mir frei aus dem Englischen übersetzt.

Im zweiten Teil will ich einige Hinweise zu Visual Basic direkt geben, und im dritten Teil dann noch etwas das Debugging ansprechen.


Lichtsteuerungen sind Anwendungen, die praktisch in Echtzeit laufen müssen. Hier muß man sich der Einschränkungen, die Windows vorgibt, bewußt sein. Man kann es kaum beeinflussen, ob während einer Programmausführung ein anderes Programm auch bearbeitet wird, und wenn erst einmal ein anderes Programm aktiv ist, dann hat man gar keinen Einfluß darauf, wann das eigene Programm weiterarbeiten darf. Ein zeitkritisches Programm sollte also immer ausschließlich auf dem Rechner aktiv sein. Wer z.B. eine Textverarbeitung im Hintergrund geöffnet hat (vielleicht will man sich zwischendurch ja nur Notizen über die Beleuchtung aufschreiben), braucht sich nicht zu wundern, wenn plötzlich während einer Überblendung das Programm stehenbleibt und die Textverarbeitung eine Sicherheitskopie des Textes anlegt. Der Beleuchtungseffekt ist natürlich anders als erwünscht.

Zurück zum Anfang


Teil I

"Ziel beim Programmieren muß es sein, ein Programm zu schreiben, das auf Anhieb richtig läuft, und das ein anderer herausfinden kann, was und warum etwas getan wird".

Der Weg dazu führt über 19 "Programming Proverbs" die nachfolgend erläutert werden.

Ein guter Start ist das halbe Rennen

Kein noch so großer Zeitdruck darf einen in die Versuchung bringen, sofort mit dem Programmieren zu beginnen, ohne vorherige Planung sind die ersten Fehler schon vorprogrammiert. Also "Stop - Ruhe bewahren - methodisch weiterarbeiten.

Je genauer ein Problem definiert ist, desto einfacher hat man es bei der Arbeit. Wenn ich ein Ziel habe, kann ich es auch gezielt ansteuern. Zu einer kompletten Definition gehören:

Komplette Beschreibung aller Ein- und Ausgaben, vollständige Definition aller Berechnungen. Übrigens ist die ein erheblicher Aufwand, der nur zu gerne übergangen wird um schnell vorwärts zu kommen, um endlich programmieren zu können. Eine gute schriftliche Definition zahlt sich zum Schluß immer aus.

Wenn man Programme nicht nur für sich schreibt, ist im allgemeinen eine Dokumentation notwendig. Hier ermöglicht die frühzeitige Integration von Programm und Dokumentation, daß Gedanken wesentlich besser ersichtlich sind, daß man sich überlegen muß, wie einzelnen Funktionen ausgeführt werden sollten (wenn etwas schwierig zu beschreiben ist, ist es sicherlich auch nicht einfach zu bedienen). Falls ein Fremder die Dokumentation schreibt, ist hier auch schon ein guter Gedankenaustausch zwischen Anwender und Programmierer gegeben.

Man sollte sich zuerst einmal die Zeit nehmen, in Ruhe das Problem zu überdenken, sich die Struktur des Programms zu überlegen etc. Es ist nämlich viel einfacher einen schlechten Gedanken zu entdecken, als ein schlechtes Programm.

Ein Programmieren von Oben nach Unten, also vom Übergeordneten Gedanken hin zum Detail, hat viele Vorteile. Man entwickelt zuerst die oberen Ebenen, geht dann eine Ebene tiefer usw. Dadurch ist man lange Zeit Programmsprachen unabhängig (die gleiche Struktur läßt sich in Visual Basic, Pascal oder auch C verwenden).

Man kann Details auf eine spätere Ebenen verschieben, und behält dabei die wichtigen Dinge im Auge.

Man definiert rechtzeitig Übergabeparameter für Subroutinen und Funktionen, da man weiß, welche Werte man hat, und welche man braucht.

Jede Ebene läßt sich verifizieren, ohne daß das Programm komplett ausgearbeitet sein muß.

Hier ist Visual Basic nicht ganz so hilfreich. Es ermuntert einen geradezu "mal eben" eine Routine für ein bestimmtes Element zu schreiben ohne sich vorher Gedanken darüber zu machen, an welcher Stelle welche Werte denn genau benötigt werden. Das bewirkt dann, daß man eine Routine zu einem späteren Zeitpunkt neu schreibt bzw. ändert, weil nicht alles berücksichtigt worden ist.

Einhalten der logischen Struktur

Gute Programme haben übersichtliche Strukturen, einzelne Units sind relativ klein und übersichtlich. Es gibt dann wenige (im besten Fall nur einen) Übergänge zwischen den logischen Blöcken.

Oft neigt man dazu, alles in einer einzigen Routine berechnen zu lassen. Jedoch sollte man möglichst Unterberechnungen auch in getrennten Subroutines durchführen. Oft stellt man dann später heraus, daß die diese Subroutine auch von anderen Stellen aus nutzen läßt.

Das hat sich wohl hoffentlich bei Visual Basic von selbst erledigt.

Auch hier unterstützt ein Visual Basic sehr gut, automatisches Einrücken und die Möglichkeit von belieben Leerzeilen und Kommentaren erleichtern die Lesbarkeit des Programms.

Schreiben des Codes

Ein Gedanke, der "offensichtlich" ist, und den man auch offensichtlich programmiert hat, kann schon nach kurzer Zeit nicht mehr nachvollziehbar sein. Man sollte sich bemühen, so ausführlich zu kommentieren, daß jederzeit eine weiter Person ohne zusätzliche Erklärung das Programm nachvollziehen kann. dazu gehört das Beschreiben von allen benutzten Variablen und Konstanten, Kommentare zur logischen Struktur (was wird in dieser Schleife gemacht? Auf welche Werte teste ich Grenzen etc.) und die Beschreibung von Übergabewerten.

Der Visual Basic Compiler erkennt sehr viele Fehler, es geht schnell mal eben einen Lauf zu machen. Dennoch sollten schon vorher keine Fehler in der Syntax gemacht werden. Erstens wird nicht alles erkannt, und einen Laufzeitfehler zu finden ist noch schwieriger.

Visual Basic unterstützt einen dabei allerdings sehr gut, sobald man den Cursor auf ein Schlüsselwort plaziert hat und F1 drückt, erscheint sofort zu diesem Punkt die passende Erklärung. Sobald man irgendwelche Bedenken über die Syntax hat, sollte man den Hilfepunkt aufrufen.

Ein guter Programmierer schreibt Code, der einfach zu lesen ist. Man sollte tunlichst vermeiden, mit "Trick" zu programmieren, um etwa ein paar Zeilen Code oder ein paar Millisekunden Ausführungszeit zu sparen. Im Normalfall sind nur wenige Stellen in einem Programm zeitkritisch.

Den Anwender interessiert nur, wie ein Programm bedient wird, und was als Ergebnis da herauskommt. Es lohnt sich, der Ausgabe auf Drucker und Bildschirm besondere Beachtung zu schenken.

Es lohnt sich, die Programmstruktur einmal von Hand zu durchlaufen, richtig den Source Code auf dem Papier nachfahren und mitrechnen. Besonders wichtig dabei ist das Austesten der Randbedingungen (Anfangs- und Endwerte von Schleifen, muß der Abbruch bei >= Erfolgen oder bei >), auch ist zu testen, was das Programm bei Fehleingaben macht (z.B. Eingabe eines Strings statt einer Zahl, Werte die außerhalb des Gültigkeitsbereich der Variablen liegen etc.)

Auch beim Austesten sollte man Top Down ein Programm nachvollziehen können.

und natürlich ..

Nachdem man eine Weile am eigene Programm gearbeitet hat, verliert man leicht den notwendigen Abstand zu seiner Arbeit. dadurch kann man leicht schlecht Strukturen oder mangelhafte Dokumentation übersehen. Ein Außenstehender erkennt jedoch leicht, wenn man unübersichtlich programmiert hat oder die Beschreibung im Handbuch nicht ausreicht.

Von Zeit zu Zeit sollte man ruhig das Handbuch seiner Programmiersprache erneut durchlesen. Dadurch erinnert man sich an selten benutze Funktionen, die man doch noch irgendwann einmal dringend braucht, man stell fest, wo eigene Unsicherheiten sind und kann gezielt einiges wiederholen.

Sollte einmal alles vertan sein, sich das Programm zu häufig geändert haben, muß man zuweilen noch einmal ganz von vorne anfangen. Bei einer soliden Vorbereitung und guten Definition wird es kaum dazu kommen, doch hin und wieder merkt man, daß man sich etwas verrannt hat. Bevor man jetzt mühevoll bestehende Fehler ausbügelt, ist ein kompletter Neustart vielleicht sinnvoller.

Zurück zum Anfang


Teil II

Es ist relativ einfach, in Visual Basic Programme zu schreiben. Sehr viele Verwaltungsaufgaben werden durch Visual Basic durchgeführt, außerdem ist es relativ einfach ein schönes Bildschirmlayout zu erstellen. Wesentlich schwieriger ist es allerdings, Visual Basic Programme zu lesen. Es gibt keine durchgängige Programmstruktur, Subroutinen sind über den gesamten Text ziemlich willkürlich verstreut. Jeder, der an Computern arbeitet, hat sicherlich schon einmal festgestellt, daß es zwischendurch sinnvoll und notwendig ist, eine Programmausdruck zu machen, um den Text besser lesen zu können. Ganz wesentlich trägt eine sinnvolle Benennung der einzelnen Elemente dazu bei, ein Programm lesbar zu machen.

Benennung von Steuerelementen:

"Sub Befehl1_Click" trägt sicherlich wenig dazu bei, festzustellen, um was für ein Element es sich handelt. Erst durch lesen des gesamten Codes kann man vielleicht erkennen, was damit gemeint ist.

Ich habe mir angewöhnt, nicht die automatische Namensgebung von Visual Basic zu verwenden, sondern suche Namen aus, aus denen möglichst direkt zu erkennen ist, welches Element dahinter steckt, und was damit gemacht werden soll. Da Visual Basic im Ausdruck alle Routinen alphabetisch ordnet, benenne ich die Elemente nach Art und Funktion. So sind die einzelnen Steuerelemente zusammenhängend aufgeführt.
Als Vorschlag:
Art Abkürzung Assoziation
Anzeige IMG image
Befehlsschaltfläche cmd command
Bezeichnungsfeld lbl lable
Bildfeld pic picture
Datei-Listenfeld fil files
Daten dat dates
Figur shp shape
Form frm form
Funktionen ---- keine
Gitternetz grd grid
Horizontale Bildlaufl hsb horis. scroll bar
Kombinationsfeld cbo combo
Kontrollkästchen chk checked
Laufwerk-Listenfeld drv drive
Linie lin line
Listenfeld lst list
Menü mnu menue
OLE ole ole
Optionsfeld opt option
Rahmen fra frame
Textfeld txt text
Vertikale Bildlaufl. vsb vertical scroll bar
Verzeichnis-Listenfeld dir directory
Zeitgeber tmr timer


VB Werkzeuge

So benenne ich z.B. den Command Button Ende "cmdEnde" die Funktion Click heißt dann automatisch "cmdEnde_Click".

Konstanten:

Alle Werte, die an mehr als einer Stelle gebraucht werden, sollten als Konstante definiert werden.So braucht bei einer Änderung nur ein Wert geändert werden und es werden im Programm alle Werte automatisch richtig angepaßt. Durch aussagekräftige Namen der Konstante wird das Programm wesentlich lesbarer.

Es lassen sich z.B. hervorragend die einzelnen Elemente eines Steuerelementenfeldes benennen und bei if oder case abfragen

If Index = Color then ....

Variablen:

Jede Variable soll ausdrücklich initialisiert werden (Option Explicit) und kurz beschrieben werden.


Teil III

ist noch in Arbeit und wird im Laufe des Monats folgen. Weitere Ergänzungen werde ich nach Lust und Bedarf schreiben.

Über Kommentare würde ich mich sehr freuen, am besten gleich per E-Mail. So kann ich auch am einfachsten herausfinden, was Sie daran interessiert hat, und was verbesserungsbedürftig ist.

Zurück zum Anfang

Florian Behrendt (Bergwerk01@aol-com) 5. März 1998