Microsoft® Visual Basic® 编程语言是 Microsoft .NET Framework 的高级编程语言。 尽管它设计为一种易于理解且易于学习的语言，但它也足以满足经验丰富的程序员的需求。 Visual Basic 编程语言的语法类似于英语，可提升 Visual Basic 代码的清晰度和可读性。 尽可能使用有意义的字词或短语，而不是缩写、首字母缩略词或特殊字符。 通常允许非必要或不需要的语法，但不需要。
Visual Basic 编程语言可以是强类型语言，也可以是松散类型语言。 松散键入会延迟类型检查的重担，直到程序已在运行。 这不仅包括转换的类型检查，还包括方法调用的类型检查，这意味着方法调用的绑定可以延迟到运行时。 当生成原型或其他程序时，开发速度比执行速度更重要时，这非常有用。 Visual Basic 编程语言还提供强类型语义，用于在编译时执行所有类型检查，并禁止方法调用的运行时绑定。 这可以保证最佳性能，并帮助确保类型转换正确。 生成执行速度和执行正确性非常重要的生产应用程序时，这非常有用。
本文档介绍 Visual Basic 语言。 它应该是完整的语言说明，而不是语言教程或用户的参考手册。
语法表示法
此规范描述了两种语法：词法语法和语法语法。 词法语法定义如何将字符组合到表单标记;语法定义如何组合标记以形成 Visual Basic 程序。 还有几种辅助语法用于预处理作，例如条件编译。
此规范中的语法以 ANTLR 格式编写 -- 请参阅 http://www.antlr.org/。
Visual Basic 程序中的情况并不重要。 为简单起见，所有终端都将以标准大小写提供，但任何大小写都将匹配它们。 作为 ASCII 字符集的可打印元素的终端由相应的 ASCII 字符表示。 匹配终端时，Visual Basic 也区分宽度，允许全角 Unicode 字符匹配其半角 Unicode 等效项，但仅以全标记为基础。 如果标记包含混合半角和全角字符，则令牌不匹配。
可以为可读性添加换行符和缩进，并且不属于生产环境。
兼容性
编程语言的一个重要功能是语言的不同版本之间的兼容性。 如果较新版本的语言不接受与以前版本的语言相同的代码，或将其解释为与以前版本不同的语言，则在将语言的一个版本升级到另一个版本的代码时，可能会给程序员带来负担。 因此，必须保留版本之间的兼容性，除非语言使用者的好处是清晰而压倒性的。
以下策略控制对版本之间的 Visual Basic 语言的更改。 此上下文中使用的术语语言仅指 Visual Basic 语言本身的语法和语义方面，不包括作为命名空间的一部分 Microsoft.VisualBasic （和子命名空间）包含的任何 .NET Framework 类。 .NET Framework 中的所有类都由本文档范围之外的单独版本控制与兼容性策略涵盖。
兼容性中断类型
在理想世界中，现有版本的 Visual Basic 与 Visual Basic 的所有未来版本之间的兼容性为 100%。 但是，在某些情况下，兼容性中断的需求可能超过它可能对程序员施加的成本。 这种情况如下：
新警告。 引入新的警告不是兼容性中断。 但是，由于许多开发人员使用“将警告视为错误”进行编译，因此在引入警告时必须格外小心。
新关键字。 引入新语言功能时，可能需要引入新关键字。 将做出合理的努力来选择关键字，以最大程度地减少与用户标识符冲突的可能性，并使用现有关键字，使其有意义。 将提供帮助，以便从早期版本升级项目并转义任何新关键字。
编译器 bug。 当编译器的行为与语言规范中记录的行为不符时，修复编译器行为以匹配记录的行为可能是必要的。
规范 bug。 当编译器与语言规范一致，但语言规范明显错误时，可能需要更改语言规范和编译器行为。 短语“明显错误”意味着记录的行为与大多数用户期望的明确且明确的行为相反，并且会为用户生成高度不受欢迎的行为。
规范不明确。 当语言规范应阐明特定情况下发生的情况，但不会发生的情况时，编译器会以不一致或明显错误（使用上一点的相同定义）的方式处理这种情况时，可能需要阐明规范并更正编译器行为。 换句话说，如果规范涵盖大小写 a、b、d 和 e，但省略 c 中发生的情况的任何提及，并且编译器在 c 的情况下行为不正确，则可能需要记录 c 中发生的情况并更改编译器的行为以匹配。 （请注意，如果规范对发生的情况不明确，并且编译器的行为方式不明确，编译器行为将成为事实上的规范。
将运行时错误转换为编译时错误。 如果代码在运行时保证为 100% 失败（即用户代码中存在明确的 bug），则可能需要添加可捕获这种情况的编译时错误。
规范遗漏。 如果语言规范不明确允许或禁止特定情况，并且编译器以不可取的方式处理这种情况（如果编译器行为明显错误，则规范 bug 而不是规范遗漏），可能需要澄清规范并更改编译器行为。 除了通常的影响分析之外，此类更改还进一步限制在将更改的影响视为极小且对开发人员的好处非常高的情况下。
新功能。 一般情况下，引入新功能不应更改语言规范的现有部分或编译器的现有行为。 在引入新功能需要更改现有语言规范的情况下，仅当影响极小且功能的好处很高时，这种兼容性中断才合理。
安全性。 在特殊情况下，安全问题可能需要出现兼容性中断，例如删除或修改本质上不安全的功能，并给用户带来明显的安全风险。
以下情况是引入兼容性中断的不可接受原因：
不良或令人遗憾的行为。 语言设计或编译器行为合理，但在回顾中认为不可取或令人遗憾，这不是破坏向后兼容性的理由。 必须改用下面介绍的语言弃用过程。
别的东西。 否则，编译器行为仍向后兼容。
影响条件
在考虑是否可接受的兼容性中断时，可以使用多个条件来确定更改的影响。 影响越大，接受兼容性的条形越高。
条件为：
更改的范围是什么？ 换句话说，有多少程序可能会受到影响？ 有多少用户可能会受到影响？ 编写受更改影响的代码有多常见？
在更改之前，是否有任何解决方法可以获取相同的行为？
变化有多明显？ 用户是否会立即获得某些更改的反馈，或者他们的程序是否只是以不同的方式执行？
是否可以在升级期间合理解决更改问题？ 是否可以编写一个工具，以完美的准确性查找更改发生的情况，并更改代码以处理更改？
社区对更改的反馈是什么？
语言弃用
随着时间的推移，语言或编译器的某些部分可能会弃用。 如前所述，无法中断兼容性以删除此类已弃用的功能。 相反，必须遵循以下步骤：
鉴于 Visual Studio 版本 A 中存在的功能，必须在用户社区征求有关弃用该功能的反馈，并在做出任何最终弃用决策之前发出完整通知。 弃用过程可能会根据用户社区反馈在任何时刻撤消或放弃。
完整版本（即不是点发布）必须发布 Visual Studio 的 B ，编译器警告已弃用。 默认情况下，警告必须处于打开状态，并且可以关闭。 弃用必须清楚地记录在产品文档和 Web 中。
Visual Studio 的完整版本 C 必须发布，并显示编译器警告，这些警告无法关闭。
Visual Studio 的完整版本 D 随后必须发布，并显示已弃用的编译器警告，这些警告已转换为编译器错误。 D 的发布必须在主流支持阶段（截至本文撰写 5 年）结束之后发布 A。
最后，可能会释放 Visual Studio 的版本 E ，以删除编译器错误。
不允许在此弃用框架中处理的更改。
