選擇VB.NET還是C#

2024-07-10 13:07:29

字體：大中小

來源：轉載

供稿：網(wǎng)友

關于vb.net又怎么樣呢？

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

vb.net有內置的（插入特點）支持；而c#沒有

“vb.net內置了很多東西像字符串操作(mid, instr, 等等)和類型轉換（例如cint）。c#缺乏這些內置的支持，所以，我所需要的東西，在c#中很難找到。

如果你抓住這些你應該mid 或者 cint功能不放，而最終認為這就是vb.net強于c#的證據(jù)，你最好去看看microsoft.visualbasic namespace。你將在那里發(fā)現(xiàn)大部分vb.net內部命令和應用功能。這些功能在namespace中被保存之后，任何cls兼容的語言都能使用他們，就像列表a中所顯示的那樣。這些例子削弱了我們的爭論，不是嗎？

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

“vb.net與com實體的捆綁支持更好一些。”我也只是看到了一點點而已，并且我決定再也不在支持方面作任何推理。從我迄今為止所觀察到的，這不是真的。c#和vb.net必須采用runtime callable的包裝以及等量的源代碼來執(zhí)行一個早期的實體。同樣地，執(zhí)行一個晚期的實體也需要相同數(shù)量的代碼。

vb.net使用ide中的后臺編譯

如果你不能找到其他的認為vb的開發(fā)環(huán)境好的例子，你至少不得不承認它的源代碼編輯是很有特點的。你能一邊打字一邊字面上排除你的代碼的錯誤。麻煩就是那些很弱智的編譯錯誤信息框總是彈出來，并且如果你把你的喇叭聲音開得過大的話，報錯的嘀嘀聲也許會嚇到你。

visual studio.net避免了這種驚嚇，直到你修改完成，并且處理了一些消極的錯誤，提示系統(tǒng)經(jīng)過了微軟的改進：他會在那些錯誤語句的下面打上彎彎曲曲的下劃線。

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

我要強調的是，那些有遠見的技術公司不再會去尋找具有某種開發(fā)語言經(jīng)驗的程序員，而是去尋找那些有.net類庫開發(fā)經(jīng)驗的程序員。因此我勸你不要過分的擔心自己的選擇到底是什么：隨便找一個你覺得有興趣學的語言，認真地學好他的框架結構就行了。

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

上一篇：堅持學asp.net——(十二)

下一篇：ASP.NET的WebFrom組件LinkButton編程