百万程式员的苦恼-选择vb.net还是c#_c#应用

2008-02-23 05:47:02来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

  在过去的一年中,互连网上的各大讨论区或电子邮件的讨论列表都对微软的VB.NET连同C#的各种优越性做了探讨。这些讨论围绕的主要问题就是,我应该先学哪一个,VB.NET还是C#?

  我写这篇文章的目的就是想帮您解决这个问题。我并不是想动摇您倾向哪一种语言而是想解决一些大家在基本问题上的疑惑,以便大家能够作出自己的决定,选择一种自己觉得用起来最舒适的语言。我将尽量避免讨论一些语法上的模棱两可的话,就像“C#的括弧太多了,”“VB.NET句子太冗长,”或“我讨厌C#(或VB.NET)因为他能(或不能)区分大小写。”之类的话。评论语法的好坏是您个人品味的问题。相反,我将着重讨论一些我见到的关于这两种语言的技术方面的讨论。

  在C#方面

  作为微软公司最新的一种语言,并且由于他又是Java语言的小翻版,C#引起了广大的关注。

  人们看上去喜欢一种语言仅仅取决于他是最新的,程式研发者们总是喜欢用最新的工具工作。其他的一些选择使用C#的理由更为具体一些。

  领导潮流的东西总是无懈可击的

  “假如我正准备学一门新的语言,我还是应该学C#。”这也许也是您经常听到的言论。那些推理总是这样进行的:“VB6转变到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#有内置的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类库研发经验的程式员。因此我劝您不要过分的担心自己的选择到底是什么:随便找一个您觉得有兴趣学的语言,认真地学好他的框架结构就行了。

  假如您最终认为我是错的,并且市场也不需要您一定要选择一种语言,那您就尽管嘲笑我吧。


标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇: 如何利用c#创建和调用dll _c#应用

下一篇: 基于c#的接口基础教程之一_c#教程