為什麼 VB 裡面是 Dim?從 BASIC 行號到 Excel VBA 的歷史演進
Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license.
If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1280
在很多人眼裡,VB(Visual Basic / VB.NET)看起來「老派」、「不主流」。但如果我們回頭去看它的歷史,你會發現這些奇怪的關鍵字、設計方式,背後其實都有時代的印記。
本文將從Dim
的由來講起,一路談到 BASIC 的行號、子程序、VB.NET 的地位,以及為什麼 Excel 至今還沒有淘汰 VBA。
1. Dim
是什麼?為什麼不是 Declare
?
在 VB 裡,我們用 Dim
來宣告變數,例如:
Dim x As Integer
Dim name As String
Dim arr(10) As Double
這個關鍵字其實來自 Dimension(維度) 的縮寫。在 1960s 的早期 BASIC 裡,變數本來不需要宣告,直接用就行。但陣列需要指定大小,於是才有了 DIM
命令:
10 DIM A(10) ' 宣告一個 10 元素的陣列
20 DIM M(5,5) ' 宣告一個 5x5 矩陣
隨著 Visual Basic 的出現,微軟決定「繼承」這個語法,把 Dim
泛化為所有變數的宣告方式。
而另一個關鍵字 Declare
,則被專門用來聲明「外部函數」(DLL 函數),比如:
Declare Function GetTickCount Lib "kernel32" () As Long
這樣一來,Dim
與 Declare
的語義被區分開來:
-
Dim
= 我要一塊記憶體空間(內部變數) -
Declare
= 我要告訴編譯器外部有一個函數 -
Const
= 我要一個常數 -
Static
= 我要一個靜態變數
這樣的關鍵字設計,其實是 內存 vs 外部接口 vs 常數 的清楚分工。
2. 為什麼 BASIC 要行號?為什麼從 10 開始?
在早期 BASIC 程式裡,你會看到這樣的代碼:
10 PRINT "HELLO"
20 GOTO 10
這裡的 10
、20
並不是變數,而是 行號 (Line Number)。
作用
-
指定程式執行順序(按行號大小執行)。
-
作為
GOTO
、GOSUB
的跳轉目標。 -
幫助「編輯」程式 —— 在沒有現代 IDE 的年代,你只能一行一行輸入和修改。
為什麼從 10 開始、每隔 10?
雖然可以從 1、2、3 寫,但大家更習慣用 10,20,30…
。理由是:
-
方便插入新行。比如要在 10 和 20 之間加一句,就可以用
15
。 -
如果行號用滿了,可以用
RENUM
命令重排。
這不是語法強制,而是 程式員的共識。
你甚至可以用行號 0(0 PRINT "HELLO"
),但幾乎沒人這樣幹,因為容易混淆。
3. BASIC 沒有函數?那怎麼辦?
早期 BASIC 的確沒有「自定義函數」的概念。
只能用 GOSUB ... RETURN
來模擬子程序:
10 INPUT "Your name"; N$
20 GOSUB 100
30 END
100 PRINT "Hello "; N$
110 RETURN
這樣的「子程序」:
-
不能帶參數
-
沒有回傳值
-
全靠全域變數傳資料
所以說,早期 BASIC 更像是 面向過程的初級形態。
到了 QuickBASIC (1985),才正式加入 SUB
和 FUNCTION
,能定義參數與回傳值。再到 Visual Basic (1991),才徹底進入「結構化程序設計」。VB.NET 則進一步支援完整的 OOP(物件導向)。
👉 BASIC 的演進路線可以概括為:
指令流 (Line Number + GOTO) → 面向過程 (GOSUB) → 結構化 (SUB/FUNCTION) → 物件導向 (Class in VB.NET)。
4. 那 VB.NET 還「爛」嗎?
很多人覺得 VB.NET 過時,其實這要分兩方面看:
技術層面
VB.NET 本質上與 C# 一樣強大,因為它們都跑在 .NET CLR 上。
-
有 OOP、LINQ、Lambda、Async/Await。
-
能做 WinForms、WPF、ASP.NET、Entity Framework。
-
編譯出來的 IL 幾乎與 C# 無差。
👉 VB.NET ≠ 技術爛。
生態層面
-
微軟從 .NET Core 開始,重心轉到 C#。
-
新特性、範例、教學幾乎只有 C#。
-
社群規模懸殊,VB.NET 幾乎只剩「維護老系統」。
👉 VB.NET = 被邊緣化。
5. 為什麼 Excel 只能寫 VBA,而不是 C#?
Excel 的巨集(Macro)一直用 VBA (Visual Basic for Applications)。
很多人納悶:為什麼不用 C#?
原因
-
歷史包袱:1993 年 Excel 5.0 就內建 VBA,至今數億份文件依賴它。
-
使用者族群:會計師、分析員不是程式設計師,VBA 更容易學。
-
內建引擎:VBA 是解譯器,程式碼可以直接存進
.xlsm
文件,C# 需要外部 CLR,太重。 -
安全與部署:VBA 宏能夠被 Excel 管控(雖然仍有安全風險),而 C# 如果內建,宏病毒會更危險。
微軟的替代方案
-
VSTO (C#/VB.NET Add-in) → 部署麻煩,沒普及。
-
Office.js (JavaScript API) → 用於 Web Add-in,不是宏。
-
Office Scripts (TypeScript) → Excel Online 的新方向,但還不成熟。
為什麼沒淘汰 VBA?
不是因為性能,而是因為:
-
巨大的歷史相容性成本。
-
使用者群體對 VBA 依賴太深。
-
微軟還沒找到能完全取代的解決方案。
6. 總結:從 Dim
到 VBA,背後的邏輯
-
Dim
:原本只為陣列(Dimension),後來泛化為所有變數的宣告。 -
行號:為了在沒有 IDE 的年代方便插行,於是大家用
10,20,30
。 -
子程序:早期 BASIC 沒有函數,只能用
GOSUB
,算是面向過程的起點。 -
VB.NET:技術上很強,但社群與戰略上被邊緣化。
-
Excel VBA:不是性能最佳,而是「相容性 + 使用者群體」決定了它至今不死。
👉 這些設計看似「奇怪」甚至「落後」,其實都是當年 時代背景 + 實用妥協 的結果
✍️ 如果你今天在用 VB.NET 或 VBA,別急著笑它「爛」——它們其實是歷史演進的活化石,也是微軟工程哲學裡「兼顧相容性與現實需求」的最好見證。
This article was last edited at