VB.NET VS C#.

End Sub

對於 VB6 來說 event 處理是一項改良，副函數可以從任何物件、任何函數名稱處理事件，並且事實上同一個函數可以處理多種事件。

判決：VB.NET 大勝。VB.NET 可以使用與 C# 一樣複雜的語法，也可以簡單的語法提供動態建立的屬性，以宣告事件的語法提供多種狀況下任何 signature 形式的事件。

VB 命令

想一下 VB6 與 C++ 的差異，C++ 是一種非常簡練的語言--它的關鍵字非常少。也就是說 C++ 程式設計師要靠大量的函式庫--不管是標準的 C runtime、標準的範本函式庫，或是撰寫 Windows 程式的 ATL 或 MFC class library。比起 VB6 的軟體開發人員而言，C++ 的程式設計師也需要對 Win32 API 有更多的了解。

VB 在歷史上真正的力量就在於將那些函數、class libraries 包裝成非常豐富的內建函數或關鍵字。

在 .NET 上，C# 程式設計師可以幾乎使用所有的 .NET framework classes，以及一些 class library 為包含的 Win32 API。VB.NET 當然也可以完全存取這些資源，但它仍然保留了原先內建，強固的關鍵字集合。

但在你以這個原因為主要考量決定採用 VB.NET 時，可以考慮以下的 C# 程式碼

這是什麼，在 C# 呼叫 Visual Basic 的函數？(譯者註：要測試這種做法，C# 要參照 Microsoft.VisualBasic)

是的，大部分 VB 內建的函數現在 .NET 環境下都屬於 Microsoft.VisualBasic namespace。因為它屬於 .NET framework 的一部份，且與 CLS 完全相容，所以這些功能可以被 C# 或是任何其他的語言使用。

當然，這並不表示完全相同，VB.NET 並不需要使用完整的 Namespace 和物件名稱來確認使用的方法。同事 VB.NET 可以執行一些聰明的動作，如利用 mid 函數來設定字串中的子字串

Dim s As String = "abcdef"

VB 程式設計師在以上的程式碼中不會覺得有啥奇怪，但這真是一個令人訝異的動作。因為在 .NET 中字串是永遠不變的(它們不可以被修改)，但 VB.NET 讓整個動作看起來是在私地下建立一個新的字串，並賦予到傳進 mid 函數的字串變數。

判決：VB.NET 贏。從語言的角度看，這是小贏。因為其他的 .NET classes 可以所有在 Microsoft.VisualBasic 中的操作。但從經濟的角度上考量就算不是大贏，也贏得不小。因為 VB 的程式設計師已經熟悉這些 VB.NET 的命令，使用它們可以快速成為 .NET 的開發人員。這是一個短期的好處(因為就算 VB 程式設計師選擇了 C# 最終也會學到 .NET 中對等的功能)，但畢竟它是一個好處。對於 C++ 在 .NET 要選擇何種開發語言，這個優點就毫無意義了(譯者註：因為 C++ 的程式設計師本來也不知道 VB 所提供的命令)。

其他不同的語法

我在這裡不討論 VB.NET 與 C# 基礎語法上的差異，用大括號"{}"還是 Begin...End，用分號還是換行，以 for(,,) 或 For...Next。這些都是語言特色，沒啥麼好比較的。一但你熟悉了一個語言，要在對應到另外一個語言的特色是很容易的。

判決：完全依個人喜好，在這裡不做判決。

效能

我不願意在 Beta 版本比較兩個語言的效能，但記住兩點

1.VB.NET  和 C# 都大量使用了 .NET Framework，它才是兩個語言效能上的主要考量。

2.兩個語言都建立相同的中介語言(Intermediate Language IL)碼，以相同的 Just-in-time(JIT) 編譯器編譯。

基於以上兩點你很難說兩者的效能上有何差異

判決：平手

Using 或 Imports

C# 和 VB.NET 都提供了直接(也可以說是減少撰寫)使用 .NET Framework 架構物件的語法。例如，如果為了除錯你想要輸出一句話到 Visual Studio 視窗上，你可以利用以下的程式碼

System.Diagnostics.Debug.WriteLine("你的除錯碼")

C# 可以撰寫一模一樣的程式碼，只是加個分號。

在 C# 你可以利用 Using 命令來避免需要以全名來參照 Debug 物件，用法如下

using System.Diagnostics;

這讓你可以直接使用 Debug 物件，程式碼如下

Debug.WriteLine("除錯碼");

在 VB.NET 可以用 Imports 做到相同的事

Imports System.Diagnostics

第一眼看來這兩者是相同的，但以撰寫 Console 應用程式為例，在 C# 你要存取 Console.WriteLine 函數，需要撰寫如下

Console.WriteLine("你的輸出字串");

在這裡需要注意的是 C# 一定要定義 Console 物件的名稱。Using 語法只提供不用重複撰寫 Namespace，但與 Object 無關。在 VB.NET，你可以利用 Imports 直接提供到物件的簡寫，範例如下

Imports System.Console

所以程式碼可以更簡寫成

WriteLine("你的輸出字串")

判決：VB.NET 贏。可以直接引用的物件會帶來許多方便，尤其是在列舉一串的控制字元時。

Unmanaged Code

C# 讓你可以定義一個 unmanaged code 區塊--可以利用指標來存取 unmanaged memory。

在第一眼看來這似乎是 C# 的主要好處，但以下列理由來說，它並不見得真好

當下的 benchmarks 顯示 unmanaged code 並未比 managed code 顯著提升效能

因為 managed code 所提供的好處，強烈建議不要使用 unmanaged code(如減少 memory leak、memory 存取錯誤等等)

與一般的想法相反的是 C# 直接存取 unmanaged code 的能力並不表示你可以避免掉如 .NET interop 函數對 managed 與 unmanaged 程式碼間資料的 marshal。

VB.NET 可以完整存取 .NET interop 函數，包含呼叫任何API 函數，並使用所有標準的 marshaling 屬性從 managed memory(包括 COM 的呼叫)來 marshal 資料、物件和結構

VB.NET 可以使用 unmanaged memory，它可以獲取或釋放一個 unmanaged memory 區塊。它可以來回複製 unmanaged memory。它只是卻少內建的關鍵字，而必須要藉由 .NET interop 方法。

判決：C# 小贏

Assembly 組織

C# 讓你可以將 assembly 切成多個輸出檔案。這在你需要以多個檔案的方式來散佈應用程式時用到，如透過網路下載。VB.NET 的專案建立一個單一的輸出(DLL 或 EXE)。

因為部分散佈的方式可以同樣多個 assemblies 的方式散佈，所以很難說這是 C# 主要的好處。可能還會有人強調維護 assemblies 和可執行檔間的一對一對應是比較好維護與散佈的。

判決：C# 贏，但代價多大

(譯者註：據譯者的測試，這部分 VB.NET 也可以多個編譯過的 mod ，透過一個 manifest 以 al.exe 組成一個執行檔，似乎兩者應該是平手。但不確定是否是 Daniel Appleman 所強調的)

分別大小寫(case sensitivity)

分別大小寫也是信仰問題。C++ 的程式設計師偶爾會強調變數、方法、指令分別大小寫的重要。VB 的程式設計師則享受的不分大小寫的自由，並讓編譯器來修正他們曾經定義的變數的大小寫差異。

除了一點以外其實我們可以不討論這的問題， CLS 要求所有公共的名稱是不分大小寫的。這表示 C# 的程式設計師可以定義不同公共的成員 method1 和 Method1，從 C# 的角度來看是不同的，但對其他的 assembly 來說是相同的，這個結果會讓人混淆。所以若 C# 的程式設計師若要考慮與 CLS 相容，就必須小心不要在定義公共元素上以大小寫來區分不同。

判決：VB.NET 贏在與 CLS 相容

XML 文件

C# 讓你可以內建 XML 格式的說明文件到程式碼中，格式的範例如下

/// <summary>

/// 對於 Class1 的描述

/// </summary>

編譯器也可以對於 XML 文件做一些聰明的判斷，例如 seealso 標籤不僅僅讓編譯器建立程式碼元素交互參照，也可以確認被參照的元素是否存在，也就是說你可以有標籤如下

<seealso cref="Class2">

若在你的程式中沒有找到 Class2，編譯器會警告你。

判決：第一眼看起來 XML 文件似乎是個很好的構想。我很難判斷它是否會因此流行起來，但讓程式碼本身就具備說明能力，且讓編譯器可以不僅判讀文件的正確性，也提醒程式設計師所疏忽的公共物件與方法的文件是一個很吸引人的概念。所以我認為這是 C# 重大的贏面，並請問微軟為何 VB.NET 沒有？

語法之外的

有一些考量與語言的語法本身無關，但仍是選擇兩個語言時需要考慮的。

背景編譯與解析

C# 有一個非常聰明的分析器，幫你在編輯程式碼時標註錯誤，如漏寫分號或語法錯誤。但它畢竟不是完整的編譯器，所以無法抓到一些語意上的錯誤，如

using System.一些不存在的Namespace;

分析器在沒有編譯器的幫忙下無法方便錯誤而接受，這個錯誤要到編譯時期才會被發現。

如果你在 VB.NET 輸入相同的程式碼

Imports System.一些不存在的Namespace

VB 會立刻標出錯誤所在，並表示它找不到這個 namespace。VB 可以這麼做是因為 VB 的編譯器在你撰寫程式時已經完整地在背景執行。

問題是：收到即時錯誤有多重要？這又是一定程度的個人偏好。我相信有些程式設計師會先僅僅編寫程式，再在程式 build 時回來檢視錯誤﹔以往我個人用這種方式就已經足夠了。但以我個人的觀點來看，在開發環境提供撰寫程式時立刻錯誤檢查會大幅提升效率，我可以確定在移到下一行之前每一行程式碼都可以編譯，對我來說一開始就寫正確比事後在編譯時期發現錯誤再修改要有效率得多。

我鄭重地建議你在兩種編輯環境各花一小時來編寫程式，相信一但你熟悉了 VB.NET 的背景編譯，就會感受到沒有它的痛苦。

判決：VB.NET 大贏

從 VB6 升級

對於將 VB6 的程式碼升級到 VB.NET，我已經強調過 "移植是不聰明的"，可能還不如再 .NET 建立相的程式碼，或是利用 interop system 來與已有的 COM 物件或 DLL 合作。

但仍有一些元件適合升級程式碼--尤其是希望用到 .NET free threading 特色的商業邏輯元件，或是有 memory leak 問題而希望透過 .NET 的記憶體管理獲得改善的元件。

我已經強調在大多數狀況下移植是不聰明的，若還要將 VB6 的程式碼轉成 C# 更是愚蠢至極。VB.NET 最少還提供了升級精靈來幫忙處理大部分乏味的苦工。最重要的是 VB  程式碼所使用的 Visual Basic 風格的錯誤處理與 VB.NET 和 C# 徹底不同。但與 C# 不同的是 VB.NET 仍然支援舊的錯誤處理方式，讓你在升級程式碼時可以結合新舊的錯誤處理，而不需要大費周章地重新設計錯誤處理邏輯。

不要搞錯：以 Exception 為基礎的錯誤處理是遠較 VB 舊格式的錯誤處理機制來得好。但若你需要升級舊有的程式碼，你最好還是升級錯誤處理的方式。

判決：VB.NET 大贏，但只對 VB6

聰明的格式化

C# 和 VB.NET 都提供某種程式化地自動完成語法--如自動加上結尾的大括號或是 End 區塊語法。也包含某種層度的自動縮排。

但 VB.NET 的編譯器要遠比 C# 來得聰明。我立刻發現我不再需要注意程式縮排的問題，只要讓 VB.NET 的編輯器去做就可以了，我在任何地方敲上程式碼它都可以立刻以正確的格式縮排，非常酷。

C# 在括號配對上做得不錯(所以你可以輕易分辨程式區塊)，但從編輯程式的角度上來看，我仍然判定 VB.NET 贏

判決：VB.NET 徹底省掉了格式化程式的麻煩

熟悉與學習成本

熟悉語法是程式設計師最需要的，也是學新語言最貴的成本。

明顯地不管是選擇 VB.NET 或 C# 學習 .NET 都比學語法來得重要。事實上，語言是如此的相似，只要你熟悉一種語言，在幾天之內就可以熟悉另一種語言。

在短期的好處上是使用原來熟悉的語法，只要努力去了解 .NET 的架構即可

判決：VB.NET 給 Visual Basic 程式設計師，C# 給 C++ 和 Java 的程式設計師

結論

較重要的考量

下表列出明顯的差異，當你在選兩種語言時可以慎重考慮，這些比較長遠地影響開發成本

次要考量

下表列出兩個語言的次要考量，不像前述重要考量上對軟體開發生命週期長遠成本的影響。而比較偏向對先前版本的個人因素考量。

考量是否與 CLS 相容

下表列出是否你需要考慮與 CLS 相容的各點

上一页  [1] [2] [3] [4] 

Copyright ＠ 2007-2012 敏韬网(敏而好学，文韬武略--MinTao.Net)（学习笔记） Inc All Rights Reserved.
闵涛 E_mail:admin@mintao.net(欢迎提供学习资源)

鄂公网安备 42011102001154号

站长：MinTao ICP备案号：鄂ICP备11006601号-18