Einführung in Visual Basic

Die Programmiersprache Microsoft® Visual Basic® ist eine allgemeine Programmiersprache für Microsoft .NET Framework. Obwohl es darauf ausgelegt ist, eine benutzerfreundliche und leicht zu erlernende Sprache zu sein, ist es auch leistungsfähig genug, um die Bedürfnisse erfahrener Programmierer zu erfüllen. Die Programmiersprache Visual Basic weist eine Syntax auf, die Englisch ähnelt und die Klarheit und Lesbarkeit von Visual Basic-Code fördert. Wo immer möglich, werden aussagekräftige Wörter oder Ausdrücke anstelle von Abkürzungen, Akronyme oder Sonderzeichen verwendet. Zusätzliche oder nicht benötigte Syntax ist im Allgemeinen zulässig, aber nicht erforderlich.

Die Programmiersprache Visual Basic kann entweder eine stark typierte oder eine lose typierte Sprache sein. Lose Typisierung verzögert einen Großteil der Typüberprüfung, bis ein Programm bereits ausgeführt wird. Dies umfasst nicht nur die Typüberprüfung von Konvertierungen, sondern auch Methodenaufrufe, was bedeutet, dass die Bindung eines Methodenaufrufs bis zur Laufzeit zurückgestellt werden kann. Dies ist hilfreich beim Erstellen von Prototypen oder anderen Programmen, bei denen die Geschwindigkeit der Entwicklung wichtiger ist als die Ausführungsgeschwindigkeit. Die Visual Basic-Programmiersprache bietet auch stark typografische Semantik, die zur Kompilierungszeit alle Typüberprüfungen durchführt und die Laufzeitbindung von Methodenaufrufen nicht zulässig macht. Dies garantiert eine maximale Leistung und trägt dazu bei, dass Typkonvertierungen korrekt sind. Dies ist hilfreich beim Erstellen von Produktionsanwendungen, bei denen die Ausführungs- und Ausführungskorrektur wichtig ist.

In diesem Dokument wird die Visual Basic-Sprache beschrieben. Es ist eine vollständige Sprachbeschreibung anstelle eines Sprachlernprogramms oder eines Benutzerreferenzhandbuchs.

Grammatiknotation

Diese Spezifikation beschreibt zwei Grammatiken: eine lexikalische Grammatik und eine syntaktische Grammatik. Die lexikalische Grammatik definiert, wie Zeichen kombiniert werden können, um Token zu bilden; Die syntaktische Grammatik definiert, wie die Token kombiniert werden können, um Visual Basic-Programme zu bilden. Es gibt auch mehrere sekundäre Grammatiken, die für Vorverarbeitungsvorgänge wie die bedingte Kompilierung verwendet werden.

Die Grammatiken in dieser Spezifikation werden im ANTLR-Format geschrieben - siehe http://www.antlr.org/.

Die Groß-/Kleinschreibung ist in Visual Basic-Programmen nicht wichtig. Der Einfachheit halber werden alle Terminals in der Standard-Groß-/Kleinschreibung angegeben, aber jede Groß-/Kleinschreibung entspricht ihnen. Terminals, die druckbare Elemente des ASCII-Zeichensatzes sind, werden durch ihre entsprechenden ASCII-Zeichen dargestellt. Visual Basic ist auch beim Abgleichen von Terminals breite unempfindlich, sodass Unicode-Zeichen mit voller Breite ihren Unicode-Entsprechungen halber Breite entsprechen, jedoch nur auf basis eines ganzen Tokens. Ein Token wird nicht übereinstimmen, wenn es gemischte Zeichen mit halber Breite und Zeichen voller Breite enthält.

Zeilenumbrüche und Einzug können zur Lesbarkeit hinzugefügt werden und sind nicht Teil der Produktion.

Kompatibilität

Ein wichtiges Feature einer Programmiersprache ist die Kompatibilität zwischen verschiedenen Versionen der Sprache. Wenn eine neuere Version einer Sprache nicht denselben Code wie eine frühere Version der Sprache akzeptiert oder anders interpretiert als die vorherige Version, kann eine Belastung für einen Programmierer beim Upgrade seines Codes von einer Version der Sprache auf eine andere gelegt werden. Daher müssen die Kompatibilität zwischen Versionen beibehalten werden, es sei denn, der Vorteil der Sprachkonsumenten ist eindeutig und überwältigend.

Die folgende Richtlinie steuert Änderungen an der Visual Basic-Sprache zwischen Versionen. Die Begriffssprache bezieht sich bei Verwendung in diesem Kontext nur auf die syntaktischen und semantischen Aspekte der Visual Basic-Sprache selbst und enthält keine .NET Framework-Klassen, die als Teil des Microsoft.VisualBasic Namespaces (und Unternamespaces) enthalten sind. Alle Klassen im .NET Framework werden von einer separaten Versionsverwaltungs- und Kompatibilitätsrichtlinie außerhalb des Gültigkeitsbereichs dieses Dokuments abgedeckt.

Arten von Kompatibilitätsunterbrechungen

In einer idealen Welt wäre kompatibilität 100% zwischen der vorhandenen Version von Visual Basic und allen zukünftigen Versionen von Visual Basic. Es kann jedoch Situationen geben, in denen die Notwendigkeit einer Kompatibilitätsunterbrechung die Kosten überwiegen kann, die sie für Programmierer auferlegen kann. Solche Situationen sind:

• Neue Warnungen. Die Einführung einer neuen Warnung ist per se keine Kompatibilitätsunterbrechung. Da jedoch viele Entwickler mit aktivierten "Warnungen als Fehler behandeln" kompilieren, muss bei der Einführung von Warnungen zusätzliche Sorgfalt ausgeführt werden.

• Neue Schlüsselwörter. Die Einführung neuer Schlüsselwörter kann erforderlich sein, wenn neue Sprachfeatures eingeführt werden. Angemessene Anstrengungen werden unternommen, um Schlüsselwörter auszuwählen, die die Möglichkeit einer Kollision mit den Bezeichnern von Benutzern minimieren und vorhandene Schlüsselwörter verwenden, wo es sinnvoll ist. Es wird Hilfe bereitgestellt, um Projekte aus früheren Versionen zu aktualisieren und allen neuen Schlüsselwörtern zu entgehen.

• Compilerfehler. Wenn das Verhalten des Compilers mit einem dokumentierten Verhalten in der Sprachspezifikation in Konflikt steht, kann es erforderlich sein, das Compilerverhalten entsprechend dem dokumentierten Verhalten zu beheben.

• Spezifikationsfehler. Wenn der Compiler mit der Sprachspezifikation konsistent ist, die Sprachspezifikation jedoch eindeutig falsch ist, kann eine Änderung der Sprachspezifikation und des Compilerverhaltens erforderlich sein. Der Ausdruck "eindeutig falsch" bedeutet, dass das dokumentierte Verhalten entgegenläuft, was eine klare und eindeutige Mehrheit der Benutzer erwartet und ein sehr unerwünschtes Verhalten für Benutzer erzeugt.

• Mehrdeutigkeit der Spezifikation. Wenn die Sprachspezifikation angeben sollte, was in einer bestimmten Situation geschieht, aber nicht, und der Compiler behandelt die Situation auf eine Weise, die entweder inkonsistent oder eindeutig falsch ist (unter Verwendung derselben Definition aus dem vorherigen Punkt), klärung der Spezifikation und Korrektur des Compilerverhaltens kann erforderlich sein. Mit anderen Worten, wenn die Spezifikation Fälle a, b, d und e behandelt, aber alle Erwähnungen davon ausgelassen, was im Fall c geschieht, und der Compiler verhält sich falsch in case c, es kann notwendig sein, zu dokumentieren, was in Fall c geschieht und das Verhalten des Compilers zu ändern. (Beachten Sie, dass, wenn die Spezifikation mehrdeutig darüber war, was in einer Situation geschieht und der Compiler sich in einer Weise verhält, die nicht eindeutig falsch ist, wird das Compilerverhalten zur de facto-Spezifikation.)

• Ausführen von Laufzeitfehlern in Kompilierungszeitfehler. In einer Situation, in der Code 100% zur Laufzeit garantiert fehlschlägt (d. h. der Benutzercode hat einen eindeutigen Fehler darin), kann es wünschenswert sein, einen Kompilierungszeitfehler hinzuzufügen, der die Situation erfasst.

• Auslassung der Spezifikation. Wenn die Sprachspezifikation eine bestimmte Situation nicht ausdrücklich zulässt oder nicht zulässt und der Compiler die Situation auf eine Weise behandelt, die nicht erwünscht ist (wenn das Compilerverhalten eindeutig falsch war, wäre es ein Spezifikationsfehler, kein Spezifikationsfehler), kann es notwendig sein, die Spezifikation zu klären und das Compilerverhalten zu ändern. Neben der üblichen Auswirkungsanalyse sind Änderungen dieser Art weiter auf Fälle beschränkt, in denen die Auswirkungen der Änderung als extrem minimal betrachtet werden und der Nutzen für Entwickler sehr hoch ist.

• Neue Features. Im Allgemeinen sollten durch die Einführung neuer Features vorhandene Teile der Sprachspezifikation oder das vorhandene Verhalten des Compilers nicht geändert werden. In der Situation, in der die Einführung eines neuen Features eine Änderung der vorhandenen Sprachspezifikation erfordert, ist eine solche Kompatibilitätsunterbrechung nur dann sinnvoll, wenn die Auswirkung extrem minimal wäre und der Vorteil des Features hoch ist.

• Sicherheit: In außergewöhnlichen Situationen können Sicherheitsbedenken eine Kompatibilitätsunterbrechung erfordern, z. B. das Entfernen oder Ändern eines Features, das inhärent unsicher ist und ein klares Sicherheitsrisiko für Benutzer darstellt.

Die folgenden Situationen sind keine akzeptablen Gründe für die Einführung von Kompatibilitätsunterbrechungen:

• Unerwünschtes oder bedauerbares Verhalten. Sprachdesign oder Compilerverhalten, das vernünftig ist, aber als unerwünscht oder bedauerlich betrachtet wird, ist keine Rechtfertigung für die Abwärtskompatibilität. Der unten beschriebene Sprachdeprecationsprozess muss stattdessen verwendet werden.

• Irgendetwas anderes. Andernfalls bleibt das Compilerverhalten abwärtskompatibel.

Auswirkungskriterien

Bei der Prüfung, ob ein Kompatibilitätswechsel akzeptabel sein könnte, werden mehrere Kriterien verwendet, um zu bestimmen, welche Auswirkungen die Änderung haben könnte. Je größer die Auswirkung ist, desto höher ist die Leiste für die Annahme der Kompatibilitätsunterbrechungen.

Die Kriterien sind:

• Was ist der Umfang der Änderung? Mit anderen Worten, wie viele Programme sind wahrscheinlich betroffen? Wie viele Benutzer sind wahrscheinlich betroffen? Wie häufig wird es sein, Code zu schreiben, der von der Änderung betroffen ist?

• Gibt es Problemumgehungen, um vor der Änderung das gleiche Verhalten zu erhalten?

• Wie offensichtlich ist die Änderung? Erhalten Benutzer sofortiges Feedback, dass sich etwas geändert hat, oder werden ihre Programme einfach anders ausgeführt?

• Kann die Änderung während des Upgrades angemessen behoben werden? Ist es möglich, ein Tool zu schreiben, das die Situation finden kann, in der die Änderung mit perfekter Genauigkeit auftritt, und den Code ändern, um die Änderung zu umgehen?

• Was ist das Feedback der Community zu der Änderung?

Veraltete Sprache

Im Laufe der Zeit werden Teile der Sprache oder des Compilers möglicherweise veraltet. Wie bereits erwähnt, ist es nicht akzeptabel, die Kompatibilität zu unterbrechen, um solche veralteten Features zu entfernen. Stattdessen müssen die folgenden Schritte befolgt werden:

1. Angesichts eines Features, das in Version A von Visual Studio vorhanden ist, muss feedback von der Benutzercommunity zur Deaktivierung des Features und zur vollständigen Benachrichtigung aufgefordert werden, bevor eine endgültige Veraltetkeitsentscheidung getroffen wird. Der Abbruchvorgang kann jederzeit basierend auf Dem Feedback der Benutzercommunity rückgängig gemacht oder abgebrochen werden.

2. Vollversion (d. h. keine Point Release) von Visual Studio muss mit Compilerwarnungen freigegeben werden, die die veraltete Verwendung warnen. Die Warnungen müssen standardmäßig aktiviert sein und können deaktiviert werden. Die Veraltetkeit muss in der Produktdokumentation und im Web klar dokumentiert werden.

3. Eine Vollversion C von Visual Studio muss mit Compilerwarnungen freigegeben werden, die nicht deaktiviert werden können.

4. Eine Vollversion D von Visual Studio muss anschließend mit den veralteten Compilerwarnungen veröffentlicht werden, die in Compilerfehler konvertiert wurden. Die Veröffentlichung von D muss nach Ende der Mainstream-Supportphase (5 Jahre ab diesem Schreiben) der Version A erfolgen.

5. Schließlich kann eine Version E von Visual Studio veröffentlicht werden, die die Compilerfehler entfernt.

Änderungen, die in diesem Veralteten Framework nicht behandelt werden können, sind nicht zulässig.