在網(wǎng)上經(jīng)常能看到一些評(píng)論和比較C#、VB.net優(yōu)劣的文章。其中絕大多數(shù)都認(rèn)為：VB.net就沒(méi)有它存在的必要，VB.net遲早要被C#取代。
確實(shí)，計(jì)算機(jī)語(yǔ)言不是很重要的，也許討論它有點(diǎn)無(wú)聊。所以還希望那些“心中無(wú)劍”、“架構(gòu)、思想至尚”的高手們口下留情。
關(guān)于VB.net與C#在功能、能力、面向?qū)ο蟮奶匦陨希瑢?shí)在是難分伯仲。這個(gè)已是不爭(zhēng)的事實(shí)。尤其是VS.net2005中，這兩種語(yǔ)言已經(jīng)達(dá)到了驚人地相似！
下面就通過(guò)三個(gè)大方面對(duì)這這兩種語(yǔ)言進(jìn)行比較：
一、語(yǔ)言的人性化區(qū)別
C#像傻男人，VB.net像聰明賢惠的女人
從代碼的風(fēng)格就可以看出。
例1. 聲明變量時(shí)：
C#: int iTest ; //很直接的語(yǔ)氣,類(lèi)似于:擦汗！拿毛巾
VB.net Dim iTest As Integer ‘很委婉的語(yǔ)氣,類(lèi)似于:小王,給我拿條毛巾,我用它擦汗~實(shí)現(xiàn)完全相同的功能，但有著很明顯的區(qū)別。哪個(gè)更人性化、更易懂呢？
例2.語(yǔ)言的關(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ī)器味道”的語(yǔ)言。
而VB.net的關(guān)鍵字，都是“人的行為”，“人的稱(chēng)謂”。
相信VB.net的語(yǔ)法更具親和力，更易于幫助我們理解面向?qū)ο蟮奶匦浴?/p>
二、語(yǔ)言的先進(jìn)性的對(duì)比
現(xiàn)在，計(jì)算機(jī)軟件工程越來(lái)越龐大，已經(jīng)遠(yuǎn)遠(yuǎn)不是10年前的幾十KB大小的級(jí)別了。這就對(duì)語(yǔ)言的可擴(kuò)展性、可輔助性提出了更高的要求。“面向?qū)ο?#8221;便是這個(gè)需求的一個(gè)產(chǎn)物。
從現(xiàn)有的語(yǔ)言來(lái)看，具有“標(biāo)識(shí)符”的標(biāo)識(shí)性語(yǔ)言具備更高的容錯(cuò)性、可調(diào)試性、可擴(kuò)展性。比如HTML、XML。尤其是XML已經(jīng)成為了下一代語(yǔ)言的模型。
為什么像HTML、XML這種具有“開(kāi)口”和“封口”的語(yǔ)言 有更高的容錯(cuò)性、可調(diào)試性呢？這要取決于它的“吝嗇”性。“開(kāi)口”和“封口”可以把故障的范圍最小化，使出現(xiàn)問(wèn)題的部分盡量不影響其它部分。比如說(shuō)：在HTML的<table>中，少寫(xiě)一個(gè)<TR>多寫(xiě)一個(gè)<TR>均不會(huì)對(duì)表格中其它行造成太大的影響。
與 這種“吝嗇”的語(yǔ)法相反的是“貪婪”性的語(yǔ)法。什么是“貪婪”性呢？這個(gè)問(wèn)題也不太好解釋。不過(guò)，這種特性與正則表達(dá)式的解析十分十分地一致。“吝嗇性”的正則表達(dá)式 用做 精確匹配Group時(shí)有著較高的性能，而“貪婪性”的正則表達(dá)式用于判斷IsMatch時(shí)有著較高的性能。像C類(lèi)的所有封口均使用大括號(hào)的語(yǔ)言，就屬于這種“貪婪性”性的語(yǔ)言。過(guò)多相同的封口使得代碼更加地難于控制。
許多人抱怨微軟，為什么不給C#加上動(dòng)態(tài)編譯、加上自動(dòng)完成……，實(shí)際上，微軟何嘗不想加啊，但由于C#的語(yǔ)法特性，是根本無(wú)法實(shí)現(xiàn)的。
下面就用實(shí)例來(lái)說(shuō)明為什么C#無(wú)法實(shí)現(xiàn)動(dòng)態(tài)編譯：
看下面的C#代碼段，代碼中的大括號(hào)是不平衡的：
class A {
class B {
class C
{
int F1()
{
return 1;
}
int F2()
{
return 2;
}
}
}
假如現(xiàn)在已經(jīng)有了C#的動(dòng)態(tài)編譯器，現(xiàn)在 要求編譯器指明 到底是哪里丟失了大括號(hào)！這時(shí)，編譯器就糊涂了：因?yàn)?nbsp; 不論是把大括號(hào)加在F1的末尾 還是加在class A的末尾 都是行得通的，雖然這兩種情況的意義是完全不同的，即：不能判斷F1到底是Class C的方法，還是Class B的方法。那么連帶下一步，在代碼的其它部分就更無(wú)法判斷調(diào)用F1的代碼的合理性了。
這里只是舉了一個(gè)簡(jiǎn)單的例子，實(shí)際的情況比這個(gè)更復(fù)雜。我們可以看到，在C語(yǔ)言的代碼沒(méi)有完全正確地書(shū)寫(xiě)之前，它的結(jié)構(gòu)是有可能極度混亂、多意性的，在這種極度混亂的環(huán)境下 是無(wú)法判斷故障之所在、無(wú)法正確識(shí)別對(duì)象的結(jié)構(gòu)的。自然，這樣的動(dòng)態(tài)編譯器也就成了“累贅”。
相比之下，同樣的內(nèi)容 看看VB語(yǔ)法：
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
無(wú)論你刪除End Class還是刪除End function，故障范圍都不會(huì)擴(kuò)大，定位就可以做到精準(zhǔn)。檢錯(cuò)如此，自動(dòng)完成代碼也是如此。在C#環(huán)境下，由于代碼結(jié)構(gòu)可能存在著“多意性”，所以IDE有可能無(wú)法決定做處理的確切位置。
當(dāng)然，C類(lèi)的代碼并不是沒(méi)有優(yōu)點(diǎn)，其優(yōu)點(diǎn)主要有二：
1.節(jié)省代碼所占的磁盤(pán)和內(nèi)存空間
2.使編譯器的體積能夠做得更小（最終還是為了節(jié)省磁盤(pán)空間）
只有在 內(nèi)存和磁盤(pán)空間非常珍貴的過(guò)去的年代里，C類(lèi)語(yǔ)言代碼才能夠更具優(yōu)勢(shì)。
然而在內(nèi)存和磁盤(pán)如此豐富的今天，這種優(yōu)勢(shì)已經(jīng)成了劣勢(shì)。
借助于這種具有確定的“開(kāi)口”與“封口”的特性，相信VB.net會(huì)走得更遠(yuǎn)。
三、語(yǔ)言的靈活性、適應(yīng)性的對(duì)比
C#的代碼，可以“隨便書(shū)寫(xiě)”：在一行里可以寫(xiě)多條語(yǔ)句，一條語(yǔ)句可以分成多行來(lái)寫(xiě)。這使得它的代碼有可能更加地“松散”。雖然C#允許您把代碼寫(xiě)得非常地松散，不過(guò)在實(shí)際的使用中，幾乎所有的使用者都默默地走向了VB的代碼風(fēng)格（一行一條語(yǔ)句）。最后，它的分號(hào)成了累贅。
雖然C#的代碼更加地自由，不過(guò)C#的思想比起VB.net起來(lái)卻是更加地死板。
在這方面，我覺(jué)得把C#比做手動(dòng)檔汽車(chē)、把VB.net比做自動(dòng)檔汽車(chē)是比較合適的。自動(dòng)檔汽車(chē)也可以用手動(dòng)檔的方式駕駛。C#的思想、思路在VB.net中均可實(shí)現(xiàn)，而VB.net的思想（自動(dòng)檔）卻經(jīng)常無(wú)法在C#上實(shí)現(xiàn)。下面舉例說(shuō)明：
例一：事件模型
在C#中，事件模型是固定的，構(gòu)造一個(gè)事件模型通常需要下面的思路：
建立事件代理結(jié)構(gòu)、聲明事件、建立事件處理方法、添加事件句柄、判斷事件代理是否掛到上實(shí)例、通過(guò)代理方法引發(fā)事件。在VB.net中，即可以按照C#所用的模式建立事件，也可以用VB.net自身所帶的RaiseEvent方法實(shí)現(xiàn)。雖然他們編譯后的結(jié)構(gòu)幾乎是一樣的，但畢竟VB.net讓我們有了更多的選擇，何樂(lè)而不為呢？下面就看看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
“用盡量少的代碼 做出更多的事情”是每個(gè)人程序員的最?lèi)?ài)！
很顯然，VB.net在這方面占盡了優(yōu)勢(shì)。
例二：可選參數(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#中是無(wú)法實(shí)現(xiàn)的，但可以通過(guò)“重載”的方式實(shí)現(xiàn)相同的效果：
void XXX(int P1){}
void XXX(int P1,string P2){}
void XXX(int P1,string P2,string P3{}
當(dāng)然，用VB.net也可以用重載方式寫(xiě)出一模一樣的結(jié)構(gòu)。
例三：事件代理的掛接
C#中：只有一種方法：XXX.XXX += new XXX(…);
VB.net中：即可以效仿C#的方法：AddHandler(XXX.xxx,AddressOf XXX)
也可以把過(guò)程顯示地指定給某個(gè)事件：Sub(…) Handles XXX.XXX
利用上面的第二種方法的特性，可以實(shí)現(xiàn)在VB.net代碼編輯頁(yè)中 簡(jiǎn)單地通過(guò)下拉框 來(lái)精確地定位某個(gè)對(duì)象的特定事件的處理過(guò)程。
遺憾的是，這種方便的特性在C#中是無(wú)法實(shí)現(xiàn)的。因?yàn)镃#的語(yǔ)法:XXX.XXX +=的后面可以是任何方法返回的具有相同簽名的實(shí)例。比如通過(guò)屬性、方法，甚至是隨機(jī)判斷后返回的。這種“過(guò)份的自由”使得C#編譯器在運(yùn)行代碼前不能準(zhǔn)確地確定該對(duì)象事件的處理部位。類(lèi)似的例子太多了，舉不勝舉。
總之，VB.net給了我們更大的活動(dòng)空間，它允許我們?cè)?#8220;更快的速度”和“更嚴(yán)格性能要求”之間自由選擇。
四、代碼書(shū)寫(xiě)上的比較
一、變量的命名的區(qū)別
C#是區(qū)分變量的大小寫(xiě)的，這一點(diǎn)著實(shí)讓人摸不著門(mén)。也許這僅僅是為了效仿Java?
在公共語(yǔ)言規(guī)范中(CLS)，明確規(guī)定“變量不區(qū)分大小寫(xiě)”的，真是難為了C#編譯器，還要把“重名”的變量重新命名。
相比之下，VB.net更加符合CLS，而且因?yàn)椴粎^(qū)分大小寫(xiě)，編輯器就更輕松地實(shí)現(xiàn)了“自動(dòng)更正”功能。
C#絕對(duì)是“嫁錯(cuò)了人”。
C要區(qū)分大小寫(xiě)，其原因有二：一是為了能使用更多的變量資源，二是為了節(jié)省編譯器的開(kāi)銷(xiāo)（性能和體積上都節(jié)省）。
如今，.net環(huán)境允許我們使用多達(dá)1024個(gè)長(zhǎng)度的變量名，而且已完全面向?qū)ο蠡嗤淖兞靠梢酝瑫r(shí)出現(xiàn)在任何object中，所以可用的變量資源數(shù)量 理論上已經(jīng)達(dá)到了無(wú)窮多個(gè)！在這樣的條件下，“區(qū)分大小寫(xiě)”使代碼在 可讀性、可調(diào)試性、可輔助性上都造成了不小的負(fù)面影響！它已經(jīng)成為了語(yǔ)言發(fā)展的障礙！
二、代碼的書(shū)寫(xiě)
幾乎絕大多數(shù)的C#程序員都覺(jué)得他們?cè)诖a的書(shū)寫(xiě)上有著無(wú)與倫比的優(yōu)越性，因?yàn)镃#代碼看上去是如此的簡(jiǎn)潔。是的，如果我們僅使用記事本來(lái)開(kāi)發(fā).net應(yīng)用程序，我相信像VB、Delphi早就滅絕了。但更糟糕的是：如果我們僅能使用記事本寫(xiě)代碼，那么程序員也早就集體自殺了。說(shuō)多少也不會(huì)有人相信，尤其是C#程序員不會(huì)相信 在代碼書(shū)寫(xiě)方面 他們會(huì)完敗于VB.net程序員。我們完全可以用“鍵盤(pán)鉤子”做個(gè)小程序來(lái)檢測(cè)、驗(yàn)證一下到底是哪種代碼更浪費(fèi)鍵盤(pán)、書(shū)寫(xiě)起來(lái)更吃力。
測(cè)試結(jié)果很明顯：VB.net代碼需要按鍵的次數(shù)更少、書(shū)寫(xiě)更為容易。原因是IDE在其中起到了極大的作用！
VB.net不必像C#那樣不停地用Ctrl+shift+B來(lái)編譯檢錯(cuò)；不必不停地按下Shift鍵來(lái)輸入星羅棋布的符號(hào)；不必不停地使用Ctrl+]徘徊于大括號(hào)之間；更不必手動(dòng)輸入眾多的“關(guān)閉符”。（試一試：輸入If A=B [回車(chē)]，這時(shí) Then和End IF馬上就都給你準(zhǔn)備好了）(再試一試：在一個(gè)剛剛建立的新Class中，輸入Inherits后 回車(chē)，所有需要實(shí)現(xiàn)的方法都給你準(zhǔn)備好了)
究其本質(zhì)，是由于VB.net的語(yǔ)言起到了決定性的作用。
正是因?yàn)槲覀円呀?jīng)告訴了編輯器“這是一個(gè)ReadOnly Property”，所以編輯器會(huì)給我們自動(dòng)提供了Get結(jié)構(gòu)代碼；正是因?yàn)槲覀円呀?jīng)告訴了編輯器“這是一個(gè)WithEvents的對(duì)象”，所以編輯器會(huì)在對(duì)象事件選擇列表里加入它；正是因?yàn)槲覀円呀?jīng)告訴了編輯器“這是一個(gè)Event”，所以當(dāng)我們要RaiseEvent時(shí)，它會(huì)準(zhǔn)確地出現(xiàn)在列表中；正是因?yàn)槲覀円呀?jīng)告訴了編輯器“這是一個(gè)Function”，所以當(dāng)我們寫(xiě)上調(diào)用方法后，它會(huì)自動(dòng)地在后面加上括號(hào)；……反觀C#，由于代碼過(guò)度地萎縮，許多事情還需要通過(guò)分析整段代碼的結(jié)構(gòu)來(lái)決定它的屬性，導(dǎo)致這些“智能的操作”無(wú)法在C#上實(shí)現(xiàn)。
五、總結(jié)
由于C#語(yǔ)言是基于符號(hào)的語(yǔ)言，這就決定了它的可擴(kuò)展性比較弱(所有的符號(hào)都讓C#給用過(guò)了，如果再擴(kuò)展，還能用什么呢？像C++那樣，把-->和::這種組合符號(hào)也搬上來(lái)嗎？)
相反，VB.net會(huì)有更多的特性、更大的潛力有待于發(fā)揮。
用馬克思的理論來(lái)衡量這兩種語(yǔ)言：具有發(fā)展前途的事物 稱(chēng)之為“新事物”。而VB.net正是這種“新事物”。
現(xiàn)在看C#語(yǔ)言：說(shuō)方便性，比VB.net差；論性能，比C++差；談跨平臺(tái)通用性，比Java差
C#實(shí)際上是一種過(guò)度性的、雞肋的計(jì)算機(jī)語(yǔ)言。
從C++到C#，更多的體會(huì)是：委曲求全從VB到VB.net，更多的體會(huì)是：如魚(yú)得水！
我們應(yīng)該感謝比爾•蓋茨 發(fā)明的Basic語(yǔ)言，更應(yīng)該感謝微軟，把VB.net的能力發(fā)揮得如此透徹！相信大家讀完了這篇文章，會(huì)更深刻地了解 為什么VB.net比C#會(huì)貴上1000塊錢(qián)。
如果說(shuō)C#是微軟的一個(gè)佳作，那么VB.net就是微軟的精品！