VB.NET與C#語言之間的比較分析
在網上經常能看到一些評論和比較C#與VB.net優劣的文章。其中絕大多數都認為：VB.net就沒有它存在的必要，VB.net遲早要被C#取代。
確實，計算機語言不是很重要的，也許討論它有點無聊。所以還希望那些“心中無劍”、“架構、思想至尚”的高手們口下留情。
關于C#與VB.net在功能、能力、面向對象的特性上，實在是難分伯仲。這個已是不爭的事實。尤其是VS.net2005中，這兩種語言已經達到了驚人地相似！
下面就通過三個大方面對這這兩種語言進行比較：
一、語言的人性化區別
C#像傻男人，VB.net像聰明賢惠的女人
從代碼的風格就可以看出。
例1. 聲明變量時：
C#: int iTest ; //很直接的語氣,類似于:擦汗！拿毛巾
VB.net Dim iTest As Integer ‘很委婉的語氣,類似于:小王,給我拿條毛巾,我用它擦汗~
實現完全相同的功能，但有著很明顯的區別。哪個更人性化、更易懂呢？
例2.語言的關鍵字上：
C#關鍵字：
using、this、void、base、abstract、sealed、virtual、switch、internal、static
相應的VB.net關鍵字：
Imports、Me、Sub、MyBase、MustInherit、NotOverridable、MustOverride、Select 、Friend、Shared
比較一下，C#的關鍵字比較冰冷，是具有一定“機器味道”的語言。
而VB.net的關鍵字，都是“人的行為”，“人的稱謂”。
相信VB.net的語法更具親和力，更易于幫助我們理解面向對象的特性。
二、語言的先進性的對比
現在，計算機軟件工程越來越龐大，已經遠遠不是10年前的幾十KB大小的級別了。這就對語言的可擴展性、可輔助性提出了更高的要求。“面向對象”便是這個需求的一個產物。
從現有的語言來看，具有“標識符”的標識性語言具備更高的容錯性、可調試性、可擴展性。比如HTML、XML。尤其是XML已經成為了下一代語言的模型。
為什么像HTML、XML這種具有“開口”和“封口”的語言 有更高的容錯性、可調試性呢？這要取決于它的“吝嗇”性。“開口”和“封口”可以把故障的范圍最小化，使出現問題的部分盡量不影響其它部分。比如說：在HTML的< table>中，少寫一個< TR>多寫一個< TR>均不會對表格中其它行造成太大的影響。
與 這種“吝嗇”的語法相反的是“貪婪”性的語法。什么是“貪婪”性呢？這個問題也不太好解釋。不過，這種特性與正則表達式的解析十分十分地一致。“吝嗇性”的正則表達式 用做 精確匹配Group時有著較高的性能，而“貪婪性”的正則表達式用于判斷IsMatch時有著較高的性能。
像C類的所有封口均使用大括號的語言，就屬于這種“貪婪性”性的語言。過多相同的封口使得代碼更加地難于控制。
許多人抱怨微軟，為什么不給C#加上動態編譯、加上自動完成……，實際上，微軟何嘗不想加啊，但由于C#的語法特性，是根本無法實現的。下面就用實例來說明為什么C#無法實現動態編譯：
看下面的C#代碼段，代碼中的大括號是不平衡的：
- class A {
- class B {
- class C
- {
- int F1()
- {
- return 1;
- }
- int F2()
- {
- return 2;
- }
- }
- }
假如現在已經有了C#的動態編譯器，現在要求編譯器指明到底是哪里丟失了大括號！
這時，編譯器就糊涂了：因為不論是把大括號加在F1的末尾 還是加在class A的末尾 都是行得通的，雖然這兩種情況的意義是完全不同的，即：不能判斷F1到底是Class C的方法，還是Class B的方法。那么連帶下一步，在代碼的其它部分 就更無法判斷 調用F1的代碼的合理性了。
這里只是舉了一個簡單的例子，實際的情況比這個更復雜。我們可以看到，在C語言的代碼沒有完全正確地書寫之前，它的結構是有可能極度混亂、多意性的，在這種極度混亂的環境下 是無法判斷故障之所在、無法正確識別對象的結構的。自然，這樣的動態編譯器也就成了“累贅”。
相比之下，同樣的內容 看看VB語法：
- Class A
- Class B
- Class C
- Function X1() As Integer
- Return 1
- End Function
- End Class
- Function X2() As Integer
- Return 2
- End Function
- End Class
- End Class
無論你刪除End Class還是刪除End function，故障范圍都不會擴大，定位就可以做到精準。
檢錯如此，自動完成代碼也是如此。在C#環境下，由于代碼結構可能存在著“多意性”，所以IDE有可能無法決定做處理的確切位置。
當然，C類的代碼并不是沒有優點，其優點主要有二：
1.節省代碼所占的磁盤和內存空間
2.使編譯器的體積能夠做得更小（最終還是為了節省磁盤空間）
只有在 內存和磁盤空間非常珍貴的過去的年代里，C類語言代碼才能夠更具優勢。
然而在內存和磁盤如此豐富的今天，這種優勢已經成了劣勢。
借助于這種具有確定的“開口”與“封口”的特性，相信VB.net會走得更遠。
三、語言的靈活性、適應性的對比
C#的代碼，可以“隨便書寫”：在一行里可以寫多條語句，一條語句可以分成多行來寫。這使得它的代碼有可能更加地“松散”。雖然C#允許您把代碼寫得非常地松散，不過在實際的使用中，幾乎所有的使用者都默默地走向了VB的代碼風格（一行一條語句）。***，它的分號成了累贅。
雖然C#的代碼更加地自由，不過C#的思想比起VB.net起來卻是更加地死板。
在這方面，我覺得把C#比做手動檔汽車、把VB.net比做自動檔汽車是比較合適的。自動檔汽車也可以用手動檔的方式駕駛。
C#的思想、思路在VB.net中均可實現，而VB.net的思想（自動檔）卻經常無法在C#上實現。下面舉例說明：
例一：事件模型
在C#中，事件模型是固定的，構造一個事件模型通常需要下面的思路：
建立事件代理結構、聲明事件、建立事件處理方法、添加事件句柄、判斷事件代理是否掛到上實例、通過代理方法引發事件。
在VB.net中，即可以按照C#所用的模式建立事件，也可以用VB.net自身所帶的RaiseEvent方法實現。雖然他們編譯后的結構幾乎是一樣的，但畢竟VB.net讓我們有了更多的選擇，何樂而不為呢？下面就看看VB.net引發事件的兩種方法示例：
方法一：用RaiseEvent.
這是一種非常快捷、代碼思路非常清晰的一種方法：
- Class EventClass
- Public Event E1(sender as Object,e as XXXEventHandler)
- Sub XXXX()
- RaiseEvent E1(Me,new XXXEventHandler(…)
- End Sub
- End Class
方法二：用C#的的思路
- Public Delegate Sub xxxHandler(ByVal sender As Object, ByVal e As EventArgs)
- Public Class A
- Public Event XXX As xxxHandler
- Public Overridable Sub OnXXXEvent(ByVal sender As Object, ByVal e As EventArgs)
- If XXXEvent IsNot Nothing Then
- XXXEvent.Invoke(sender, e)
- End If
- End Sub
- Sub X()
- OnXXXEvent(Me, New EventArgs)
- End Sub
- End Class
“用盡量少的代碼 做出更多的事情”是每個人程序員的***！
很顯然，VB.net在這方面占盡了優勢。
例二：可選參數結構
如下代碼展示了VB特有的結構：可選參數
- Public Sub XXX(P1 As Integer,Optional P2 As String,Optional P3 As String)
- ‘…
- End Sub
這樣的結構在C#中是無法實現的，但可以通過“重載”的方式實現相同的效果：
- void XXX(int P1){}
- void XXX(int P1,string P2){}
- void XXX(int P1,string P2,string P3{}
當然，用VB.net也可以用重載方式寫出一模一樣的結構。
例三：事件代理的掛接
C#中：只有一種方法：XXX.XXX += new XXX(…);
VB.net中：即可以效仿C#的方法：AddHandler(XXX.xxx,AddressOf XXX)
也可以把過程顯示地指定給某個事件：Sub(…) Handles XXX.XXX
利用上面的第二種方法的特性，可以實現在VB.net代碼編輯頁中 簡單地通過下拉框 來精確地定位某個對象的特定事件的處理過程。
遺憾的是，這種方便的特性在C#中是無法實現的。因為C#的語法:XXX.XXX +=的后面可以是任何方法返回的具有相同簽名的實例。比如 通過屬性、方法，甚至是隨機判斷后返回的。
這種“過份的自由”使得C#編譯器在運行代碼前不能準確地確定該對象事件的處理部位。
類似的例子太多了，舉不勝舉。
總之，VB.net給了我們更大的活動空間，它允許我們在“更快的速度”和“更嚴格性能要求”之間自由選擇。
四、代碼書寫上的比較
（一）變量的命名的區別
C#是區分變量的大小寫的，這一點著實讓人摸不著門。也許這僅僅是為了效仿Java?
在公共語言規范中(CLS)，明確規定“變量不區分大小寫”的，真是難為了C#編譯器，還要把“重名”的變量重新命名。
相比之下，VB.net更加符合CLS，而且因為不區分大小寫，編輯器就更輕松地實現了“自動更正”功能。
C#絕對是“嫁錯了人”。
C要區分大小寫，其原因有二：一是為了能使用更多的變量資源，二是為了節省編譯器的開銷（性能和體積上都節省）。
如今，.net環境允許我們使用多達1024個長度的變量名，而且已完全面向對象化，相同的變量可以同時出現在任何object中，所以可用的變量資源數量 理論上已經達到了無窮多個！
在這樣的條件下，“區分大小寫”使代碼在 可讀性、可調試性、可輔助性上都造成了不小的負面影響！它已經成為了語言發展的障礙！
（二）代碼的書寫
幾乎絕大多數的C#程序員都覺得他們在代碼的書寫上有著***的優越性，因為C#代碼看上去是如此的簡潔。
是的，如果我們僅使用記事本來開發.net應用程序，我相信像VB、Delphi早就滅絕了。
但更糟糕的是：如果我們僅能使用記事本寫代碼，那么程序員也早就集體自殺了。
說多少也不會有人相信，尤其是C#程序員不會相信 在代碼書寫方面 他們會完敗于VB.net程序員。
我們完全可以用“鍵盤鉤子”做個小程序來檢測、驗證一下到底是哪種代碼更浪費鍵盤、書寫起來更吃力。（這個程序我已經寫好，有興趣的可以到http://img.pcpop.com/upimg2/2005/5/15/491525800.jpg 來下載。注意：必須使用網絡快車下載，下載后把文件更改為exe的即可直接運行。這個序使用VB.net + Framework1.0編寫，必要的時候 需要你安裝.net框架。）
測試結果很明顯：VB.net代碼需要按鍵的次數更少、書寫更為容易。原因是IDE在其中起到了極大的作用！
VB.net不必像C#那樣不停地用Ctrl+shift+B來編譯檢錯；不必不停地按下Shift鍵來輸入星羅棋布的符號；不必不停地使用Ctrl+]徘徊于大括號之間；更不必手動輸入眾多的“關閉符”。
（試一試：輸入If A=B [回車]，這時 Then和End IF馬上就都給你準備好了）
(再試一試：在一個剛剛建立的新Class中，輸入Inherits后 回車，所有需要實現的方法都給你準備好了)
究其本質，是由于VB.net的語言起到了決定性的作用。
正是因為我們已經告訴了編輯器“這是一個ReadOnly Property”，所以編輯器會給我們自動提供了Get結構代碼；
正是因為我們已經告訴了編輯器“這是一個WithEvents的對象”，所以編輯器會在對象事件選擇列表里加入它；
正是因為我們已經告訴了編輯器“這是一個Event”，所以當我們要RaiseEvent時，它會準確地出現在列表中；
正是因為我們已經告訴了編輯器“這是一個Function”，所以當我們寫上調用方法后，它會自動地在后面加上括號；
……
反觀C#，由于代碼過度地萎縮，許多事情還需要通過分析整段代碼的結構來決定它的屬性，導致這些“智能的操作”無法在C#上實現。
但這些動詞并不能表明C#與VB.net之間具有什么差距！！！！
【編輯推薦】
