百萬程式設計師的苦惱－選擇VB.NET還是C# (轉)

百萬程式設計師的苦惱－選擇VB.NET還是C# (轉)[@more@]在過去的一年中，網際網路上的各大討論區或者電子的討論列表都對的以及的各種優越性做了探討。這些討論圍繞的主要問題就是，我應該先學哪一個，VB.NET還是C#？

　　我寫這篇文章的目的就是想幫您解決這個問題。我並不是想動搖你傾向哪一種語言而是想解決一些大家在基本問題上的疑惑，以便大家能夠作出自己的決定，選擇一種自己覺得用起來最舒適的語言。我將盡量避免討論一些語法上的模稜兩可的話，就像“C#的括弧太多了，”“VB.NET句子太冗長，”或者“我討厭C#（或者VB.NET）因為它能（或者不能）區分大小寫。”之類的話。評論語法的好壞是你個人品味的問題。相反，我將著重討論一些我見到的關於這兩種語言的技術方面的討論。

　　在C#方面

　　作為微軟公司最新的一種語言，並且由於它又是語言的小翻版，C#引起了廣大的關注。

　　人們看上去喜歡一種語言僅僅取決於它是最新的，開發者們總是喜歡用最新的工具工作。其它的一些選擇使用C#的理由更為具體一些。

　　領導潮流的東西總是無懈可擊的

　　“如果我正準備學一門新的語言，我還是應該學C#。”這也許也是你經常聽到的言論。那些推理總是這樣進行的：“轉變到VB.NET變化已經非常大了，以至於它基本上就是一門是新的語言。如果我無論如何打算學習新語言，我想還是學C#吧，因為它是特別為.NET類的庫設計的。”

　　這也是我聽到過的關於這兩方面的最蒼白的爭論。你也可以同樣理直氣壯的說，如果我無論如何打算學習新語言,我想還是學VB.NET吧，畢竟它也是一門新的語言。另外，讓我們想想為什麼VB.NET從其先驅者那裡如此激烈地演變到現在的樣子：它為了適應.NET類的庫而被重新設計了。

　　對比管理過的和沒有管理過的程式碼

　　“C#允許我寫那些執行在CLS器控制之外的非管理程式碼，我可以直接訪問儲存器，並且使用指標。讓程式碼自由地執行，包括使用儲存器的管理，可以得到更高的效益。”這個觀點有3個問題需要考慮：首先，我們不應該在Beta版本的開發環境下討論問題。舉個例子：在.NET的Beta1和Beta2版本之間有顯著的管理程式碼執行速度的改善。第二，我們還不能把非管理程式碼比管理程式碼能獲取多少利益量化，並且是否值得為了這些好處冒險。可以去看看Eric Gunnerson在MSDN上的這篇文章。第三，儘管VB.NET不能建立非管理程式碼，它能透過System.Runtime.InteropServices 名字空間的使用，來訪問並工作於非管理儲存器。

　　C#有內建的編制器

　　“C#包括直接被嵌入成為的XML檔案編制器在內。如果我使用C#，我同時編寫了程式碼並編制了檔案。”使用過JavaDoc的人都知道，把你的檔案編制加到你的原始碼中是多麼的有用。原始碼和檔案編制可以同時，因此至少在理論上講，你的文件永遠都不會過時。不過，以我的來看，相對少數的Java開發者還是在使用JavaDoc。這樣，問題就變成“你將使用它嗎？”如果你的對這問題的解答是“是”，你有足夠的理由試試C#。
關於VB.NET又怎麼樣呢？

　　在很多真正的開發者看來，VB像玩具語言似的，從某種角度看，也確實是這樣的。迄今為止，VB遠比我們所知道的那兩三個弱點更多。不過VB.NET確實是和C#同樣強大的.NET開發語言。有些人說它更強大。

　　VB.NET有內建的（插入特點）支援；而C#沒有

　　“VB.NET內建了很多東西像字串操作(Mid, InStr, 等等)和型別轉換（例如CInt）。C#缺乏這些內建的支援，所以，我所需要的東西，在C#中很難找到。

　　如果你抓住這些你應該Mid 或者 CInt功能不放，而最終認為這就是VB.NET強於C#的證據，你最好去看看.VisualBasic namespace。你將在那裡發現大部分VB.NET內部命令和應用功能。這些功能在namespace中被儲存之後，任何CLS相容的語言都能使用他們，就像列表A中所顯示的那樣。這些例子削弱了我們的爭論，不是嗎？

　　更好捆綁的支援就是不支援

　　“VB.NET與COM實體的捆綁支援更好一些。”我也只是看到了一點點而已，並且我決定再也不在支援方面作任何推理。從我迄今為止所觀察到的，這不是真的。C#和VB.NET必須採用runtime callable的包裝以及等量的原始碼來一個早期的實體。同樣地，執行一個晚期的實體也需要相同數量的程式碼。

　　VB.NET使用中的後臺編譯

　　如果你不能找到其他的認為VB的開發環境好的例子，你至少不得不承認它的原始碼編輯是很有特點的。你能一邊打字一邊字面上排除你的程式碼的錯誤。麻煩就是那些很弱智的編譯錯誤資訊框總是彈出來，並且如果你把你的喇叭開得過大的話，報錯的嘀嘀聲也許會嚇到你。

　　.NET避免了這種驚嚇，直到你修改完成，並且處理了一些消極的錯誤，提示經過了微軟的改進：他會在那些錯誤語句的下面打上彎彎曲曲的下劃線。

　　VB.NET背景編譯程式/句法檢驗器非常複雜，而且很客氣地指出你的錯誤。從某些方面看，它能更準確地告訴你如何修改你原始碼中的錯誤。當C#有它自己的語法檢查器，並且可以查出括弧的匹配，計算圓括弧的多少，顯示丟失的分號，但是它還是不能像VB.NET那樣使用簡單。再繼續討論這兩種語言的優越性確實會讓我心煩的，不過微軟的話確實是一個真理，那就是所有的.NET語言都是平等建立的。那些主張C#優於VB.NET的人（反之亦然）和那些攀比工資的開發者們一樣錯了。

　　我要強調的是，那些有遠見的技術公司不再會去尋找具有某種開發語言經驗的程式設計師，而是去尋找那些有.NET類庫開發經驗的程式設計師。因此我勸你不要過分的擔心自己的選擇到底是什麼：隨便找一個你覺得有興趣學的語言，認真地學好他的結構就行了。

　　如果你最終認為我是錯的，並且市場也不要求你一定要選擇一種語言，那你就儘管嘲笑我吧。