在网上经常能看到 一些评论和比较C#、VB.net优劣的文章。其中绝大多数都认为:VB.net就没有它存在的必要,VB.net迟早要被C#取代。
确实,计算机语言不是很重要的,也许讨论它有点无聊。所以还希望那些“心中无剑”、“架构、思想至尚”的高手们口下留情。
关于VB.net与C#在功能、能力、面向对象的特性上,实在是难分伯仲。这个已是不争的事实。尤其是VS.net2005中,这两种语言已经达到了惊人地相似!
下面就通过三个大方面对这这两种语言进行比较:
一、语言的人性化区别
C#像傻男人,VB.net像聪明贤惠的女人
从代码的风格就可以看出。
例1. 声明变量时:
C#: int iTest ; //很直接的语气,类似于:擦汗!拿毛巾
VB.net Dim iTest As Integer ‘很委婉的语气,类似于:小王,给我拿条毛巾,我用它擦汗~
实现完全相同的功能,但有着很明显的区别。哪个更人性化、更易懂呢?
例2.语言的关键字上:
C#关键字:
using、this、void、base、abstract、sealed、virtual、switch、internal、static
相应的VB.net关键字:
Imports、Me、Sub、MyBase、MustInherit、NotOverridable、MustOverride、Select 、Friend、Shared
比较一下,C#的关键字比较冰冷,是具有一定“机器味道”的语言。
而VB.net的关键字,都是“人的行为”,“人的称谓”。
相信VB.net的语法更具亲和力,更易于帮助我们理解面向对象的特性。
二、语言的先进性的对比
现在,计算机软件工程越来越庞大,已经远远不是10年前的几十KB大小的级别了。这就对语言的可扩展性、可辅助性提出了更高的要求。“面向对象”便是这个需求的一个产物。
从现有的语言来看,具有“标识符”的标识性语言具备更高的容错性、可调试性、可扩展性。比如HTML、XML。尤其是XML已经成为了下一代语言的模型。
为什么像HTML、XML这种具有“开口”和“封口”的语言 有更高的容错性、可调试性呢?这要取决于它的“吝啬”性。“开口”和“封口”可以把故障的范围最小化,使出现问题的部分尽量不影响其它部分。比如说:在HTML的<table>中,少写一个<TR>多写一个<TR>均不会对表格中其它行造成太大的影响。
与 这种“吝啬”的语法相反的是“贪婪”性的语法。什么是“贪婪”性呢?这个问题也不太好解释。不过,这种特性与正则表达式的解析十分十分地一致。“吝啬性”的正则表达式 用做 精确匹配Group时有着较高的性能,而“贪婪性”的正则表达式用于判断IsMatch时有着较高的性能。
像C类的所有封口均使用大括号的语言,就属于这种“贪婪性”性的语言。过多相同的封口使得代码更加地难于控制。
许多人抱怨微软,为什么不给C#加上动态编译、加上自动完成……,实际上,微软何尝不想加啊,但由于C#的语法特性,是根本无法实现的。下面就用实例来说明为什么C#无法实现动态编译:
看下面的C#代码段,代码中的大括号是不平衡的:
class A {
class B {
class C
{
int F1()
{
return 1;
}
int F2()
{
return 2;
}
}
}
假如现在已经有了C#的动态编译器,现在要求编译器指明到底是哪里丢失了大括号!
这时,编译器就糊涂了:因为 不论是把大括号加在F1的末尾 还是加在class A的末尾 都是行得通的,虽然这两种情况的意义是完全不同的,即:不能判断F1到底是Class C的方法,还是Class B的方法。那么连带下一步,在代码的其它部分 就更无法判断 调用F1的代码的合理性了。
这里只是举了一个简单的例子,实际的情况比这个更复杂。我们可以看到,在C语言的代码没有完全正确地书写之前,它的结构是有可能极度混乱、多意性的,在这种极度混乱的环境下 是无法判断故障之所在、无法正确识别对象的结构的。自然,这样的动态编译器也就成了“累赘”。
相比之下,同样的内容 看看VB语法:
Class A
Class B
Class C
Function X1() As Integer
Return 1
End Function
End Class
Function X2() As Integer
Return 2
End Function
End Class
End Class
无论你删除End Class还是删除End function,故障范围都不会扩大,定位就可以做到精准。
检错如此,自动完成代码也是如此。在C#环境下,由于代码结构可能存在着“多意性”,所以IDE有可能无法决定做处理的确切位置。
当然,C类的代码并不是没有优点,其优点主要有二:
1.节省代码所占的磁盘和内存空间
2.使编译器的体积能够做得更小(最终还是为了节省磁盘空间)
只有在 内存和磁盘空间非常珍贵的过去的年代里,C类语言代码才能够更具优势。
然而在内存和磁盘如此丰富的今天,这种优势已经成了劣势。
借助于这种具有确定的“开口”与“封口”的特性,相信VB.net会走得更远。
三、语言的灵活性、适应性的对比
C#的代码,可以“随便书写”:在一行里可以写多条语句,一条语句可以分成多行来写。这使得它的代码有可能更加地“松散”。虽然C#允许您把代码写得非常地松散,不过在实际的使用中,几乎所有的使用者都默默地走向了VB的代码风格(一行一条语句)。最后,它的分号成了累赘。
虽然C#的代码更加地自由,不过C#的思想比起VB.net起来却是更加地死板。
在这方面,我觉得把C#比做手动档汽车、把VB.net比做自动档汽车是比较合适的。自动档汽车也可以用手动档的方式驾驶。
C#的思想、思路在VB.net中均可实现,而VB.net的思想(自动档)却经常无法在C#上实现。下面举例说明:
例一:事件模型
在C#中,事件模型是固定的,构造一个事件模型通常需要下面的思路:
建立事件代理结构、声明事件、建立事件处理方法、添加事件句柄、判断事件代理是否挂到上实例、通过代理方法引发事件。
在VB.net中,即可以按照C#所用的模式建立事件,也可以用VB.net自身所带的RaiseEvent方法实现。虽然他们编译后的结构几乎是一样的,但毕竟VB.net让我们有了更多的选择,何乐而不为呢?下面就看看VB.net引发事件的两种方法示例:
方法一:用RaiseEvent.
这是一种非常快捷、代码思路非常清晰的一种方法:
Class EventClass
Public Event E1(sender as Object,e as XXXEventHandler)
Sub XXXX()
RaiseEvent E1(Me,new XXXEventHandler(…)
End Sub
End Class
方法二:用C#的的思路
Public Delegate Sub xxxHandler(ByVal sender As Object, ByVal e As EventArgs)
Public Class A
Public Event XXX As xxxHandler
Public Overridable Sub OnXXXEvent(ByVal sender As Object, ByVal e As EventArgs)
If XXXEvent IsNot Nothing Then
XXXEvent.Invoke(sender, e)
End If
End Sub
Sub X()
OnXXXEvent(Me, New EventArgs)
End Sub
End Class
“用尽量少的代码 做出更多的事情”是每个人程序员的最爱!
很显然,VB.net在这方面占尽了优势。
例二:可选参数结构
如下代码展示了VB特有的结构:可选参数
Public Sub XXX(P1 As Integer,Optional P2 As String,Optional P3 As String)
‘…
End Sub
这样的结构在C#中是无法实现的,但可以通过“重载”的方式实现相同的效果:
void XXX(int P1){}
void XXX(int P1,string P2){}
void XXX(int P1,string P2,string P3{}
当然,用VB.net也可以用重载方式写出一模一样的结构。
例三:事件代理的挂接
C#中:只有一种方法:XXX.XXX += new XXX(…);
VB.net中:即可以效仿C#的方法:AddHandler(XXX.xxx,AddressOf XXX)
也可以把过程显示地指定给某个事件:Sub(…) Handles XXX.XXX
利用上面的第二种方法的特性,可以实现在VB.net代码编辑页中 简单地通过下拉框 来精确地定位某个对象的特定事件的处理过程。
遗憾的是,这种方便的特性在C#中是无法实现的。因为C#的语法:XXX.XXX +=的后面可以是任何方法返回的具有相同签名的实例。比如 通过属性、方法,甚至是随机判断后返回的。
这种“过份的自由”使得C#编译器在运行代码前不能准确地确定该对象事件的处理部位。
类似的例子太多了,举不胜举。
总之,VB.net给了我们更大的活动空间,它允许我们在“更快的速度”和“更严格性能要求”之间自由选择。
四、代码书写上的比较
一、变量的命名的区别
C#是区分变量的大小写的,这一点着实让人摸不着门。也许这仅仅是为了效仿Java?
在公共语言规范中(CLS),明确规定“变量不区分大小写”的,真是难为了C#编译器,还要把“重名”的变量重新命名。
相比之下,VB.net更加符合CLS,而且因为不区分大小写,编辑器就更轻松地实现了“自动更正”功能。
C#绝对是“嫁错了人”。
C要区分大小写,其原因有二:一是为了能使用更多的变量资源,二是为了节省编译器的开销(性能和体积上都节省)。
如今,.net环境允许我们使用多达1024个长度的变量名,而且已完全面向对象化,相同的变量可以同时出现在任何object中,所以可用的变量资源数量 理论上已经达到了无穷多个!
在这样的条件下,“区分大小写”使代码在 可读性、可调试性、可辅助性上都造成了不小的负面影响!它已经成为了语言发展的障碍!
二、代码的书写
几乎绝大多数的C#程序员都觉得他们在代码的书写上有着无与伦比的优越性,因为C#代码看上去是如此的简洁。
是的,如果我们仅使用记事本来开发.net应用程序,我相信像VB、Delphi早就灭绝了。
但更糟糕的是:如果我们仅能使用记事本写代码,那么程序员也早就集体自杀了。
说多少也不会有人相信,尤其是C#程序员不会相信 在代码书写方面 他们会完败于VB.net程序员。
我们完全可以用“键盘钩子”做个小程序来检测、验证一下到底是哪种代码更浪费键盘、书写起来更吃力。(这个程序我已经写好,有兴趣的可以到http://img.pcpop.com/upimg2/2005/5/15/491525800.jpg 来下载。注意:必须使用网络快车下载,下载后把文件更改为exe的即可直接运行。这个序使用VB.net + Framework1.0编写,必要的时候 需要你安装.net框架。)
测试结果很明显:VB.net代码需要按键的次数更少、书写更为容易。原因是IDE在其中起到了极大的作用!
VB.net不必像C#那样不停地用Ctrl+shift+B来编译检错;不必不停地按下Shift键来输入星罗棋布的符号;不必不停地使用Ctrl+]徘徊于大括号之间;更不必手动输入众多的“关闭符”。
(试一试:输入If A=B [回车],这时 Then和End IF马上就都给你准备好了)
(再试一试:在一个刚刚建立的新Class中,输入Inherits后 回车,所有需要实现的方法都给你准备好了)
究其本质,是由于VB.net的语言起到了决定性的作用。
正是因为我们已经告诉了编辑器“这是一个ReadOnly Property”,所以编辑器会给我们自动提供了Get结构代码;
正是因为我们已经告诉了编辑器“这是一个WithEvents的对象”,所以编辑器会在对象事件选择列表里加入它;
正是因为我们已经告诉了编辑器“这是一个Event”,所以当我们要RaiseEvent时,它会准确地出现在列表中;
正是因为我们已经告诉了编辑器“这是一个Function”,所以当我们写上调用方法后,它会自动地在后面加上括号;
……
反观C#,由于代码过度地萎缩,许多事情还需要通过分析整段代码的结构来决定它的属性,导致这些“智能的操作”无法在C#上实现。
但这些动词并不能表明VB.net和C#之间具有什么差距!!!!
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/panjun_websoftware/archive/2008/02/28/2129117.aspx
posted on 2011-03-09 13:47
张志松 阅读(5502)
评论(1) 编辑 收藏 引用 所属分类:
VB.NET