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.
Der Weg dazu führt über 19 "Programming Proverbs" die nachfolgend erläutert werden.
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.
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.
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.
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.
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 |
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.
Ü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.
Florian Behrendt (Bergwerk01@aol-com) 5. März 1998
