兩方面討論VB.NET C#區別
在過去的半年里，大家都在探討VB.NET 它和c#的區別，在這里我和大家簡單的談談關于VB.NET C#區別。
VB.NET C#區別：
對比管理過的和沒有管理過的代碼
“C#允許我寫那些運行在CLS存儲器控制之外的非管理代碼，我可以直接訪問存儲器，并且使用指針。讓代碼自由地運行，包括使用存儲器的管理，可以得到更高的效益。”這個觀點有3個問題需要考慮：首先，我們不應該在Beta版本的開發環境下討論性能問題。舉個例子：在.NET的Beta1和Beta2版本之間有顯著的管理代碼運行速度的改善。第二，我們還不能把非管理代碼比管理代碼能獲取多少利益量化，并且是否值得為了這些好處冒險。可以去看看Eric Gunnerson在MSDN上的這篇文章。第三，盡管VB.NET不能建立非管理代碼，它能通過System.Runtime.InteropServices 名字空間的使用，來訪問并工作于非管理存儲器。
C#有內置的XML文件編制器
“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#的證據，你最好去看看Microsoft.VisualBasic namespace。你將在那里發現大部分VB.NET內部命令和應用功能。這些功能在namespace中被保存之后，任何CLS兼容的語言都能使用他們，就像列表A中所顯示的那樣。這些例子削弱了我們的爭論，不是嗎？
更好捆綁的支持就是不支持
“VB.NET與COM實體的捆綁支持更好一些。”我也只是看到了一點點而已，并且我決定再也不在支持方面作任何推理。從我迄今為止所觀察到的，這不是真的。C#和VB.NET必須采用runtime callable的包裝以及等量的源代碼來執行一個早期的實體。同樣地，執行一個晚期的實體也需要相同數量的代碼。
VB.NET使用IDE中的后臺編譯
如果你不能找到其他的認為VB的開發環境好的例子，你至少不得不承認它的源代碼編輯是很有特點的。你能一邊打字一邊字面上排除你的代碼的錯誤。麻煩就是那些很弱智的編譯錯誤信息框總是彈出來，并且如果你把你的喇叭聲音開得過大的話，報錯的嘀嘀聲也許會嚇到你。Visual Studio.NET避免了這種驚嚇，直到你修改完成，并且處理了一些消極的錯誤，提示系統經過了微軟的改進：他會在那些錯誤語句的下面打上彎彎曲曲的下劃線。
VB.NET背景編譯程序/句法檢驗器非常復雜，而且很客氣地指出你的錯誤。從某些方面看，它能更準確地告訴你如何修改你源代碼中的錯誤。當C#有它自己的語法檢查器，并且可以查出括弧的匹配，計算圓括弧的多少，顯示丟失的分號，但是它還是不能像VB.NET那樣使用簡單。再繼續討論這兩種語言的優越性確實會讓我心煩的，不過微軟的話確實是一個真理，那就是所有的.NET語言都是平等建立的。那些主張C#優于VB.NET的人（反之亦然）和那些攀比工資的開發者們一樣錯了。
我要強調的是，那些有遠見的技術公司不再會去尋找具有某種開發語言經驗的程序員，而是去尋找那些有.NET類庫開發經驗的程序員。因此我勸你不要過分的擔心自己的選擇到底是什么：隨便找一個你覺得有興趣學的語言，認真地學好他的框架結構就行了，上邊就是簡單的分析VB.NET C#區別，希望大家選擇自己喜歡的語言。
【編輯推薦】
