C#和VB.NET詳細(xì)比較
本文對(duì)C#和VB.NET的各種優(yōu)越性做了探討，包括VB.NET使用IDE中的后臺(tái)編譯、C#有內(nèi)置的XML文件編制器和對(duì)比管理過(guò)的和沒(méi)有管理過(guò)的代碼等方面。
在過(guò)去的一年中，互聯(lián)網(wǎng)上的各大討論區(qū)或者電子郵件的討論列表都對(duì)微軟的C#和VB.NET的各種優(yōu)越性做了探討。這些討論圍繞的主要問(wèn)題就是，我應(yīng)該先學(xué)哪一個(gè)，VB.NET還是C#？
我寫這篇文章的目的就是想幫您解決這個(gè)問(wèn)題。我并不是想動(dòng)搖你傾向哪一種語(yǔ)言而是想解決一些大家在基本問(wèn)題上的疑惑，以便大家能夠作出自己的決定，選擇一種自己覺(jué)得用起來(lái)最舒適的語(yǔ)言。我將盡量避免討論一些語(yǔ)法上的模棱兩可的話，就像“C#的括弧太多了，”“VB.NET句子太冗長(zhǎng)，”或者“我討厭C#（或者VB.NET）因?yàn)樗埽ɑ蛘卟荒埽﹨^(qū)分大小寫。”之類的話。評(píng)論語(yǔ)法的好壞是你個(gè)人品味的問(wèn)題。相反，我將著重討論一些我見到的關(guān)于這兩種語(yǔ)言的技術(shù)方面的討論。
在C#方面
作為微軟公司最新的一種語(yǔ)言，并且由于它又是Java語(yǔ)言的小翻版，C#引起了廣大的關(guān)注。
人們看上去喜歡一種語(yǔ)言僅僅取決于它是最新的，程序開發(fā)者們總是喜歡用最新的工具工作。其它的一些選擇使用C#的理由更為具體一些。
領(lǐng)導(dǎo)潮流的東西總是無(wú)懈可擊的
“如果我正準(zhǔn)備學(xué)一門新的語(yǔ)言，我還是應(yīng)該學(xué)C#。”這也許也是你經(jīng)常聽到的言論。那些推理總是這樣進(jìn)行的：“VB6轉(zhuǎn)變到VB.NET變化已經(jīng)非常大了，以至于它基本上就是一門是新的語(yǔ)言。如果我無(wú)論如何打算學(xué)習(xí)新語(yǔ)言，我想還是學(xué)C#吧，因?yàn)樗翘貏e為.NET類的庫(kù)設(shè)計(jì)的。”
這也是我聽到過(guò)的關(guān)于這兩方面的最蒼白的爭(zhēng)論。你也可以同樣理直氣壯的說(shuō)，如果我無(wú)論如何打算學(xué)習(xí)新語(yǔ)言,我想還是學(xué)VB.NET吧，畢竟它也是一門新的語(yǔ)言。另外，讓我們想想為什么VB.NET從其先驅(qū)者那里如此激烈地演變到現(xiàn)在的樣子：它為了適應(yīng).NET類的庫(kù)而被重新設(shè)計(jì)了。
對(duì)比管理過(guò)的和沒(méi)有管理過(guò)的代碼
“C#允許我寫那些運(yùn)行在CLS存儲(chǔ)器控制之外的非管理代碼，我可以直接訪問(wèn)存儲(chǔ)器，并且使用指針。讓代碼自由地運(yùn)行，包括使用存儲(chǔ)器的管理，可以得到更高的效益。”這個(gè)觀點(diǎn)有3個(gè)問(wèn)題需要考慮：首先，我們不應(yīng)該在Beta版本的開發(fā)環(huán)境下討論性能問(wèn)題。舉個(gè)例子：在.NET的Beta1和Beta2版本之間有顯著的管理代碼運(yùn)行速度的改善。第二，我們還不能把非管理代碼比管理代碼能獲取多少利益量化，并且是否值得為了這些好處冒險(xiǎn)。可以去看看Eric Gunnerson在MSDN上的這篇文章。第三，盡管VB.NET不能建立非管理代碼，它能通過(guò) System.Runtime.InteropServices 名字空間的使用，來(lái)訪問(wèn)并工作于非管理存儲(chǔ)器。
C#有內(nèi)置的XML文件編制器
“C#編譯器包括直接被嵌入成為源代碼的XML文件編制器在內(nèi)。如果我使用C#，我同時(shí)編寫了代碼并編制了文件。”使用過(guò)JavaDoc 的人都知道，把你的文件編制加到你的源代碼中是多么的有用。源代碼和文件編制可以同時(shí)更新，因此至少在理論上講，你的文檔永遠(yuǎn)都不會(huì)過(guò)時(shí)。不過(guò)，以我的經(jīng)驗(yàn)來(lái)看，相對(duì)少數(shù)的Java開發(fā)者還是在使用JavaDoc。這樣，問(wèn)題就變成“你將使用它嗎？”如果你的對(duì)這問(wèn)題的解答是“是”，你有足夠的理由試試C#。
關(guān)于VB.NET又怎么樣呢？
在很多真正的開發(fā)者看來(lái)，VB像玩具語(yǔ)言似的，從某種角度看，也確實(shí)是這樣的。迄今為止，VB遠(yuǎn)比我們所知道的那兩三個(gè)弱點(diǎn)更多。不過(guò)VB.NET確實(shí)是和C#同樣強(qiáng)大的.NET開發(fā)語(yǔ)言。有些人說(shuō)它更強(qiáng)大。
VB.NET有內(nèi)置的（插入特點(diǎn)）支持；而C#沒(méi)有
“VB.NET內(nèi)置了很多東西像字符串操作(Mid, InStr, 等等)和類型轉(zhuǎn)換（例如CInt）。C#缺乏這些內(nèi)置的支持，所以，我所需要的東西，在C#中很難找到。
如果你抓住這些你應(yīng)該Mid 或者 CInt功能不放，而最終認(rèn)為這就是VB.NET強(qiáng)于C#的證據(jù)，你最好去看看Microsoft.VisualBasic namespace。你將在那里發(fā)現(xiàn)大部分VB.NET內(nèi)部命令和應(yīng)用功能。這些功能在namespace中被保存之后，任何CLS兼容的語(yǔ)言都能使用他們，就像列表A中所顯示的那樣。這些例子削弱了我們的爭(zhēng)論，不是嗎？
更好捆綁的支持就是不支持
“VB.NET與COM實(shí)體的捆綁支持更好一些。”我也只是看到了一點(diǎn)點(diǎn)而已，并且我決定再也不在支持方面作任何推理。從我迄今為止所觀察到的，這不是真的。C#和VB.NET必須采用runtime callable的包裝以及等量的源代碼來(lái)執(zhí)行一個(gè)早期的實(shí)體。同樣地，執(zhí)行一個(gè)晚期的實(shí)體也需要相同數(shù)量的代碼。
VB.NET使用IDE中的后臺(tái)編譯
如果你不能找到其他的認(rèn)為VB的開發(fā)環(huán)境好的例子，你至少不得不承認(rèn)它的源代碼編輯是很有特點(diǎn)的。你能一邊打字一邊字面上排除你的代碼的錯(cuò)誤。麻煩就是那些很弱智的編譯錯(cuò)誤信息框總是彈出來(lái)，并且如果你把你的喇叭聲音開得過(guò)大的話，報(bào)錯(cuò)的嘀嘀聲也許會(huì)嚇到你。
Visual Studio.NET避免了這種驚嚇，直到你修改完成，并且處理了一些消極的錯(cuò)誤，提示系統(tǒng)經(jīng)過(guò)了微軟的改進(jìn)：他會(huì)在那些錯(cuò)誤語(yǔ)句的下面打上彎彎曲曲的下劃線。
VB.NET背景編譯程序/句法檢驗(yàn)器非常復(fù)雜，而且很客氣地指出你的錯(cuò)誤。從某些方面看，它能更準(zhǔn)確地告訴你如何修改你源代碼中的錯(cuò)誤。當(dāng)C#有它自己的語(yǔ)法檢查器，并且可以查出括弧的匹配，計(jì)算圓括弧的多少，顯示丟失的分號(hào)，但是它還是不能像VB.NET那樣使用簡(jiǎn)單。再繼續(xù)討論這兩種語(yǔ)言的優(yōu)越性確實(shí)會(huì)讓我心煩的，不過(guò)微軟的話確實(shí)是一個(gè)真理，那就是所有的.NET語(yǔ)言都是平等建立的。那些主張C#優(yōu)于VB.NET的人（反之亦然）和那些攀比工資的開發(fā)者們一樣錯(cuò)了。
我要強(qiáng)調(diào)的是，那些有遠(yuǎn)見的技術(shù)公司不再會(huì)去尋找具有某種開發(fā)語(yǔ)言經(jīng)驗(yàn)的程序員，而是去尋找那些有.NET類庫(kù)開發(fā)經(jīng)驗(yàn)的程序員。因此我勸你不要過(guò)分的擔(dān)心自己的選擇到底是什么：隨便找一個(gè)你覺(jué)得有興趣學(xué)的語(yǔ)言，認(rèn)真地學(xué)好他的框架結(jié)構(gòu)就行了。
如果你最終認(rèn)為我是錯(cuò)的，并且市場(chǎng)也不要求你一定要選擇一種語(yǔ)言，那你就盡管嘲笑我吧。
【編輯推薦】
