Einleitung

Die vorliegenden Programmierrichtlinien für VISUAL BASIC wurden für die Entwicklung unternehmensinterner und kundenbezogener Anwendungen entwickelt. Sie decken schwerpunktmäßig die allgemeinen Themenbereiche der VISUAL BASIC-Programmierung ab. Spezielle Aufgabenstellungen, die z.B. bei der Realisierung von DDE-, OLE-, ODBC-, GDI- und MDI-Anwendungen auftreten, werden von den Richtlinien nicht berücksichtigt. Entsprechende Ergänzungsrichtlinien sind im Bedarfsfall projektspezifisch zu erstellen.

Die Richtlinien gelten ab Windows 95 und Windows-NT und zwar für VISUAL BASIC ab Version 4.0.

Die vorliegenden Richtlinien enthalten einerseits Vorschriften und Empfehlungen für die Gestaltung graphischer Benutzeroberflächen mit VISUAL-BASIC, um die Bedienung und Nutzung von VISUAL BASIC-Anwendungen zu vereinheitlichen und zu erleichtern, und andererseits programmiertechnische Vorgaben und Empfehlungen, um die Stabilität, die Effizienz und insbesondere die Wartbarkeit von VISUAL BASIC-Anwendungen zu verbessern.

Portabilitätsaspekte spielen bei den vorliegenden Richtlinien keine Rolle, da VISUAL BASIC nur von einem Hersteller vertrieben wird.

Die vorliegenden Richtlinien sind nur als allgemeiner Rahmen zu verstehen. In größeren Projekten sollten vor Projektbeginn zusätzliche, projektspezifische Richtlinien (Art der Kommentierung, Vorgabe von Prozedurköpfen, ...) verbindlich festgelegt werden.

Die Richtlinien sind bei der Erstellung von VISUAL BASIC-Applikationen verbindlich. Alle Empfehlungen ("Soll-Regeln") sind als Hilfestellung gedacht und nach Möglichkeit zu berücksichtigen. Abweichungen von den Programmierrichtlinien sind nur in begründeten Ausnahmefällen erlaubt und müssen in den entsprechenden Programmquellen zusätzlich dokumentiert werden.

Oberflächendesign

Allgemeine Kriterien der Benutzerfreundlichkeit

Unter Kriterien der Benutzerfreundlichkeit werden Eigenschaften von Programmen zusammengefaßt, die dem Benutzer einen effizienten und problemlosen Umgang mit den Programmen ermöglichen. Sie stellen wichtige, in der Regel meßbare Qualitätsmerkmale für die einzelnen Programme dar. Hierzu zählen nach SNI-Style-Guide [1] bzw. ISO-Norm 9241 [3] die folgenden 7 Grundsätze der Dialoggestaltung (die ISO-Norm-Definitionen sind hierbei jeweils in Kursivschrift angegeben):

Aufgabenangemessenheit:

Aufgabenangemessenheit ist dann gegeben, wenn ein System den Benutzer bei der Erfüllung seiner Aufgaben unterstützt.

Ein Dialog ist aufgabenangemessen, wenn er den Benutzer unterstützt, seine Arbeitsaufgabe effektiv und effizient zu erledigen.

Selbstbeschreibungsfähigkeit:

Selbstbeschreibungsfähigkeit eines Programms liegt vor, wenn die Benutzeroberfläche transparent ist und die zum Verständnis der Anwendung erforderlichen Hilfs- und Auskunftsfunktionen anbietet.

Ein Dialog ist selbstbeschreibungsfähig, wenn jeder einzelne Dialogschritt durch Rückmeldung des Dialogsystems unmittelbar verständlich ist oder dem Benutzer auf Anfrage erklärt wird.

Steuerbarkeit:

Ein Anwendungsprogramm ist steuerbar, wenn der Benutzer die Geschwindigkeit des Ablaufs sowie die Reihenfolge und Menge der Ein- und Ausgaben beeinflussen kann.

Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht wird.

Erwartungskonformität:

Ein Anwendungsprogramm ist erwartungskonform, wenn es in allen Zuständen dem Modell entspricht, das sich der Benutzer vom Anwendungsprogramm gebildet hat.

Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.B. den Kenntnissen aus dem Arbeitsgebiet, der Ausbildung und Erfahrung des Benutzers sowie den allgemein anerkannten Konventionen.

Fehlerrobustheit/Fehlertoleranz:

Ein Dialog ist fehlerrobust/fehlertolerant, wenn trotz erkennbar fehlerhafter Eingaben das beabsichtigte Arbeitsergebnis mit minimalem oder ohne Korrekturaufwand erreicht wird.

Individualisierbarkeit:

Eine Anwendung erfüllt dieses Kriterium, wenn der Benutzer die Anwendung seinen Bedürfnissen und persönlichen Fähigkeiten in Hinblick auf eine bestimmte Arbeitsaufgabe (z.B. durch die Definition benutzerspezifischer Arbeitsprofile) anpassen kann.

Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe, an Belange, individuelle Vorlieben des Benutzers und Benutzerfähigkeiten zuläßt.

Erlernbarkeit/Lernförderlichkeit:

Eine Anwendung und ihre Benutzeroberfläche sollten so strukturiert und konzipiert sein, daß sich das jeweilige Fachgebiet und die zugehörigen Arbeitsabläufe in der Anwendung widerspiegeln und der Einarbeitsaufwand für den Benutzer niedrig ist.

Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet.

Die oben genannten Kriterien der Bedienerfreundlichkeit sind in den Style-Guides [1] und [2] sowie in Teil 10 der ISO-Norm 9241 [3] detailliert beschrieben und erläutert.

Allgemeine Aspekte

Programme unter Windows (bzw. Windows NT) sind mit einer graphischen Benutzeroberfläche ausgestattet; die einzelnen Oberflächenelemente werden dabei von Windows verwaltet. VISUAL BASIC bietet zahlreiche, vordefinierte Oberflächenobjekte (Steuerelemente) an, die in einem visuellen Oberflächenentwurf einem sogenannten Werkzeugkasten entnommen und nach den Wünschen des Benutzers in einem Formular plaziert werden können. Formulare und die darin enthaltenen Steuerelemente können auf dem Bildschirm bzw. im Formular beliebig positioniert werden. Ferner kann ihr Erscheinungsbild (Größe, Rahmen, Farben, usw.) in einem weiten Rahmen über Eigenschaften variiert werden.

Alle von VISUAL BASIC bereitgestellten Oberflächenelemente sind mit ihren Eigenschaften und Methoden Windows-konform und genügen im Detail den von den einzelnen Style-Guides (siehe [1] und [2]) geforderten Kriterien der Bedienungsfreundlichkeit und Ergonomie. Hierzu zählen die Form, Anordnung und Funktionalität von automatisch erzeugten Bildlaufleisten sowie von Fenstermenü-, Verkleinerungs- und Vergrößereungsknopf usw.. Die folgenden Regeln und Empfehlungen beziehen sich daher nur auf die freien Gestaltungsmöglichkeiten seitens des Benutzers.

VISUAL BASIC-Anwendungen sollten sich grundsätzlich an Standard-Windows-Anwendungen orientieren, da Arbeitsweise, Struktur und Oberfläche dieser Anwendungen dem Benutzer in der Regel schon bekannt und vertraut sind. Der Benutzer sollte die von VISUAL BASIC angebotenen Oberflächenelemente im gleichen Sinne nutzen wie entsprechende Standard-Windows-Applikationen (z.B. sollten Befehlsschaltflächen für Aktionen und nicht für Textausgaben verwendet sowie Optionsfelder für Einzel- und Kontrollfelder für Mehrfach-Auswahlen - und nicht umgekehrt - benutzt werden). Ferner sollten keine eigenen Techniken und Objekte neu entwickelt werden, wenn VISUAL BASIC hierfür Standard-Verfahren und -Elemente anbietet (z.B. sollte für die Dateiauswahl sowie die dynamische Auswahl von Druckern, Farben und Schriften das Steuerelement "Gemeinsame Dialoge" anstelle von selbst definierten Dialogen benutzt werden).

Die Benutzeroberfläche muß zu jedem Zeitpunkt übersichtlich sein. Formulare sollten daher nicht mit Steuerelementen überladen werden, d.h. weniger wichtige oder selten benutzte Steuerelemente sollten gegebenenfalls in zusätzliche Formulare ausgelagert werden. Ferner sollten die Steuerelemente (auch Menüauswahlen), die ein Benutzer in einem speziellen Kontext oder auf Grund seiner Berechtigung nicht benutzen kann, ausgeblendet oder inaktiviert werden. Hierdurch werden auch Fehlbedienungen des Systems seitens des Benutzers von vornherein ausgeschlossen.

Die an der Benutzeroberfläche verfügbare Funktionalität sollte direkt per Standard-Menü ober Schaltflächen angeboten werden und somit unmittelbar für den Benutzer ersichtlich sein. Versteckte Funktionen, die z.B. per Doppelklick auf ein bestimmtes Steuerelement oder per Kontext-Menü aktiviert werden, sollten nur in Ausnahmefällen eingesetzt werden.

Die Interaktion mit dem System sollte nach Möglichkeit objektorientiert (z.B. "Bild aufhängen") erfolgen, da diese Arbeitsweise die reale Welt bis auf wenige Ausnahmen (z.B. "Suche Text") besser abbildet als die funktionsorientierte Sicht. Die objektorientierte Vorgehensweise gliedert sich i.a. in folgende Bedienschritte:

1. Objekt(e) selektieren
2. gewünschte Funktion auswählen
3. Funktion auf selektierten Objekten ausführen.


Anordnung und Form

Unsere gewohnte Blickrichtung ist "schreibbedingt" von links nach rechts und von oben nach unten orientiert. Diesem Umstand sollte bei der Anordnung der einzelnen Oberflächenelemente Rechnung getragen werden: Menüs sollten von links nach rechts angeordnet und möglichst in "pull-down-Form" eingesetzt werden, während wichtige bzw. häufig verwendete Objekte möglichst oben und/oder links zu positionieren sind.

Elemente, die eine logische Einheit bilden, sollten auch optisch zusammen gruppiert werden. Eine solche Gruppierung kann durch den Einsatz sogenannter Kontainerobjekte wie z.B. "frame", "panel" oder "shape" (Umrahmung durch Rechteck, ...) oder die Verwendung von Farben unterstützt und hervorgehoben werden. Innerhalb eines Menüs sollten zusammengehörende Menüpunkte gruppenweise durch einen bzw. zwei Striche voneinander abgesetzt werden.

Durch die Verwendung unterschiedlicher Cursorsymbole kann der Status der Anwendung verdeutlicht werden (z.B. durch Verwendung des Wartecursors ("Eieruhr"), um dem Benutzer einen Wartezustand anzuzeigen usw.).

Alle Steuerelemente sollten mit einem schwarzen Rand versehen werden. Hierdurch wird der Kontrast erhöht, was insbesondere bei unterschiedlichen Bildschirm-Auflösungen oder beim Einsatz von Monochrom-Bildschirmen anstelle von Farb-Displays wichtig ist.

Wenn möglich sollten 3D-Darstellungen den 2D-Darstellungen vorgezogen werden, da sie einen größeren Bezug zur Wirklichkeit haben und daher als angenehmer und wirkungsvoller empfunden werden.


Verwendung von Farben

Farben wirken anziehend und fokussierend. Wenn sie sinnvoll eingesetzt werden, erleichtern sie die Orientierung auf dem Bildschirm erheblich. Zu viele Farben verwirren jedoch nur.

Farben eignen sich zur Gruppierung, zur Unterscheidung (z.B. der Aus- und Eingabe) oder zur Hervorhebung von Elementen.

Aus physiologischer Sicht sollten keine Komplementärfarben (z.B. rot und grün) übereinander verwendet und keine größeren Flächen mit dunklen Farben gefärbt werden.

Eingabefelder sollten an Hand der Hintergrundfarbe direkt erkennbar sein, um Fehlversuchen bei der Eingabe vorzubeugen. Die Fordergrundfarbe wird bei Eingabefeldern erst nach der Eingabe, d.h. nach eventuellen Fehlversuchen, sichtbar; daher ist sie zur Kennzeichnung von Eingabebereichen nur bedingt geeignet.

Die Farben sollten zumindest innerhalb einer Anwendung die gleiche Bedeutung haben.

Farben sollten nach Möglichkeit gemäß den "natürlichen" Farbassoziationen der Benutzer gebraucht werden. Die "Warnfarbe" Rot sollte z.B. auf Fehler und potentielle Gefahrenquellen hinweisen.

Im Normalfall sollten - insbesondere für große Flächen - keine "schreienden", aggressiven Farben verwendet werden. Zusammen verwendete Farben sollten einerseits einen harmonischen Eindruck vermitteln und andererseits über den nötigen Kontrast verfügen. Um letzteres sicherzustellen, sollten Anwendungen auch auf Monochrom-Bildschirmen getestet werden.


Verwendung von Schriften

Schriften vermitteln ebenfalls einen starken visuellen Eindruck. Durch die Schriftart, Größe und Attribute (fett, kursiv, unterstrichen) können Texte gruppiert bzw. bestimmte Textteile hervorgehoben werden.

Kursive und Serifen-Schriften sind schwer zu lesen. Sie sollten daher nur in Ausnahmefällen eingesetzt werden.

In einer Anwendung sollten möglichst wenig unterschiedliche Schriftarten verwendet werden.

Schriften können durch Farben unterstützt und hervorgehoben werden. Hierbei muß jedoch auf den nötigen Kontrast geachtet werden; d.h. auch bei einer Monochrom-Darstellung muß die Schrift noch deutlich lesbar sein. Zwecks besserer Lesbarkeit sollten vorrangig dunkle (schwarze) Schriften auf hellem Untergrund verwendet werden.

Häufige Wechsel von Schriftart, Schriftgröße, Schriftattributen und Schriftfarben sind störend und verwirrend und daher zu vermeiden.


Animationseffekte

Von Animationseffekten (z.B. blinkenden oder scrollenden Texten) sollte nur sparsam Gebrauch gemacht werden.

Programmierung

Allgemeine Programmierregeln

Innerhalb eines Programmsystems sollte durchgängig ein übersichtlicher und konsistenter Programmierstil beibehalten werden, um den Code allgemein lesbar zu gestalten.

Doppelte Codierung (Redundanzen) sollte möglichst vermieden werden. Hierdurch wird in der Regel die Programmgröße reduziert, und Programmänderungen müssen später nicht an mehreren Stellen gleichzeitig durchgeführt werden.

Bei der Änderung eines Programmes sollten Stilbrüche vermieden werden. Ein einheitlicher mittelmäßiger Programmierstil ist besser als unterschiedliche, teils gute Programmierstile.

Sicherheit, Zuverlässigkeit und Transparenz haben Vorrang vor Geschwindigkeit und Performance. Tuning-Maßnahmen sind als additive Prozesse zu sehen.

Alle Softwareprodukte sind ausreichend zu dokumentieren.

Die vom Hersteller angebotenen Tools und Hilfsmittel zur Programmentwicklung (z.B. Debugger, Assistenten, ...) sollten intensiv genutzt werden.

Das Löschen von Daten sowie die Änderung kritischer Daten sollte man sich über zusätzliche Sicherheitsabfragen explizit vom Benutzer bestätigen lassen.

Die Programme sollten grundsätzlich in jedem Verzeichnis funktionsfähig sein, d.h. es dürfen keine festen Pfadangaben benutzt werden. Die intern verwendeten Dateien müssen im Anwendungsverzeichnis oder unterhalb dieses Verzeichnisses liegen. Sie können dann mittels APP.PATH relativ zum Anwendungsverzeichnis angesprochen werden.


Kommentierung

Alle Formular- und Quellmodule müssen mit einem Kommentarkopf, der die Leistung bzw. den Verwendungszweck des jeweiligen Moduls erläutert, beginnen.

Alle benutzerdefinierten Prozeduren müssen mit einem Kommentarkopf beginnen, in dem die Funktionalität der Prozedur, die einzelnen Parameter und ggf. das Prozedur-Ergebnis (bei Funktionen) ausreichend erläutert werden. Nach Möglichkeit sollte auch die Reaktion im Fehlerfalle beschrieben werden.

Ereignis-Prozeduren, müssen nur dann mit einem Kommentarkopf versehen werden, wenn der zugehörige Codeteil nicht trivial ist, da die Leistung der Prozedur in der Behandlung eines speziellen Ereignisses für ein spezielles Steuerelement besteht. Das Steuerelement und das Ereignis, wofür die Ereignis-Prozedur gültig ist, werden beide über den Namen der Ereignis-Prozedur identifiziert. Eine Erläuterung der Parameter ist i.a. nicht erforderlich, da diese in VISUAL BASIC element- und ereignisbezogen definiert und beschrieben sind. Da Ereignis-Prozeduren keinen Funktions-Charakter haben, erübrigt sich die Beschreibung der Funktionsrückgabe.

Innerhalb von Prozeduren sollten funktionale Einheiten und komplexe Algorithmen mit Kommentarzeilen eingeleitet werden.

Die Bedeutung bzw. der Inhalt von Variablen und Konstanten, sollte per Kommentar erläutert werden, wenn der Name keine ausreichenden Rückschlüsse hierauf zuläßt.

Bei der Deklaration externer Prozeduren sollten die Funktionalität der Prozedur und ggf. die Parameter sowie der Rückgabewert beschrieben werden.

Der Deklarationsteil des anwendungsspezifischen Quellmoduls oder des Startformulars sollte eine Änderungshistorie für die gesamte Anwendung enthalten. Diese sollte zu allen nachträglichen Änderungen folgende Informationen enthalten: lfd. Nr., Datum, Autor und Erläuterung der Änderung. Die von einer Änderung betroffenen Quellcode-Zeilen sollten per Kommentar mit der Änderungs-Nr. gekennzeichnet werden.

Die Kommentarverwendung sollte zumindest innerhalb einer Anwendung einheitlich sein.

Zur besseren Lesbarkeit der Prozeduren sollten (z.B. zwischen logischen Einheiten) Leerzeilen verwendet werden.


Namenskonventionen

Die Namen von Prozeduren, Variablen und Konstanten müssen stets mit einem Buchstaben beginnen. Danach dürfen sie Buchstaben, Ziffern und den Unterstrich enthalten. Die Länge ist auf 40 Stellen begrenzt. Groß- und Kleinbuchstaben werden nicht unterschieden. Umlaute sind nicht erlaubt.

Alle selbst definierten Namen sollten möglichst aussagefähig sein, d.h. der Name sollte unmittelbar Rückschlüsse auf die Leistung einer Prozedur bzw. den Inhalt einer Variablen oder Konstanten zulassen.

Verschiedene Namensbestandteile sollten generell durch gleichzeitige Nutzung der Groß- und Kleinschreibung, wobei ein Name bis auf die Anfänge der Namensbestandteile klein geschrieben wird oder durch Trennung mittels Unterstrich gekennzeichnet werden.

Beispiele:

(a) AltesErstellDatum
(b) altes_erstell_datum
(c) ALTES_ERSTELL_DATUM
(d) cmdErstellDatumAendern_Click.

Für die Namen von Variablen, Formularen, Steuerelementen und benutzerdefinierten Prozeduren sollte nach Möglichkeit die Schreibweise von Beispiel (a) verwendet werden. Für Formulare und Steuerelemente sind zusätzliche Präfixe zu verwenden (siehe unten). Die Namen von Ereignis-Prozeduren werden von VISUAL BASIC analog Beispiel (d) in der Form "elementname_ereignis" gebildet, wobei "elementname" den Namen eines Formulars bzw. eines Steuerelementes darstellt und "ereignis" das jeweilige Ereignis, wodurch die Prozedur angestoßen wird, kennzeichnet.

Es müssen stets die in VISUAL BASIC vordefinierten Konstanten vom Format vbBezeichner oder die in den eingesetzten Zusatz-Steuerelementen festgelegten Konstanten benutzt werden. Die Namen der selbst definierten Konstanten sollten sich ebenfalls formal von den Variablennamen unterscheiden und zwar entweder durch Verwendung der Schreibweise für die vordefinierten Konstanten (Beispiel (c)) oder durch Verwendung der Schreibweise aus Beispiel (a) mit der Präfix c (z.B. cMaxWert).

Die logische Zusammengehörigkeit von Daten und/oder Konstanten sollte durch die Verwendung gemeinsamer Namensbestandteile kenntlich gemacht werden.

Prozeduren sollten nach Möglichkeit in der Form "ObjektAktion" (z.B. BenutzerLoeschen, BenutzerAendern, ...) und nicht umgekehrt "benamt" werden (z.B. LoeschenBenutzer, AendernBenutzer, ...). Analog sollten Variablen- und Konstantennamen in der Form "ObjektAttribut" (z.B. cFarbeRot anstelle von cRoteFarbe) oder bei Funktionscodes in der Form "ObjektFunktion" (z.B. cFarbeAendern) gebildet werden.

Bei benutzerdefinierten Prozeduren sollten die Parameternamen mit der Präfix p beginnen.

Bei großen Anwendungen kann es nützlich sein, den Gültigkeitsbereich von Variablen und Konstanten durch eine geeignete Präfix (z.B. g für programm-globale und m für modul-globale Daten) im Namen zu verdeutlichen.

Die Namen der Formulare müssen mit der Präfix frm beginnen (z.B.: frmAnmeldung). In den Namen der zugehörigen Formular-Dateien sollte die Präfix frm weggelassen werden, da diese Dateien schon mit der Dateierweiterung ".FRM" als Formular gekennzeichnet sind. Die Basic- und Klassenmodule sollten mit der Präfixen bas und cls gekennzeichnet werden. Diese Präfixe sollten bei den zugehörigen Dateinamen ebenfalls wegen der Dateierweiterungen ".BAS" und ".CLS" weggelassen werden.

Für Steuerelemente, die im VISUAL BASIC-Code nicht angesprochen werden, sollten keine eigenen Namen vergeben werden; in diesem Fall sollten die Default-Namen von VISUAL BASIC belassen werden. Für alle angesprochenen Steuerelemente sind eigene, selbsterklärende Namen mit einer 3-stelligen Präfix (in Kleinbuchstaben), die den Typ des Steuerelement es kennzeichnet, zu verwenden (z.B.: cmdErstellDatumAendern für eine Befehls-Schaltfläche mit der Funktion "Ändern des Erstelldatums"). Für die einzelnen Steuerelement-Typen sollten folgende Präfixe benutzt werden:

cal Kalender (calendar)
cbo Kombinationslistenfeld (combo box, DB combo box)
chk Kontrollfeld (check box)
cmd Befehlsschaltfläche (command button)
crp Report-Steuerelement (crystal report)
dat Datensteuerelement (data control)
dir Verzeichnislistenfeld (directory list box)
dlg Gemeinsame Dialoge (common dialogs)
drv Laufwerklistenfeld (drive list box)
fil Dateilistenfeld (file list box)
fra Rahmen (frame)
grd Tabelle (grid, DB grid)
hsb Horizontale Bildlaufleiste (horizontal scroll bar)
img Bild-Anzeigebereich (image)
iml Bild-Liste (image list)
lbl Bezeichnungsfeld (label)
lin Linie (line)
lst Listenfeld (list box, DB list box)
lsv Listenansicht (list view)
mmc Steuerelement für Multimedia (multimedia control)
mnu Menü-Auswahl (menue)
opt Optionsfeld (option button)
ole OLE2-Element (OLE client 2.0)
pic Bildfeld (picture box)
pnl Anordnungsbereich (panel)
pgb Fortschrittsanzeigeleiste (progress bar)
rtf Textfeld für formatierte Darstellung (rich text format)
sld Schieberegler (slider)
shp Figur (shape)
stb Zustandsanzeigeleiste (status bar)
tab Register (tab strip, tab)
tlb Symbolleiste (tool bar)
tmr Zeitmesser (timer)
trv Strukturansicht (tree view)
txe Textfeld mit Edit-Maske (mask edit box)
txt Standard-Textfeld (text box)
vsb Vertikale Bildlaufleiste (vertical scroll bar).

Für die Steuerelemente, die nicht zum Standard-Umfang von VISUAL BASIC gehören, sollten analog einheitliche Präfixe verwendet werden.

Der Name der Projektdatei einer Anwendung sollte nach Möglichkeit mit dem Namen des Startformulars und dem zugehörigen Programmnamen (EXE-Datei) übereinstimmen, um die Zusammengehörigkeit zu verdeutlichen.


Programm-Struktur

Die Struktur von VISUAL BASIC-Anwendungen wird weitgehend durch die Benutzeroberfläche festgelegt. Jedem Formular entspricht ein eigener Formularmodul, der aus dem Layout des Formulars, den zum Formular und dessen Steuerelementen gehörenden Ereignis-Prozeduren sowie aus formularglobalen, benutzerdefinierten Prozeduren sowie den formularbezogenen Daten (Variablen und Konstanten) besteht. Formularübergreifende Daten und Prozeduren werden in sogenannten Quellmodulen (mit Dateierweiterung ".BAS") abgelegt.

Es empfiehlt sich, allgemein wiederverwendbare Prozeduren und Datendeklarationen von den anwendungsspezifischen Prozeduren und Deklarationen zu trennen und in eigenen Quellmodulen abzulegen.

Die Projektdatei einer VISUAL BASIC-Anwendung (Dateierweiterung ".VBP") umfaßt alle Formular-Module (".FRM") und Quellmodule (".BAS", ".CLS") sowie alle zusätzlich zum Standard-Umfang benötigten Steuerelement-Dateien (".OCX").

Benutzerdefinierte Prozeduren von Quellmodulen, die nur innerhalb des eigenen Moduls angesprochenen werden dürfen, sollten mit "private" definiert werden. Damit wird eine ungewollte Verwendung der Prozedur außerhalb des Quellmoduls verhindert.

Analog sollten Variablen und Konstanten in Quellmodulen nur dann mit "public" definiert werden, wenn sie programm-global sind und außerhalb des eigenen Quellmoduls angesprochen werden.

Die zu einer VISUAL BASIC-Anwendung gehörenden Komponenten (Projektdatei, Formular- und Quellmodule, ausführbares Programm (EXE-Datei)) sollten - soweit möglich - zusammen mit den von der Anwendung benutzten externen Datenbeständen in einem eigenen Directory abgelegt werden.

VISUAL BASIC-Anwendungen sind ereignisorientiert, d.h. der Ablauf des Programms wird im Gegensatz zu konventionellen Anwendungen nicht durch das Programm selbst, sondern durch den Benutzer durch Eingaben/Interaktionen (sogenannte Ereignisse) bestimmt. Herkömmliche Ablaufdiagramme besitzen somit auf Programm-/Anwendungsebene keine Aussagekraft; sie sind lediglich innerhalb komplexer Prozeduren relevant. Die Abhängigkeit der einzelnen Formulare / Module einer Anwendung (z.B. über Menüs usw.) sollte jedoch aus Übersichtsgründen in einem Diagramm dargestellt werden.


Datenbehandlung

Alle Anwendungen müssen mit der "environment option" "require variable declaration" bzw. mit der Anweisung "Option Eplicit"am Anfang des Deklarationsteils von Formular- und Quellmodulen erstellt werden. Damit wird sichergestellt, daß nur explizit definierte Variablen angesprochen werden. Die Verwendung der DEF type-Anweisungen zur impliziten Definition von Variablen über den Anfangsbuchstaben des Variablennamens ist verboten.

Datentypen dürfen nur über die AS-Klausel (z.B. "Dim Zahl As Integer") und nicht über das Typensymbol (z.B. "Zahl%") definiert werden. Das Typensymbol ist aus Platzgründen nur bei Parametern in externen Prozedur-Deklarationen erlaubt.

Der Datentyp "Variant" sollte nur in Ausnahmefällen bzw. wenn er von VISUAL BASIC vorgeschrieben ist, verwendet werden. Anstelle von "Variant" sollten die elementaren Datentypen benutzt werden. Analog sollten stets die $-Funktionen (z.B. LEFT$) anstelle der Nicht-$-Funktionen (z.B. LEFT) verwendet werden.

Variable Zeichenketten (z.B. "Dim Zv As String") sind Zeichenketten fester Länge (z.B. "Dim Zf As String * 8") vorzuziehen.

Die Konstanten sollten - sofern sie mehrfach benutzt werden oder einer Änderung unterliegen können - separat definiert und symbolisch angesprochen werden.

Alle Variablen werden von VISUAL BASIC typkonform initialisiert, bevor sie das erste Mal angesprochen werden. Zur Klarheit sollten sie jedoch möglichst explizit initialisiert werden.

Für der Konkatenation von Daten sollte der Operator & anstelle von + verwendet werden.


Codierung

Eine Zeile darf maximal eine VISUAL BASIC-Anweisung enthalten.

Codierzeilen sollten auf eine Länge von 80 und in Ausnahmefällen von 120 Stellen begrenzt werden.

Die Prozeduren sollten größenmäßig auf maximal 100 Zeilen (ca. 2 Seiten beim Ausdruck) begrenzt werden. Ggf. sind logische Code-Einheiten als separate, benutzerdefinierte Prozeduren auszulagern.

Parameter sollten in Prozeduren nach Möglichkeit per Wert (BYVAL) und nicht per Referenz übergeben werden. Dadurch wird verhindert, daß Daten der aufrufenden Prozedur von der aufgerufenen Prozedur versehentlich überschrieben werden.

Prozeduren, die als Sub (Unterroutine) definiert sind, sollten - um unmittelbar identifizierbar zu sein - stets mit CALL aufgerufen werden. Bei Sub's ohne Parameter können die Klammern entfallen. Funktions-Prozeduren dürfen nur in Ausdrücken verwendet werden und sind an den obligatorischen Parameterklammern zu erkennen.

Zeitaufwendige Prozeduren sollten ggf. die Steuerung mittels der DOEVENTS-Anweisung an Windows zwecks Behandlung der zwischenzeitlich in der eigenen Anwendung angefallenen Ereignisse abgeben.

Innerhalb von Prozeduren sind die Grundsätze der strukturieren Programmierung einzuhalten; d.h. die GOTO-Anweisung sollte äußerst restriktiv benutzt werden (allenfalls für einen Sprung auf das Ende bzw. die Endebehandlung einer Prozedur).

Die Schachtelungstiefe von Anweisungen sollte durch eine entsprechende Einrückung der Anweisungen optisch verdeutlicht werden.

Die einzeilige IF-Anweisung "IF Bedingung THEN Anweisung ..." ist nicht erlaubt. Es ist nur die mehrzeilige, durch END IF abgeschlossene IF-Anweisung zulässig.

Anstelle des Schleifen-Konstruktes "WHILE ... WEND" sollte das flexiblere Schleifen-Element "DO WHILE ... LOOP" verwendet werden. Letztere kann beispielsweise mit einer EXIT-Anweisung "korrekt" verlassen werden.

Die Schleifen-Konstrukte dürfen nur über die korrespondierenden EXIT-Anweisungen vorzeitig verlassen werden.

Falls in einer IF-Kaskade ("IF Bedingung THEN Anweisung1 ELSEIF Bedingung THEN Anweisung2 ....") stets die gleiche Bedingung abgefragt wird, sollte hierfür die übersichtlichere SELECT CASE-Anweisung benutzt werden.

Nach Möglichkeit sollten alle Prozeduren über eine eigene Fehlerbehandlung (ON ERROR ...) verfügen.

Bei Fehlern, die nicht explizit von der Anwendung behandelt werden, sollte u.a. stets die Fehler-Nr. (ERR.NUMBER) und der von VISUAL BASIC geliefert Fehlertext (ERROR.DESCRIPTION) ausgegeben werden.

Alle Fehlermeldungen sollten zumindest innerhalb einer Anwendung einen einheitlichen Aufbau besitzen.

Häufig angesprochene Steuerelement-Eigenschaften sollten aus Performance-Gründen in Variablen übertragen werden und dann über die Variablen angesprochen werden.

Datenbank-Operationen können durch eine transaktionsorientierte Verarbeitung (BEGINTRANS, COMMITTRANS, ROLLBACK) u.U. erheblich beschleunigt werden. Darüber hinaus ermöglicht die Transaktionsverarbeitung konsistente Aktualisierungen von mehreren Tabellen.

Aus Performance-Gründen sollte man in Datenbank-Abfragen den LIKE-Operator nur sehr restriktiv verwenden.

Bei Datenbanken ist Vorsicht mit den Werten EMPTY und NULL geboten; gegebenfalls sind Feldinhalte auf beide Werte abzufragen, um einen Leerwert zu erkennen.

Die Verifikation von Bedingungen ist in VISUAL BASIC nicht optimiert. Bei einer Bedingung vom Typ "Teilbedingung1 OR Teilbedingung2" wird beispielsweise die Teilbedingung2 auch dann geprüft, wenn die Teilbedingung1 bereits erfüllt ist. Deshalb sollte das Ergebnis der einzelnen Teilbedingungen einer Bedingung unabhängig von der Ausführung und/oder dem Ergebnis der anderen Teilbedingungen sein. Bedindungen der Art "EOF(datei) OR Satzart = Ende" sind zu vermeiden, da das Feld "Satzart" in der 2. Teilbedingung beim Vorliegen der 1. Teilbedingung ("EOF") nicht mehr definiert ist und die Bedingungsprüfung entweder zu einem Fehler oder zu einem unvorhersehbaren Resultat führt.

Abkürzungen

DDE - dynamischer Datenaustausch (Dynamic Data Exchange)
DLL - Programmbibliothek mit dynamisch aufrufbaren Routinen (Dynamic Link Library)
GDI - Schnittstelle für Grafikprogrammierung (Grafics Device Interface)
GUI - grafische Benutzeroberfläche (Grafical User Interface)
MDI - Multiple Document Interface
OCX - Steuerelementdatei (xxx) für VISUAL BASIC 4
ODBC - Open DataBase Connection
OLE - Verknüpfung und Einbettung von Objekten (Object Linking and Embedding)
VBX - Steuerelementdatei (Visual Basic eXtension) für VISUAL BASIC 3

Literatur (Auswahl)

[1] SNI, System Interfaces for Applications, Styleguide V1.0, Richtlinien zur Gestaltung von Benutzeroberflächen
[2] SNI-SINIX, OSF/Motif V1.1, Style Guide
[3] ISO-Norm 9241-Teil 10 bzw. DIN EN 9241-10
[4] Mastering Microsoft VISUAL BASIC 4.0 - Interaktives Tutorial, Microsoft Press
[5] VISUAL BASIC 4.0, Addison-Wesley
[6] VISUAL BASIC 5 - Language Reference (engl.), Microsoft Press
[7] VISUAL BASIC 5 - Programmer's Guide (engl.), Microsoft Press
[8] VISUAL BASIC 5 - Language Reference (engl.), Microsoft Press
[9] VISUAL BASIC 5.0, Addison-Wesley
[10] Das große Buch zu VISUAL BASIC 5, Data Becker
[11] VISUAL BASIC - Object-Oriented Programming (engl.), Coriolis Group Books

[1] enthält zusätzliche Literaturangaben zur Gestaltung benutzerfreundlicher und ergonomischer Benutzeroberflächen sowie Hinweise auf die derzeit verfügbaren DIN- und ISO-Normen zu diesem Themenkomplex.

Gustav Schwakenberg
FORUM für Informationstechnologie GmbH
Margaretenstr. 1, 53175 Bonn
Tel: (02 28) 377 894-81
Fax: (02 28) 377 894-67