在網(wǎng)上經(jīng)常能看到一些評論和比較C#、VB.net優(yōu)劣的文章。其中絕大多數(shù)都認(rèn)為：VB.net就沒有它存在的必要，VB.net遲早要被C#取代。
        確實，計算機(jī)語言不是很重要的，也許討論它有點無聊。所以還希望那些“心中無劍”、“架構(gòu)、思想至尚”的高手們口下留情。

        關(guān)于VB.net與C#在功能、能力、面向?qū)ο蟮奶匦陨希瑢嵲谑请y分伯仲。這個已是不爭的事實。尤其是VS.net2005中，這兩種語言已經(jīng)達(dá)到了驚人地相似！

下面就通過三個大方面對這這兩種語言進(jìn)行比較：

一、語言的人性化區(qū)別

C#像傻男人，VB.net像聰明賢惠的女人
從代碼的風(fēng)格就可以看出。

例1.   聲明變量時：
C#: int   iTest   ; //很直接的語氣,類似于:擦汗！拿毛巾
VB.net Dim   iTest   As   Integer ‘很委婉的語氣,類似于:小王,給我拿條毛巾,我用它擦汗~實現(xiàn)完全相同的功能，但有著很明顯的區(qū)別。哪個更人性化、更易懂呢？

例2.語言的關(guān)鍵字上：
C#關(guān)鍵字：
using、this、void、base、abstract、sealed、virtual、switch、internal、static
相應(yīng)的VB.net關(guān)鍵字：
Imports、Me、Sub、MyBase、MustInherit、NotOverridable、MustOverride、Select   、Friend、Shared

比較一下，C#的關(guān)鍵字比較冰冷，是具有一定“機(jī)器味道”的語言。
而VB.net的關(guān)鍵字，都是“人的行為”，“人的稱謂”。
相信VB.net的語法更具親和力，更易于幫助我們理解面向?qū)ο蟮奶匦浴?/p>

二、語言的先進(jìn)性的對比
現(xiàn)在，計算機(jī)軟件工程越來越龐大，已經(jīng)遠(yuǎn)遠(yuǎn)不是10年前的幾十KB大小的級別了。這就對語言的可擴(kuò)展性、可輔助性提出了更高的要求。“面向?qū)ο?#8221;便是這個需求的一個產(chǎn)物。

從現(xiàn)有的語言來看，具有“標(biāo)識符”的標(biāo)識性語言具備更高的容錯性、可調(diào)試性、可擴(kuò)展性。比如HTML、XML。尤其是XML已經(jīng)成為了下一代語言的模型。
為什么像HTML、XML這種具有“開口”和“封口”的語言   有更高的容錯性、可調(diào)試性呢？這要取決于它的“吝嗇”性。“開口”和“封口”可以把故障的范圍最小化，使出現(xiàn)問題的部分盡量不影響其它部分。比如說：在HTML的<table>中，少寫一個<TR>多寫一個<TR>均不會對表格中其它行造成太大的影響。
與   這種“吝嗇”的語法相反的是“貪婪”性的語法。什么是“貪婪”性呢？這個問題也不太好解釋。不過，這種特性與正則表達(dá)式的解析十分十分地一致。“吝嗇性”的正則表達(dá)式   用做   精確匹配Group時有著較高的性能，而“貪婪性”的正則表達(dá)式用于判斷IsMatch時有著較高的性能。像C類的所有封口均使用大括號的語言，就屬于這種“貪婪性”性的語言。過多相同的封口使得代碼更加地難于控制。

許多人抱怨微軟，為什么不給C#加上動態(tài)編譯、加上自動完成……，實際上，微軟何嘗不想加啊，但由于C#的語法特性，是根本無法實現(xiàn)的。

下面就用實例來說明為什么C#無法實現(xiàn)動態(tài)編譯：

看下面的C#代碼段，代碼中的大括號是不平衡的：
class   A   {
        class   B   {
                class   C
                {
                        int   F1()
                        {
                                return   1;
                        }
                        int   F2()
                        {
                                return   2;
                        }
                }
}
假如現(xiàn)在已經(jīng)有了C#的動態(tài)編譯器，現(xiàn)在   要求編譯器指明   到底是哪里丟失了大括號！這時，編譯器就糊涂了：因為   不論是把大括號加在F1的末尾   還是加在class   A的末尾   都是行得通的，雖然這兩種情況的意義是完全不同的，即：不能判斷F1到底是Class   C的方法，還是Class   B的方法。那么連帶下一步，在代碼的其它部分就更無法判斷調(diào)用F1的代碼的合理性了。

這里只是舉了一個簡單的例子，實際的情況比這個更復(fù)雜。我們可以看到，在C語言的代碼沒有完全正確地書寫之前，它的結(jié)構(gòu)是有可能極度混亂、多意性的，在這種極度混亂的環(huán)境下   是無法判斷故障之所在、無法正確識別對象的結(jié)構(gòu)的。自然，這樣的動態(tài)編譯器也就成了“累贅”。

相比之下，同樣的內(nèi)容   看看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，故障范圍都不會擴(kuò)大，定位就可以做到精準(zhǔn)。檢錯如此，自動完成代碼也是如此。在C#環(huán)境下，由于代碼結(jié)構(gòu)可能存在著“多意性”，所以IDE有可能無法決定做處理的確切位置。

當(dāng)然，C類的代碼并不是沒有優(yōu)點，其優(yōu)點主要有二：
1.節(jié)省代碼所占的磁盤和內(nèi)存空間
2.使編譯器的體積能夠做得更小（最終還是為了節(jié)省磁盤空間）
只有在   內(nèi)存和磁盤空間非常珍貴的過去的年代里，C類語言代碼才能夠更具優(yōu)勢。
然而在內(nèi)存和磁盤如此豐富的今天，這種優(yōu)勢已經(jīng)成了劣勢。

借助于這種具有確定的“開口”與“封口”的特性，相信VB.net會走得更遠(yuǎn)。
三、語言的靈活性、適應(yīng)性的對比
C#的代碼，可以“隨便書寫”：在一行里可以寫多條語句，一條語句可以分成多行來寫。這使得它的代碼有可能更加地“松散”。雖然C#允許您把代碼寫得非常地松散，不過在實際的使用中，幾乎所有的使用者都默默地走向了VB的代碼風(fēng)格（一行一條語句）。最后，它的分號成了累贅。

雖然C#的代碼更加地自由，不過C#的思想比起VB.net起來卻是更加地死板。
在這方面，我覺得把C#比做手動檔汽車、把VB.net比做自動檔汽車是比較合適的。自動檔汽車也可以用手動檔的方式駕駛。C#的思想、思路在VB.net中均可實現(xiàn)，而VB.net的思想（自動檔）卻經(jīng)常無法在C#上實現(xiàn)。下面舉例說明：

例一：事件模型
在C#中，事件模型是固定的，構(gòu)造一個事件模型通常需要下面的思路：
建立事件代理結(jié)構(gòu)、聲明事件、建立事件處理方法、添加事件句柄、判斷事件代理是否掛到上實例、通過代理方法引發(fā)事件。在VB.net中，即可以按照C#所用的模式建立事件，也可以用VB.net自身所帶的RaiseEvent方法實現(xiàn)。雖然他們編譯后的結(jié)構(gòu)幾乎是一樣的，但畢竟VB.net讓我們有了更多的選擇，何樂而不為呢？下面就看看VB.net引發(fā)事件的兩種方法示例： 
方法一：用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在這方面占盡了優(yōu)勢。

例二：可選參數(shù)結(jié)構(gòu)
如下代碼展示了VB特有的結(jié)構(gòu)：可選參數(shù)
Public   Sub   XXX(P1   As   Integer,Optional   P2   As   String,Optional   P3   As   String)
‘…
End   Sub
這樣的結(jié)構(gòu)在C#中是無法實現(xiàn)的，但可以通過“重載”的方式實現(xiàn)相同的效果：
void   XXX(int   P1){}
void   XXX(int   P1,string   P2){}
void   XXX(int   P1,string   P2,string   P3{}
當(dāng)然，用VB.net也可以用重載方式寫出一模一樣的結(jié)構(gòu)。

例三：事件代理的掛接
C#中：只有一種方法：XXX.XXX   +=   new   XXX(…);
VB.net中：即可以效仿C#的方法：AddHandler(XXX.xxx,AddressOf   XXX)
也可以把過程顯示地指定給某個事件：Sub(…)   Handles   XXX.XXX

利用上面的第二種方法的特性，可以實現(xiàn)在VB.net代碼編輯頁中   簡單地通過下拉框   來精確地定位某個對象的特定事件的處理過程。
遺憾的是，這種方便的特性在C#中是無法實現(xiàn)的。因為C#的語法:XXX.XXX   +=的后面可以是任何方法返回的具有相同簽名的實例。比如通過屬性、方法，甚至是隨機(jī)判斷后返回的。這種“過份的自由”使得C#編譯器在運行代碼前不能準(zhǔn)確地確定該對象事件的處理部位。類似的例子太多了，舉不勝舉。

總之，VB.net給了我們更大的活動空間，它允許我們在“更快的速度”和“更嚴(yán)格性能要求”之間自由選擇。

四、代碼書寫上的比較
一、變量的命名的區(qū)別
C#是區(qū)分變量的大小寫的，這一點著實讓人摸不著門。也許這僅僅是為了效仿Java?
在公共語言規(guī)范中(CLS)，明確規(guī)定“變量不區(qū)分大小寫”的，真是難為了C#編譯器，還要把“重名”的變量重新命名。
相比之下，VB.net更加符合CLS，而且因為不區(qū)分大小寫，編輯器就更輕松地實現(xiàn)了“自動更正”功能。
C#絕對是“嫁錯了人”。
C要區(qū)分大小寫，其原因有二：一是為了能使用更多的變量資源，二是為了節(jié)省編譯器的開銷（性能和體積上都節(jié)省）。
如今，.net環(huán)境允許我們使用多達(dá)1024個長度的變量名，而且已完全面向?qū)ο蠡嗤淖兞靠梢酝瑫r出現(xiàn)在任何object中，所以可用的變量資源數(shù)量   理論上已經(jīng)達(dá)到了無窮多個！在這樣的條件下，“區(qū)分大小寫”使代碼在   可讀性、可調(diào)試性、可輔助性上都造成了不小的負(fù)面影響！它已經(jīng)成為了語言發(fā)展的障礙！

二、代碼的書寫
幾乎絕大多數(shù)的C#程序員都覺得他們在代碼的書寫上有著無與倫比的優(yōu)越性，因為C#代碼看上去是如此的簡潔。是的，如果我們僅使用記事本來開發(fā).net應(yīng)用程序，我相信像VB、Delphi早就滅絕了。但更糟糕的是：如果我們僅能使用記事本寫代碼，那么程序員也早就集體自殺了。說多少也不會有人相信，尤其是C#程序員不會相信   在代碼書寫方面   他們會完敗于VB.net程序員。我們完全可以用“鍵盤鉤子”做個小程序來檢測、驗證一下到底是哪種代碼更浪費鍵盤、書寫起來更吃力。

測試結(jié)果很明顯：VB.net代碼需要按鍵的次數(shù)更少、書寫更為容易。原因是IDE在其中起到了極大的作用！
VB.net不必像C#那樣不停地用Ctrl+shift+B來編譯檢錯；不必不停地按下Shift鍵來輸入星羅棋布的符號；不必不停地使用Ctrl+]徘徊于大括號之間；更不必手動輸入眾多的“關(guān)閉符”。（試一試：輸入If   A=B   [回車]，這時   Then和End   IF馬上就都給你準(zhǔn)備好了）(再試一試：在一個剛剛建立的新Class中，輸入Inherits后   回車，所有需要實現(xiàn)的方法都給你準(zhǔn)備好了)

究其本質(zhì)，是由于VB.net的語言起到了決定性的作用。
正是因為我們已經(jīng)告訴了編輯器“這是一個ReadOnly   Property”，所以編輯器會給我們自動提供了Get結(jié)構(gòu)代碼；正是因為我們已經(jīng)告訴了編輯器“這是一個WithEvents的對象”，所以編輯器會在對象事件選擇列表里加入它；正是因為我們已經(jīng)告訴了編輯器“這是一個Event”，所以當(dāng)我們要RaiseEvent時，它會準(zhǔn)確地出現(xiàn)在列表中；正是因為我們已經(jīng)告訴了編輯器“這是一個Function”，所以當(dāng)我們寫上調(diào)用方法后，它會自動地在后面加上括號；……反觀C#，由于代碼過度地萎縮，許多事情還需要通過分析整段代碼的結(jié)構(gòu)來決定它的屬性，導(dǎo)致這些“智能的操作”無法在C#上實現(xiàn)。

五、總結(jié)
由于C#語言是基于符號的語言，這就決定了它的可擴(kuò)展性比較弱(所有的符號都讓C#給用過了，如果再擴(kuò)展，還能用什么呢？像C++那樣，把-->和::這種組合符號也搬上來嗎？)
相反，VB.net會有更多的特性、更大的潛力有待于發(fā)揮。

用馬克思的理論來衡量這兩種語言：具有發(fā)展前途的事物   稱之為“新事物”。而VB.net正是這種“新事物”。

現(xiàn)在看C#語言：說方便性，比VB.net差；論性能，比C++差；談跨平臺通用性，比Java差
C#實際上是一種過度性的、雞肋的計算機(jī)語言。

從C++到C#，更多的體會是：委曲求全從VB到VB.net，更多的體會是：如魚得水！

我們應(yīng)該感謝比爾•蓋茨   發(fā)明的Basic語言，更應(yīng)該感謝微軟，把VB.net的能力發(fā)揮得如此透徹！相信大家讀完了這篇文章，會更深刻地了解   為什么VB.net比C#會貴上1000塊錢。

如果說C#是微軟的一個佳作，那么VB.net就是微軟的精品！