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

        關于VB.net與C#在功能、能力、面向對象的特性上，實在是難分伯仲。這個已是不爭的事實。尤其是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.使編譯器的體積能夠做得更?。ㄗ罱K還是為了節省磁盤空間）
只有在   內存和磁盤空間非常珍貴的過去的年代里，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程序員。我們完全可以用“鍵盤鉤子”做個小程序來檢測、驗證一下到底是哪種代碼更浪費鍵盤、書寫起來更吃力。

測試結果很明顯：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#語言是基于符號的語言，這就決定了它的可擴展性比較弱(所有的符號都讓C#給用過了，如果再擴展，還能用什么呢？像C++那樣，把-->和::這種組合符號也搬上來嗎？)
相反，VB.net會有更多的特性、更大的潛力有待于發揮。

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

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

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

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

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