VB.NET與C#語(yǔ)言之間的比較分析
在網(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)于C#與VB.net在功能、能力、面向?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)鍵字，都是“人的行為”，“人的稱謂”。
相信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ū)ο蟆北闶沁@個(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)椴徽撌前汛罄ㄌ?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è)人程序員的***！
很顯然，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è)凇案斓乃俣取焙汀案鼑?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ě)上有著***的優(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)更吃力。（這個(gè)程序我已經(jīng)寫(xiě)好，有興趣的可以到http://img.pcpop.com/upimg2/2005/5/15/491525800.jpg 來(lái)下載。注意：必須使用網(wǎng)絡(luò)快車(chē)下載，下載后把文件更改為exe的即可直接運(yùn)行。這個(gè)序使用VB.net + Framework1.0編寫(xiě)，必要的時(shí)候 需要你安裝.net框架。）
測(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)。
但這些動(dòng)詞并不能表明C#與VB.net之間具有什么差距！！！！
【編輯推薦】
