What the diffirence between C# and VB.net?

  • Thread starter Thread starter Simon Peng
  • Start date Start date
One is full of assumptions and bugs waiting to happen and the other other is
very anal/strict/less-bug-prone... :o)
 
I believe the syntax in VB.NET is "Default Property" as opposed to indexer,
but it's the same thing:
Default Property Item(ByVal index as Integer) As String
 
In a nutshell, I believe VB.NET to be for a) supporting legacy VB 6 users,
and b) for rapid-application development. In versions 2002-03 of VS, I
don't see many differences in RAD between VB.NET and C#, but I believe the
next versions of the IDE will reflect a bigger difference. (Microsoft says
vb is for task-based programming, while c# is for code-based programming,
whatever that means. I only write code to perform tasks!). What I think
it means is that while the C# team worked on generics, the vb.net team
brought back edit & continue, and added some really cool error-checking as
you code. (Almost like ms word's grammar & spelling check as you type). I
already think the VB.NET IDE is much better than the C# IDE, and it is
advancing further ahead.

In addition to operator overloading and the #region within a method body
(which I didn't realize to be a difference, nor do I think to be a very good
idea), here are some other differences:

1. C# by default supports XML comments (there are currently plugins for
VB.NET xml comments, and the next version will support it natively). This
is a huge plus for C# at the moment - especially when combined with ndoc.

2. VB.NET has a simpler syntax for some event handlers (especially useful
for GUIs) since they have the keyword "handles"
e.g.
MySub(Object sender, EventArgs e) Handles Button1.Clicked
blah blah
End Sub
no need for a line Button1.Clicked += new EventHandler(MySub)

3. VB.NET is a bit more verbose in other ways, using End Sub instead of
just } - note that the IDE generally provides the End Sub / End Fucntion /
End If automagically as soon as you start a block, so you probably type
about the same amount. Implementing properties in vb.net is really easy
with the ide - it adds the get/set methods as soon as you type the property
declartion.

4. Case sensitivity - VB.NET isn't case sensitive. This has it's advantages
and disadvantages. I like this for RAD because as I'm typing (all
lowercase) I can see it automatically recase to ProperPascalCase or
camelCase. If it doesn't recase, it means I misspelled something. I don't
like the case insensitivity because I like to use case to define scope. For
instance, a public property named Color may use a private variable color,
both of type Color. In VB.NET, you're forced to name the private variable
something else, like myColor or m_Color.

5. VB.NET has support for some "archaic" vb things that you probably
shouldn't be using in new code, but that might be useful for portability.
The terrible "On Error Resume" and such is still available in VB.NET. Also
ReDim Preserve for resizing arrays and preserving the contents (which just
copies the array contents to a new array, I believe, but the syntax *may* be
cleaner). VB.NET can also define arrays to have non 0 based indices, but
these are strongly discouraged. There's an entire dll of vb things (which
are also available in C# if you need them) specifically for legacy code.

6. VB.NET has an Option Strict On/Off which changes how typesafe the
compiler forces you to be. (C# is always quite typesafe)

7. VB.NET supports optional arguments on methods.

8. C# supports unsigned integer types (you can't add two unsigned ints in
VB.NET, for instance).

9. C# supports "unsafe" code, i.e. you can still use pointers if you need.
(really useful for image manipulation).

10. ; in C# - which is REALLY NICE. Otherwise, in VB.NET, you have to use
_ when a statement runs over the end of a line, which seems to make my VB
code have really long lines that go past the end of the screen and makes the
code much harder to read.

11. The VB.NET IDE is much nicer. Especially for intellisense, trying to
override base class methods, and adding event handlers. And the
error-reporting as you code is way ahead in VB.NET.

12. Possible difference in salary of a developer (historically C++ paid more
than VB, not sure where C# will fall in the spectrum).

13. Future differences: C# will support generics, don't think VB.NET will
(soon anyways)

Finally, and probably the most important of all: C# is more familiar for
anybody who has a C/C++/Java background. VB.NET is more familiar for
anybody who has a VB background. Pick the one that fits either your past
experience or future plans (do you want to be a Java/.NET developer, C# is
probably better. Do you come from a history of VB6 / COM programming?
VB.NET will probably be better). They both have access to the entire FCL
(Framework Class Library) so things like opening a file, reading its
contents, performing a regular expression replace on the contents, and
posting the results to a web page will be virtually identical between the
two languages.
 
Michael Mayer said:
13. Future differences: C# will support generics, don't think VB.NET will
(soon anyways)
Click to expand...

I believe it'll have it in the same release that C# does. From
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx#whidbey

<quote>
Finally, for the more advanced Visual Basic developer, language
enhancements include support for operator overloading, unsigned data
types, inline XML-based code documentation, and partial types. In
addition, developers using Visual Basic will have access to a type-
safe, high-performance, compile time-verified version of generics that
promote code reuse across a variety of data types.
</quote>
 
Jon Skeet said:
I believe it'll have it in the same release that C# does. From
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx#whidbey

<quote>
Finally, for the more advanced Visual Basic developer, language
enhancements include support for operator overloading, unsigned data
types, inline XML-based code documentation, and partial types. In
addition, developers using Visual Basic will have access to a type-
safe, high-performance, compile time-verified version of generics that
promote code reuse across a variety of data types.
</quote>
Click to expand...

Wow, that's outstanding. Didn't realize they were adding so much of that -
I even read that article, but I must have skipped that paragraph. I might
be tempted to go back to VB.NET (that was my first exposure to .NET before I
discovered C#). I would miss {}'s and ;'s since my "real" background is
C++.

Wonder if they'll have the new iterators as well? I didn't see that
mentioned in the article.

mike
 
Back
Top