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。 當編譯程式的行為與語言規格中記載的行為不符時，修正編譯程序行為以符合記載的行為可能是必要的。
規格錯誤。 當編譯程式與語言規格一致，但語言規格顯然錯誤時，可能需要變更語言規格和編譯程序行為。 「顯然錯誤」這句話表示記載的行為會與大部分用戶預期及產生高度不想要的行為相反。
規格模棱兩可。 當語言規格應該說明特定情況但不會發生的情況時，編譯程式會以不一致或明顯錯誤的方式處理方式（使用上一點的相同定義），釐清規格並更正編譯程式行為可能是必要的。 換句話說，當規格涵蓋案例 a、b、d 和 e 時，但省略 c 所發生情況的任何提及，而編譯程式在 c 的情況下的行為不正確時，可能需要記錄 c 所發生的情況，並變更編譯程序的行為以符合。 （請注意，如果規格對發生的情況模棱兩可，而且編譯程序的行為方式並不明顯錯誤，編譯程序行為就會變成事實上的規格。
將運行時間錯誤變成編譯時期錯誤。 如果程式代碼在運行時間保證為 100% 失敗（亦即使用者程式代碼有明確的 Bug），可能會想要新增攔截情況的編譯時間錯誤。
規格遺漏。 當語言規格不明確允許或不允許特定情況，而且編譯程式會以不想要的方式處理這種情況時（如果編譯程式行為明顯錯誤，則規格錯誤，而不是規格遺漏），可能需要釐清規格並變更編譯程序行為。 除了一般的影響分析之外，這類變更也會進一步限制在將變更的影響視為極小的情況，而且對開發人員的好處很高。
新功能。 一般而言，引進新功能不應變更語言規格的現有部分或編譯程式的現有行為。 在引進新功能需要變更現有的語言規格的情況下，只有在影響極小且功能的優點很高時，這種相容性中斷才合理。
安全。 在特殊情況下，安全性考慮可能會造成相容性中斷，例如移除或修改原本不安全的功能，並且對使用者造成明顯的安全性風險。
下列情況無法接受引入相容性中斷的原因：
不可取或令人遺憾的行為。 語言設計或編譯程序行為合理，但回想起來認為不想要或令人遺憾，並不是打破回溯相容性的理由。 必須改用下面涵蓋的語言取代程式。
別的東西。 否則，編譯程序行為會保持回溯相容。
影響準則
考慮相容性中斷是否可接受時，會使用數個準則來判斷變更的影響。 影響越大，接受相容性中斷的列越高。
準則如下：
變更的範圍為何？ 換句話說，有多少程式可能會受到影響？ 有多少使用者可能會受到影響？ 撰寫受到變更影響的程式代碼有多常見？
在變更之前，是否有任何因應措施可以取得相同的行為？
變化有多明顯？ 使用者是否會立即收到已變更的專案意見反應，或者其程式是否會以不同的方式執行？
是否可以在升級期間合理解決變更？ 是否可以撰寫工具，以找出變更發生完美精確度的情況，並變更程式碼以處理變更？
社群對變更的意見反應為何？
語言取代
一段時間后，語言或編譯程式的某些部分可能會過時。 如先前所述，無法中斷相容性，以移除這類已被取代的功能。 相反地，必須遵循下列步驟：
假設 Visual Studio 版本有 一項功能存在，您必須向使用者社群徵求意見反應，以取得淘汰功能，並在做出任何最終淘汰決策之前提供的完整通知。 根據使用者社群意見反應，可能在任何時間點反轉或放棄淘汰程式。
完整版本 （亦即不是點版本）必須發行Visual Studio B ，併發出編譯程式警告，警告已淘汰的使用方式。 警告預設必須開啟，而且可以關閉。 取代必須清楚記載於產品檔和網路上。
必須發行完整的 Visual Studio 版本 C ，且編譯程式警告無法關閉。
Visual Studio 的完整版本 D 之後，必須發行已取代的編譯程式警告，並轉換成編譯程序錯誤。 發行 A 必須在主要支援階段結束之後發行 D （截至本文的 5 年） 之後發生。
最後，可能會發行 Visual Studio 版本 E 來移除編譯程序錯誤。
不允許在此淘汰架構內處理的變更。
