Programmierkonventionen für Visual Basic
Bei diesem Dokument handelt es sich um eine stark überarbeitete und erweiterte Version der entsprechenden Kapitel in der MSDN-Dokumentation zu Visual Basic.
Einleitung
Warum Programmierkonventionen?
Der Hauptgrund für die Anwendung von einheitlichen Programmierkonventionen liegt in der Standardisierung der Struktur und des Programmierstils einer Anwendung, so daß der Code für den Programmierer selbst und andere leicht lesbar und verständlich ist. Gute Programmierkonventionen ermöglichen das Schreiben von präzisem, lesbarem und eindeutigem Quellcode, der konsistent mit anderen Sprachkonventionen und so intuitiv wie möglich ist.
Minimale Programmierkonventionen
In einem allgemeinen Satz von Programmierkonventionen sollten die minimalen Anforderungen definiert sein, die zur Erreichung der oben genannten Zielsetzungen notwendig sind, dem Programmierer aber bei der Programmlogik und funktionellen Abläufen freie Hand lassen. Ziel ist es, das Programm leicht lesbar und verständlich zu machen, ohne die Kreativität des Programmierers durch zu viele Richtlinien und Restriktionen zu hemmen. Aus diesem Grund sind die in diesem Text beschriebenen Konventionen kurz und als Empfehlungen gedacht.
Benennungsvereinbarungen für Objekte
Objekte sollten mit einem einheitlichen Präfix benannt werden, damit der Objekttyp leicht erkennbar ist. Empfohlene Konventionen für einige der von Visual Basic unterstützten Objekte sind im Folgenden aufgeführt.
Empfohlene Präfixe für Steuerelemente
Bei einigen Steuerelementen haben sich auch mehrere verschiedene Präfixe nebeneinander durchgesetzt. Die Reihenfolge von links nach rechts deutet die Häufigkeit der Verwendung an. Die Übersicht enthält auch Präfixe für Steuerelemente, die in aktuellen Versionen von Visual Basic nicht mehr mitgeliefert werden. Diese Präfixe sollten beim Leser etwas Gefühl für eine sinnvolle Wahl eines Präfix zu einem bestimmten Steuerelementnamen wecken:
Steuerelementtyp | Präfix | Beispiel |
---|---|---|
3D-Grundfläche (SSPanel) | pnl |
pnlGroup |
Abbildungsliste (ImageList) | ils |
ilsAllIcons |
Animierte Schaltfläche (AniPushButton) | ani |
aniMailBox |
Anzeige (Image) | img |
imgIcon |
AufAb (UpDown) | upd |
updDirection |
Befehlsschaltfläche (CommandButton) | cmd , btn |
cmdExit |
Bericht | rpt |
rptQtr1Earnings |
Bezeichnungsfeld (Label) | lbl |
lblHelpMessage |
Bild (Picture) | pic |
picVGA |
Bildausschnitt (PictureClip) | clp |
clpToolbar |
Dateilistenfeld (FileListBox) | fil |
filSource |
Datengebundene Tabelle (DBGrid) | dbgrd |
dbgrdQueryResult |
Datengebundenes Kombinationsfeld (DBCombo) | dbcbo |
dbcboLanguage |
Datengebundenes Listenfeld (DBList) | dblst |
dblstJobType |
Daten-Steuerelement (Data) | dat |
datBiblio |
Diagramm (Graph) | gra |
graRevenue |
Drehfeld (SpinButton) | spn |
spnPages |
Figur (Shape) | shp |
shpCircle |
Formular | frm |
frmEntry |
Fortschrittsleiste (ProgressBar) | prg |
prgLoadFile |
Gliederung (Outline) | out |
outOrgChart |
Horizontale Bildlaufleiste (HScrollBar) | hsb |
hsbVolume |
Kombinationsfeld, Dropdown-Listenfeld (ComboBox) | cbo |
cboEnglish |
Kommunikation (MSComm) | com |
comFax |
Kontrollkästchen (CheckBox) | chk |
chkReadOnly |
Laufwerklistenfeld (DriveListBox) | drv |
drvTarget |
Linie (Line) | lin |
linVertical |
Listenansicht (ListView) | lvw , lv |
lvwHeadings |
Listenfeld (ListBox) | lst |
lstPolicyCodes |
MAPI-Nachricht (MAPIMessages) | mpm |
mpmSentMessage |
MAPI-Sitzung (MAPISession) | mps |
mpsSession |
MCI | mci |
mciVideo |
Menü | mnu |
mnuOpen |
Messgerät (Gauge) | gau |
gauStatus |
MS Flex-Tabelle (MSFlexGrid) | msg |
msgClients |
MS-Register | mst |
mstFirst |
OLE | ole |
oleWorksheet |
Rahmen (Frame) | fra |
fraLanguage |
Register (TabStrip) | tab |
tabOptions |
RTF (RichTextBox) | rtf |
rtfReport |
Schieberegler (Slider) | sld |
sldScale |
Standard-Dialogfeld (CommonDialog) | dlg |
dlgFileOpen |
Statusleiste (StatusBar) | sta , sb |
staDateTime |
Steuerelement (control; wird in Prozeduren verwendet, wenn der genaue Typ unbekannt ist) | ctr (bzw. ctl ) |
ctrCurrent |
Stift-BEdit | bed |
bedFirstName |
Stift-HEdit | hed |
hedSignature |
Stift-Ink | ink |
inkMap |
Strukturansicht (TreeView) | tre , tvw , tv |
treOrganization |
Symbolleiste (ToolBar) | tlb , tb , tbr |
tlbActions |
Tabelle (Grid) | grd |
grdPrices |
Tastenstatus (MHState) | key |
keyCaps |
Textfeld (TextBox) | txt |
txtLastName |
Untergeordnetes MDI-Formular | mdi |
mdiNote |
Vertikale Bildlaufleiste (VScrollBar) | vsb |
vsbRate |
Verzeichnislistenfeld (DirListBox) | dir |
dirSource |
Zeitgeber (Timer) | tmr |
tmrAlarm |
Empfohlene Präfixe für Datenzugriffsobjekte (DAO)
Die nachfolgende Liste zeigt Präfixe, die für die Benennung von Datenzugriffsobjekten geeignet sind:
Datenzugriffsobjekt | Präfix | Beispiel |
---|---|---|
Container | con |
conReports |
Database | db |
dbAccounts |
DBEngine | dbe |
dbeJet |
Document | doc |
docSalesReport |
Field | fld |
fldAddress |
Group | grp |
grpFinance |
Index | idx |
idxAge |
Parameter | prm |
prmJobCode |
QueryDef | qry |
qrySalesByRegion |
Recordset | rec |
recForecast |
Relation | rel |
relEmployeeDept |
TableDef | tbd |
tbdCustomers |
User | usr |
usrNew |
Workspace | wsp |
wspMine |
Im nächsten Listing ist ein Beispielcode zu sehen, der sich an die Benennungsempfehlungen aus den obenstehenden Tabellen anhält:
Empfohlene Präfixe für Menüs
In Anwendungen sind häufig viele Menü-Steuerelemente enthalten, sodaß es sinnvoll ist, sich für diese Art von Steuerelementen an einheitliche Benennungsvereinbarungen zu halten. Präfixe für Menü-Steuerelemente sollten nach dem Präfix mnu
ein zusätzliches Präfix für jede Verschachtelungsebene erhalten, wobei die Beschriftung für das letzte Menü am Ende der Zeichenfolge stehen sollte. In der folgenden Tabelle sind einige Beispiele aufgeführt.
Menübefehlssequenz | Menüzugriffsname |
---|---|
File → Open… | mnuFileOpen |
File → Send e-mail… | mnuFileSendMail |
File → Send Fax… | mnuFileSendFax |
Format → Char… | mnuFormatChar |
Help → Contents… | mnuHelpContents |
Wenn diese Benennungsvereinbarung angewendet wird, werden alle zu einer bestimmten Menügruppe gehörenden Menü-Steuerelemente im Eigenschaftenfenster von Visual Basic nebeneinander angezeigt. Außerdem lassen sich die Menüs, denen die Menü-Steuerelemente zugeordnet sind, daran gut erkennen.
Definieren von Präfixen für andere Steuerelemente
Für Steuerelemente, die oben nicht aufgeführt wurden, sollten Sie als einheitliche Lösung ein eindeutiges, aus zwei oder drei Zeichen bestehendes Präfix festlegen. Verwenden Sie nur mehr als drei Zeichen, wenn es zur Vermeidung von Unklarheiten nötig ist. Sie können beispielsweise für abgeleitete oder modifizierte Steuerelemente die oben genannten Präfixe so erweitern, daß klar wird, welches Steuerelement tatsächlich verwendet wird. Für Steuerelemente von Drittanbietern könnten Sie eine kleingeschriebene Abkürzung für den Anbieter zum Präfix hinzufügen. Für ein Steuerelement, das aus dem 3D-Rahmen-Steuerelement aus Visual Basic Professional erstellt wurde, könnten Sie z. B. den Präfix fra3d
verwenden, um es eindeutig zu kennzeichnen.
Benennungsvereinbarungen für Konstanten und Variablen
Neben den Objekten erfordern auch Konstanten und Variablen gut durchdachte Benennungsvereinbarungen. In diesem Abschnitt werden Konventionen für Konstanten und Variablen aufgeführt, die von Visual Basic unterstützt werden. Des Weiteren finden Sie Informationen zur Identifizierung des Datentyps und des Gültigkeitsbereichs von Konstanten und Variablen.
Variablen sollten immer mit dem kleinstmöglichen Gültigkeitsbereich definiert werden. Bei Verwendung von globalen (Public
-)Variablen können äußerst komplexe Strukturen entstehen, die die Logik einer Anwendung sehr schwer verständlich machen. Zudem erschweren globale Variablen die Wiederverwendung und Wartung des Codes beträchtlich. Variablen in Visual Basic können den folgenden Gültigkeitsbereich haben:
Gültigkeitsbereich | Deklaration | Sichtbarkeit |
---|---|---|
Prozedurebene | Private in Prozedur, Sub - oder Function -Prozeduren. |
In der Prozedur, in der sie deklariert ist. |
Modulebene | Private im Deklarationsabschnitt eines Formular- oder Codemoduls (FRM- oder BAS-Datei). |
In jeder Prozedur im Formular- oder Code-Modul. |
Global | Public im Deklarationsabschnitt eines Codemoduls (BAS-Datei). |
Überall in der Anwendung. |
In einer Visual-Basic-Anwendung sollten globale Variablen nur verwendet werden, wenn es keine andere Möglichkeit gibt, auf Daten aus mehreren Formularen zuzugreifen. Wenn es unumgänglich ist, globale Variablen einzusetzen, ist es sinnvoll, alle in einem einzigen Modul zu deklarieren, nach der Funktion gruppiert. Geben Sie dem Modul einen kategorisierenden Namen, wie z. B. modPublic.bas
.
Sie sollten nach Möglichkeit modularen Code verwenden. Wenn in Ihrer Anwendung z. B. ein Dialogfeld angezeigt wird, sollten Sie alle Steuerelemente und den Code für die Ausführung der Dialogfeldfunktionen in einem Formular definieren. Auf diese Weise erleichtern Sie sich die Organisation des Codes der Anwendung durch praktische Komponenten, und der Verwaltungsaufwand zur Laufzeit wird minimiert.
Mit Ausnahme von globalen Variablen – sie sollten nicht übergeben werden – sollten Prozeduren und Funktionen nur mit Objekten arbeiten, die an sie übergeben wurden. Globale Variablen, die in Prozeduren verwendet werden, sollten im Deklarationsabschnitt am Anfang der Prozedur beschrieben werden. Außerdem sollten Sie Argumente unter Verwendung von ByVal
an Sub
- und Function
-Prozeduren übergeben, es sei denn, Sie müssen den Wert des übergebenen Arguments explizit ändern.
Präfixe für den Gültigkeitsbereich von Variablen
Bei zunehmender Größe des Projekts wird es umso wichtiger, den Gültigkeitsbereich von Variablen schnell erkennen zu können. Dies können Sie erreichen, indem Sie dem Typpräfix einen entsprechenden, aus einem Buchstaben bestehenden Präfix voranstellen. Dadurch wird der Variablenname nur unwesentlich länger. Die folgende Tabelle gibt eine Übersicht über mögliche Präfixe:
Gültigkeitsbereich | Präfix | Beispiel |
---|---|---|
Global | g |
gstrUserName bzw. g_strUserName |
Modulebene | m |
mblnZwischenergebnis bzw. m_blnZwischenergebnis |
Lokal in Prozedur | (keiner) | dblBeschleunigung |
Eine Variable hat einen globalen Gültigkeitsbereich, wenn sie in einem Standardmodul oder Formularmodul mit dem Schlüsselwort Public
als öffentlich deklariert wird. Eine Variable hat den Gültigkeitsbereich Modulebene, wenn sie in einem Standardmodul oder Formularmodul mit dem Schlüsselwort Private
als privat deklariert wird.
Konsistenz ist bei Verwendung dieser Technik sehr wichtig. Bei der Syntaxüberprüfung in Visual Basic werden Variablen auf Modulebene, die mit einem p
beginnen, nicht gefunden.
Konstanten
Die Namen von Konstanten sollten Groß- und Kleinschreibung enthalten, wobei jedes Wort mit einem Großbuchstaben beginnen sollte. Obwohl die Namen von Visual-Basic-Standardkonstanten nicht den Datentyp und Gültigkeitsbereichsinformationen beinhalten, können Präfixe wie i
, s
, g
und m
das Verständnis des Wertes und Gültigkeitsbereichs einer Konstante beträchtlich erleichtern. Befolgen Sie bei Konstantennamen die gleichen Regeln wie bei Variablennamen, z. B.:
Variablen
Wenn Sie alle Variablen deklarieren, können Sie Programmierzeit sparen, da Sie die durch Tippfehler verursachten Programmfehler vermindern (z. B. durch die Eingabe von aUserNameTmp
, sUserNameTmp
und sUserNameTemp
). Aktivieren Sie in der Registerkarte Editor des Dialogfelds Optionen das Kontrollkästchen Variablendeklaration erforderlich. Die Anweisung Option Explicit
hat zur Folge, daß alle Variablen in Ihrem Visual-Basic-Programm deklariert werden müssen. Variablen sollten einen Präfix erhalten, der auf ihren Datentyp hinweist. Besonders bei großen Programmen kann der Präfix auch erweitert werden, um den Gültigkeitsbereich der Variable anzugeben.
Datentypen von Variablen
Verwenden Sie die folgenden Präfixe, um den Datentyp einer Variablen anzugeben:
Datentyp | Präfix | Beispiel |
---|---|---|
Boolean |
bln |
blnFound |
Byte |
byt |
bytBitmapData |
Collection |
col |
colWidgets |
Currency |
cur |
curCost |
Date (Datums- und Zeitangabe) |
dtm |
dtmStart |
Double |
dbl |
dblTolerance |
Error |
err |
errItemNotFound |
Integer |
int |
intCount |
Long |
lng |
lngDistance |
Object |
obj |
objActive |
Single |
sng |
sngDifference |
String |
str |
strFileName |
Benutzerdefinierter Typ (UDT) | udt |
udtCustomer |
Variant |
vnt |
vntCheckSum |
In einer anderen Konvention sehen die Präfixe wie folgt aus:
Datentyp | Präfix | Beispiel |
---|---|---|
Feldvariable (Array) | a |
aRecordsets |
Boolean |
b |
bWorking |
Byte |
byt |
bytData |
Klasse | C |
CMessageHook |
Currency |
cur |
curPrice |
Double |
d |
dPi |
Datum und Zeit | dte |
dteBirthday |
Fehler | er |
erCode |
Single |
f |
fSinglePrecision |
Bezugsnummer (handle) | h |
hFont |
Fensterbezugsnummer (window handle) | hwnd |
hwndParent |
Long |
l |
lSeconds |
Integer |
n |
nDays |
Zählervariable (Integer oder Long ) |
n |
nCount |
Objekt (Instanz einer unbekannten Klasse) | o |
oMyObject |
Zeichenkette (String ) |
s |
sUserName |
Struktur (UDT, type name) | t |
tCustomerInfo |
Enumeration | e |
eBorderStyles |
Vorzeichenlose Ganzzahl (unsigned integer/long) | u |
uCount |
Variant |
v |
vAny |
Man kann sich diese Konventionen noch mehr den eigenen Bedürfnissen anpassen. So wäre es z. B. sinnvoll, anstelle des c
bzw. o
als Präfix für Klasseninstanzen eine Abkürzung des Klassennamens zu verwenden, also eine Instanz der Klasse CCustomer
würde dann beispielsweise custFemale
benannt werden.
Beschreibende Namen für Variablen und Prozeduren
Variablen- oder Prozedurennamen sollten Groß- und Kleinschreibung enthalten, und sie sollten so lang wie nötig sein, um den Zweck der Variablen oder Routinen zu beschreiben. Außerdem sollten Funktionsnamen mit einem Verb beginnen, wie z. B. InitializeUpdate
oder CloseDialog
. Für häufig verwendete oder lange Namen sind Standardabkürzungen zu empfehlen, um die Länge der Namen in Grenzen zu halten. Im Allgemeinen sind Variablennamen, die mehr als 32 Zeichen umfassen, auf VGA-Bildschirmen schwierig zu lesen.
Wenn Sie Abkürzungen verwenden, sollten Sie in der ganzen Anwendung auf Konsistenz achten. Wenn Sie z. B. innerhalb eines Projekts zwischen Cnt
und Count
hin- und herwechseln, schaffen Sie unnötige Verwirrung.
Benutzerdefinierte Datentypen
In einem großen Projekt mit vielen benutzerdefinierten Datentypen ist es oft hilfreich, jedem benutzerdefinierten Datentyp einen spezifischen, aus drei Zeichen bestehenden Präfix zuzuweisen. Wenn diese Präfixe mit u
(für user-defined) beginnen, sind sie immer noch leicht zu erkennen, wenn Sie mit einem benutzerdefinierten Datentyp arbeiten. ucli
könnte z. B. als Präfix für Variablen eines benutzerdefinierten Clienttyps verwendet werden.
Konventionen für strukturiertes Programmieren
Neben den Benennungsvereinbarungen können Konventionen für strukturiertes Programmieren, wie z. B. Codekommentare und einheitliche Einzüge, die Lesbarkeit des Codes beträchtlich verbessern.
Konventionen für Codekommentare
Alle Prozeduren und Funktionen sollten mit einem kurzen Kommentar beginnen, der die funktionellen Merkmale der Prozedur (das, was sie tut) beschreibt. Diese Beschreibung sollte nicht auf die Einzelheiten der Implementierung eingehen (wie sie es tut), da sich diese mit der Zeit häufig ändern, was unnötige Kommentar-Verwaltungsarbeiten erfordert oder, schlimmer noch, in fehlerhaften Kommentaren resultieren kann. Die Implementierung wird durch den Code selbst und etwaige notwendige Kommentare zu einzelnen Code-Zeilen beschrieben.
An eine Prozedur übergebene Argumente sollten beschrieben werden, wenn ihre Funktionen nicht offensichtlich sind und wenn die Prozedur erfordert, daß die Argumente in einem bestimmten Bereich liegen. Rückgabewerte von Funktionen und globale Variablen, die von der Prozedur geändert werden (besonders durch Argumente, die als Referenz übergeben werden), müssen auch zu Beginn jeder Prozedur beschrieben werden.
Kommentarblöcke in den Kopfzeilen von Prozeduren sollten die folgenden Abschnittsüberschriften enthalten:
- Zweck:
Was die Prozedur tut (nicht, wie sie es tut).
- Annahmen:
Liste mit allen externen Variablen, Steuerelementen, geöffneten Dateien oder anderen Elementen, die nicht offensichtlich sind.
- Auswirkungen:
Liste mit allen beeinflußten externen Variablen, Steuerelementen oder Dateien und den Auswirkungen darauf (nur, wenn sie nicht offensichtlich sind).
- Eingaben:
Alle Argumente, die unter Umständen nicht offensichtlich sind. Argumente stehen in einer separaten Zeile mit Kommentaren innerhalb der Zeile.
- Rückgabewerte:
Erklärung der von den Funktionen zurückgegebenen Werte.
Die folgenden Punkte sollten auch dringend beachtet werden:
Jede wichtige Variablendeklaration sollte einen Kommentar innerhalb der Zeile beinhalten, der die Verwendung der deklarierten Variable beschreibt.
Variablen, Steuerelemente und Prozeduren sollten unmißverständlich benannt werden, damit Kommentare innerhalb der Zeile nur für Details komplexer Implementierungen erforderlich sind.
Zu Beginn eines BAS-Moduls, das die allgemeinen Visual-Basic-Konstantendeklarationen enthält, sollten Sie einen Kommentar mit einem Überblick über die Funktionen der Anwendung einfügen, in dem Sie primäre Datenobjekte, Prozeduren, Algorithmen, Dialogfelder, Datenbanken und Systemabhängigkeiten auflisten. Manchmal können einige Zeilen Pseudocode, die den Algorithmus veranschaulichen, zum Verständnis des Programmcodes beitragen.
Formatieren des Codes
Da viele Programmierer immer noch VGA-Bildschirme verwenden, sollten Sie beim Formatieren des Codes möglichst platzsparend arbeiten, wobei die logische Struktur und Verschachtelung des Codes trotzdem klar erkennbar sein sollte.
Hierzu folgende Hinweise:
Verschachtelte Standardblöcke, die mit Tabulatoren formatiert sind, sollten um vier Leerschritte eingerückt werden (Voreinstellung).
-
Der Kommentar, der einen Überblick über die Funktionen einer Prozedur vermittelt, sollte um einen Leerschritt eingerückt werden. Die Anweisungen auf höchster Ebene, die auf den Kommentar mit dem Überblick über die Funktionen folgen, sollten um einen Tabulatorschritt eingerückt werden und alle verschachtelten Blöcke um einen weiteren Tabulatorschritt:
Gruppieren von Konstanten
Variablen und definierte Konstanten sollten nach ihren Funktionen gruppiert und nicht in separate Bereiche oder spezielle Dateien aufgeteilt werden. Allgemeine Visual-Basic-Konstanten sollten in einem einzigen Modul gruppiert werden, um sie von anwendungsbezogenen Deklarationen abzugrenzen.
Die Operatoren &
und +
Verwenden Sie immer den &
-Operator, wenn Sie Zeichenfolgen verknüpfen, und den +
-Operator, wenn Sie mit numerischen Werten arbeiten. Bei Verwendung des +
-Operators zum Verketten von Zeichenfolgen kann es zu Problemen kommen, wenn Sie mit zwei Werten vom Typ Variant
arbeiten:
Zeichenfolgen für MsgBox
, InputBox
und SQL-Abfragen
Verwenden Sie zum Schreiben einer langen Zeichenfolge den Unterstrich als Zeilenfortsetzungszeichen, um die Zeichenfolge leicht lesen oder korrigieren zu können. Diese Technik ist besonders hilfreich für Meldungsfelder (MsgBox
), Eingabefelder (InputBox
) oder SQL-Abfragen:
Schlußwort
Natürlich kann kein Programmierer gezwungen werden, Konventionen bei der Benennung von Objekten oder der Strukturierung von Quellcode einzuhalten. Viele Unternehmen, in denen Software hergestellt wird, schreiben ihren Programmierern jedoch vor, wie der Code, der geschrieben wird, aussehen soll. Einige Programmierer meinen, daß solche Regeln ihrer Produktivität oder Kreativität im Wege stehen. Diese Personen sind allerdings nicht dafür geeignet, in einem Team von Programmierern gemeinsam an einer Lösung zu arbeiten.
Im Internet findet man tausende von Codebeispielen zu Visual Basic, die mehr oder weniger schön formatiert sind und bei denen der Entwickler mehr oder weniger eine Konvention befolgt hat. Generell kann man jedoch sagen, daß die guten Beispiele alle von Programmierern stammen, die sauberen Code schreiben und sich selbst Konventionen auferlegen. Auch wenn für viele Programmieren zum täglichen Geschäft gehört, sollte man nicht vergessen, daß es eine Kunst ist, guten Code zu schreiben.
Weiterführende Informationen
- INFO: Microsoft Consulting Services Naming Conventions for Visual Basic
In diesem Artikel werden die von den Microsoft Consulting Services verwendeten Benennungskonventionen für Visual Basic beschrieben.
- INFO: Object Hungarian Notation Naming Conventions for VB
Übersicht über Präfixe zur Benennung von Steuerelementen.