Gedanken zu Visual Basic .NET

Einleitung

Dieser Artikel beschreibt Möglichkeiten, die Programmiersprache Visual Basic .NET zu verbessern. Dabei handelt es sich um die eigene Meinung des Autors, die sich durch langjährige Arbeit mit Visual Basic und anderen Programmiersprachen gebildet hat. Der Buchautor Bruce McKinney hatte in seinem Werk Hardcore Visual Basic bereits auf einige der Mängel von Visual Basic 6.0 und später in seinem Artikel Visual Basic.NET Revealed! auf jene von Visual Basic .NET hingewiesen. Die hier aufgezeigten Unzulänglichkeiten beziehen sich zum Teil nicht direkt auf Visual Basic .NET, sondern können auch in Bezug zu Visual Basic 6.0 stehen.

Der Schleifentyp `While`

Visual Basic stellt zwei Typen von Schleifen zur Verfügung, die eine variable Anzahl von Durchläufen ermöglichen, die Do-Schleife und die While-Schleife. Betrachtet man diese beiden Schleifen näher, wird man feststellen, daß die While-Schleife praktisch redundant ist. Der einzige Unterschied zur Do-Schleife besteht darin, daß dieser Schleifentyp keine Möglichkeit des Ausstiegs innerhalb der Anweisungsprozedur bietet. Dieser Schleifentyp wird durch das Schlüsselwort Wend (für „wenden“ im Sinne von „nach oben springen“) abgeschlossen. In Visual Basic .NET wurden While-Schleifen dahingehend verändert, daß sie mit End While anstatt mit Wend beendet werden. Außerdem kann nun auch die Schleife mit Exit While verlassen werden.

Diese Änderungen ist in verschiedener Hinsicht unglücklich: Bei der Aktualisierung von bestehendem Quellcode sind Änderungen erforderlich, da bestehender Code, in dem das Schlüsselwort Wend benutzt wird, nicht mehr kompilierbar ist. Dabei ist fragwürdig, ob die Änderung von Wend in End While, die mit einer Erhöhung der Konsistenz der Sprachkonstrukte begründet wurde, wirklich die Konsistenz in der Syntax der Programmiersprache verbessert. Schließlich wird kein einziger anderer Schleifentyp in Visual Basic mit einem End-Konstrukt abgeschlossen. End wird stattdessen vielmehr zum Abschluß deklarativer Blöcke wie etwa in End If, End With, End Sub und End Class benutzt und nicht zur direkten Steuerung des Programmflusses.

Viel schlimmer ist jedoch die Änderung der Semantik des While-Schleifentyps. Zeigte bisher eine While-Schleife an, daß es sich um einen Spezialfall der Schleifen handelte, bei dem die Bedingung im Kopf der Schleife angegeben wird und bei dem der Schleifenkörper nicht verlassen werden kann, ist in Visual Basic .NET der Schleifentyp vollkommen redundant. Es wäre sinnvoller gewesen, diesen Schleifentyp überhaupt aus der Syntax der Programmiersprache zu entfernen. Jede While-Schleife läßt sich nämlich problemlos und ohne Verlust an Intuitivität durch eine Do-Schleife ersetzten; eine Änderung, die auch nicht viel schlimmer ist als das Ändern von Wend in End While.

Mehrzeilige Codekommentare

In Visual Basic können Kommentare im Quellcode sowohl mittels des Zeichens ' oder der Anweisung Rem eingeleitet werden. Beide Möglichkeiten sind jedoch nur für einzeilige Kommentare geeignet. Mehrzeilige Kommentare können nur durch Voranstellen von ' oder Rem vor jede einzelne Zeile als solche ausgezeichnet werden. Bei der Anweisung Rem handelt es sich um ein Relikt aus alten BASIC-Versionen, in denen Anweisungen immer mit einem Operationscode eingeleitet wurden. Das Entfernen der Rem-Anweisung würde zwar bestehenden Code brechen, jedoch könnte ein Migrationswerkzeug automatisch alle Vorkommnisse dieser Anweisung durch ' ersetzen.

Da in Classic Visual Basic Kommentare als Anweisungen angesehen wurden, war das Abteilen einer Kommentaranweisung auf mehrere Zeilen mittels des Anweisungsfortsetzungszeichens _ möglich. Diese Möglichkeit besteht nicht mehr in Visual Basic .NET. Das Werkzeug zur Migration von Visual-Basic-6.0-Quellcode ist allerdings in der Lage, aufgeteilte Kommentare korrekt zu aktualisieren. Das folgende Listing zeigt einen Kommentar in Visual Basic 6.0, der mittels des Anweisungsfortsetzungszeichens _ der besseren Lesbarkeit wegen auf mehrere Zeilen aufgeteilt wurde:


' Das ist ein langer Kommentar, _
  der über mehrere Zeilen reicht, _
  aber nur ein Kommentarzeichen _
  verwendet.

Ein mehrzeiliger Kommentar unter Visual Basic 6.0 unter Verwendung des Anweisungsfortsetzungszeichens _.

Eine weitere kuriose Lösung zur Integration mehrzeiliger Kommentare stellt die Verwendung eines Blocks zur bedingten Kompilierung dar. Ist die Bedingung des #If-Blocks nicht erfüllt, ignoriert der Compiler den im Block eingeschlossenen Text. In Visual Basic 6.0 wird der Text rot gefärbt, die Entwicklungsumgebung Visual Studio 2005 wendet die Regeln zur Syntaxhervorhebung an. Diese Methode eignet sich zum schnellen Deaktivieren umfangreicher Codeblöcke. Nachstehendes Listing zeigt ein Beispiel, in dem Code mittels bedingter Kompilierung von der Kompilierung ausgenommen wird:

#If False Then
    Das ist ein Kommentar, der eigentlich ein fehlerhafter Code ist, der wegen
    der Bedingung 'False' nie ausgeführt wird und daher keinen Fehler auslöst.
#End If

Mehrzeilige „Kommentare“ mit bedingter Kompilierung.

Funktionsaufrufe bei der Initialisierung von Konstanten

Die Sprache Visual Basic enthält einige Funktionen, die bei gleicher Eingabe immer das gleiche Ergebnis zurückgeben. Beispiele dafür sind die Funktionen Chr$ und Sin. Ab und zu kommt es vor, daß man Konstanten benötigt, die Werte enthalten, die entweder überhaupt nicht in einem konstanten Ausdruck darstellbar sind oder deren Darstellung als konstanter Ausdruck nicht sinnvoll ist. Folgendes Beispiel zeigt unkompilierbaren Code, der die Verwendung von Funktionsaufrufen bei der Initialisierung von Konstanten demonstriert:

Private Const Number As Double = 1 + 3 * Sin(22)
Private Const ID As String = "usrid" & Chr$(15) & Chr$(254) & "acbf"

Funktionsaufrufe bei der Initialisierung von Konstanten.

Unter Visual Basic 6.0 lösen beide Konstantendefinitionen einen Fehler bei der Kompilierung aus, da Konstanten nur aus konstanten Ausdrücken bestehen dürfen. In Visual Basic .NET ist zumindest die zweite der beiden gezeigten Konstantendefinitionen kompilierbar. Wie leicht erkennbar ist, handelt es sich bei beiden Initialisierungsausdrücken um konstante Ausdrücke, deren Wert unabhängig davon ist, wo das Programm ausgeführt wird. Deshalb wäre es sinnvoll, die Verwendung von Basisfunktionen, die einen konstanten Wert bei gleicher Eingabe zurückgeben, bei der Initialisierung von Konstanten zuzulassen.

Formatierung von Anweisungstrennzeichen

Eines der besten Merkmale von Visual Basic war und ist die automatische Formatierung des Quellcode. Dabei werden beispielsweise Leerzeichen zwischen Operatoren eingefügt. Die Codezeile a=b+12 würde der als a = b + 12 formatiert werden. Auch das Trennen von Anweisungen mittels des Operators : wird automatisch formatiert, unter Visual Basic 6.0 wurden Anweisungen und Trennzeichen in das Format ‹Anweisung›: ‹Anweisung› gebracht, wobei nach dem Doppelpunkt beliebig viele Leerzeichen eingesetzt werden konnten, Visual Studio .NET 2002 und 2003 hingegen formatieren sie als ‹Anweisung› : ‹Anweisung›. Zwar läßt sich die intelligente Formatierung des Quellcodes deaktivieren, jedoch werden dann überhaupt keine Formatierungen mehr automatisch vorgenommen.

Eine allgemeine Regel besagt, daß man mit der Verwendung des Befehlstrennzeichens : sparsam umgehen sollte. Trotzdem erweist sich das Zusammenziehen mehrerer Anweisungen in eine Zeile in einigen Situationen als nützlich. So wird etwa bei Select Case-Anweisungen in den Case-Blöcken oft der Doppelpunkt verwendet, um den Code eines Zweiges in einer Zeile unterzubringen. Beim unten angeführten Code handelt es sich um einen Ausschnitt aus einem in Visual Basic 6.0 entwickelten Code:

Select Case UserName
    Case "Bill":    t = "Hello Bill"
    Case "Michael": t = "Good Morning, Michael"
End Select

Formatierung des Anweisungstrennzeichens in Visual Basic 6.0.

In Visual Studio .NET würde der Code anders formatiert werden, wie das nächste Codebeispiel zeigt:

Select Case UserName
    Case "Bill" : t = "Hello Bill"
    Case "Michael" : t = "Good Morning, Michael"
End Select

Formatierung des Anweisungstrennzeichens in Visual Basic .NET.

Durch dieses Funktionsmerkmal der Entwicklungsumgebung kann Code nicht mehr so übersichtlich formatiert werden, wie dies unter Visual Basic 6.0 möglich war. Es bleibt zu hoffen, daß in einer zukünftigen Version der Entwicklungsumgebung die Formatierung des Quellcodes feiner konfigurierbar sein wird.

`Caption` versus `Text`

In den Windows Forms von .NET wurden die Caption-Eigenschaften von Steuerelementen und Formularen in Text-Eigenschaften umbenannt. Als Begründung dafür wurde angegeben, daß auf dem Steuerelement sichtbarer Text durch die Text-Eigenschaft angegeben werden soll. Sicherlich haben sich die Entwickler, die damals Caption und Text als Bezeichnungen der Eigenschaften gewählt haben, etwas dabei gedacht. Die Unterscheidung zwischen Caption und Text sollte zeigen, daß Caption statische Beschriftungen, Text dagegen durch den Benutzer änderbaren Text angibt. Dies ist sinnvoll, um die Funktion von Steuerelementen leichter unterscheiden zu können.