C# vs VB

[Scott Coonce]

IsNumeric etc.

==========
You have many functions like IsNumeric, Mid etc. in VB.net which are
handy.
You have to write separate function in C# for using the above. Allright
you
people must be thinking that using these functions are not PURE (in terms
of
.Net) , these are very very handy.

If i'm not mistaken, these are implemented in something like
"Microsoft.VisualBasic.dll"-- a library that could be imported into _any_
..net project, including c#.

scott

 

[Kevin Spencer]

Taking into consoderation intellisense and auto title case, you will have

to
PRESS 17 KEYS

....

Um. This has nothing to do with the VB.Net language, but with the version of
Microsoft Visual Studio.Net that you happen to be using. You might want to
take a look at VS.Net 2005 and update your impression.

In fact, the syntax for C# is much more compact than VB.Net. So, it might be
said that, comparing apples to apples, you type less with C#.

IsNumeric etc.
==========
You have many functions like IsNumeric, Mid etc. in VB.net which are
handy.

This also has nothing to do with the VB.Net language. These functions are in
an assembly which can be used with either language. The VS.Net IDE simply
references it automatically when creating a VB.Net project, so that people
like yourself can use what they are familiar with, without having to know
anything about it, or understand where it comes from.

Optional Parameters
=============
VB.net supports optional parameters, but C# does not support them.
Although
people might argue that you can use overloaded functions instead, these is
one catch to it. Say for example the function a hundred lines of code and
the
optional parameter is just going to be used for checking in an if
condition
(most optional parameters are used for that). In C# you have to do this by
overloading the function and in that process paste the hundred lines of
code
again. What a waste... ?

Apparently, you haven't written overloaded functions before (even though
VB.Net allows you to), or simply don't know how to do it. Consider the
following:

public static int IndexOfEnd(string source, string searchString, int
startIndex)
{
int i = source.IndexOf(searchString, startIndex);
if (i < 0) return i;
return i + searchString.Length;
}

public static int IndexOfEnd(string source, string searchString)
{
return IndexOfEnd(source, searchString, 0);
}

Note that none of the code in the first definition is duplicated in the
second. The second simply calls the first, and passes a (default) third
parameter to it.

In fact, optional parameters are an illusion. The parameters are there; they
are simply given default values when they are not explicitly declared in the
method call. The above could be defined with optional parameters in VB:

Public Function IndexOfEnd(ByVal source As String, _
ByVal searchString As String, Optional ByVal startIndex As Integer = 0)
Dim i As Integer = source.IndexOf(searchString, startIndex)
If i < 0 Then Return i
Return i + searchString.Length
End Function

The VB function actually *always* takes 3 parameters. The compiler supplies
the third if the developer leaves it out.

As to the reasoning behind the decision not to support optional parameters
in C#, see the following article:

http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85556.aspx

There are some very sharp people who write in defense of VB.Net. It is a
fine .Net programming language. But this sort of argument only adds to the
widely-held impression held by many that VB is a bad language because it
fosters ignorance on the part of the developer, and leads to a large segment
of ignorant and unskilled VB developers.

Personally, I do believe that there are more VB hacks out there than C#
hacks. Until the current version of the .Net Framework and Visual
Studio.Net, this has been made possible by the lack of strictness in the
language, and Microsoft's accomodations to the VB programming community, to
make it easier for VB developers to transition to the .Net Framework. In
other words, it has been easier to write bad code in VB.Net than in C#, and
it's easier to write bad code than it is to write good code. Lazy people
tend to take the easiest path, test less, and worry about the consequences
later. This should not be taken as a sweeping generalization, or a criticism
of the language or the VB.Net community, but as a statistical theory, which
may be useful in the future development of the language.

However, in fact, there are many top-notch VB developers out there. They use
VB because they like the syntax, and either have no need for the extra
capabilities of C#, or use C# when they need to (which isn't often).
Personal preference and comfort is a perfectly valid reason for using any
language.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Rachel Suddeth]

Not sure if I saw this one addressed:

...
C#
==
SqlConnection mycon = new SqlConnection();

...
And the most irritating this is, you have to remember the object name
SqlConnection (consider this for other objects whose name you might not
remember)

Actually, as long as you remember the namespace SqlConnection is in, you can
get intellisense to give you a list of class names in that namespace, so you
don't really have to remember that. It is a bit of extra typing to put the
namespace first, but from my POV, typing a few extra chars just isn't an
issue. I spend a lot more of my programming time thinking than typing.

You know what? I think most of use like our "home" language best. I like C#
because it feels closer to the plain ol' K&R C I was raised on. I wouldn't
presume to know enough about VB to give empirical reasons to like one or the
other better. I just like the way it feels, and that's enough for me

 

[Scott Coonce]

I'm not sure if i'm adding or taking away fuel from the fire.

In both languages (i started in vb and switched to cs), I find typing the
property definitions a pain, whether its

Public Property SomeProp() As String
Get
Return _someProp
End Get
Set(ByVal Value As String)
_someProp = Value
End Set
End Property

or

public string SomeProp {
get { return _someProp; }
set { _someProp = value; }
}

both end up to be a lot of typing. and although i prefer c#, i still think
there's something fishy about the implicit variable 'value' in properties...

scott

 

[Jon Skeet [C# MVP]]

VB.net is best fit for the following reasons:

1) You have to type less. Consider the following statements to declare a
SqlConnection

LOL. How much of software development time is actually spent in typing,
would you say? Writing readable code is far more important. Do you
recommend always using single letter variable names and avoiding
writing comments, too?

IsNumeric etc.
==========
You have many functions like IsNumeric, Mid etc. in VB.net which are handy.

They're not object oriented, and I've had nasty experiences in terms of
their behaviour when it comes to different cultures (in particular
changing the culture of a thread doesn't affect *all* VB.NET functions,
even if some of them are affected by the culture of the thread which
*first* calls them. Very odd stuff).

You have to write separate function in C# for using the above.

Not for "Mid" you don't - what's wrong with Substring? (Admittedly
Substring throws an exception if you ask for data outside its range -
which I believe is almost always a better behaviour than silently
returning less data than you asked for.)

If you really want to use them from C# though, you can do so.

Optional Parameters
=============
VB.net supports optional parameters, but C# does not support them. Although
people might argue that you can use overloaded functions instead, these is
one catch to it. Say for example the function a hundred lines of code and the
optional parameter is just going to be used for checking in an if condition
(most optional parameters are used for that). In C# you have to do this by
overloading the function and in that process paste the hundred lines of code
again. What a waste... ?

You seem to be unaware of the possibility of calling one method from
another. You wouldn't paste the hundred lines of code. You'd write:

void SomeMethod()
{
SomeMethod(defaultValue); // Whatever the default value is
}

void SomeMethod (int parameter)
{
// 100 lines of code here
}

 

[Scott Coonce]

{
SomeMethod(defaultValue); // Whatever the default value is
}

void SomeMethod (int parameter)
{
// 100 lines of code here
}

I'm surprised at you, Jon. I thought a single method with a 100 lines was
bad form?

Scott

 

[Jon Skeet [C# MVP]]

I'm surprised at you, Jon. I thought a single method with a 100 lines was
bad form?

Usually, yes - although there are exceptions to the rule.

However, one method with 100 lines is better than two methods with 100
lines which are almost duplicates of each other

Jon

 

[Alvin Bruney - ASP.NET MVP]

why is it bad form? I'm currently stearing at a method i wrote the has 500
lines. I'll add that these are 500 compact lines of code. Where is the bad
form? You can't simply generalize about software development especially if
you write code that interfaces with other pieces of software that require
certain lengthy initializations.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006

 

[Jon Skeet [C# MVP]]

why is it bad form? I'm currently stearing at a method i wrote the has 500
lines. I'll add that these are 500 compact lines of code. Where is the bad
form? You can't simply generalize about software development especially if
you write code that interfaces with other pieces of software that require
certain lengthy initializations.

That length initialization can usually be broken up into smaller
methods, each of which is more easily understood, and more easily
tested. I often write a method which does nothing but call three or
four other methods in turn. That means when I need an overview of what
it does, I can just look at the names of the methods. When I need to
check the detail of a specific bit, I can skip straight to that method,
without looking at the intervening bits.

I rarely have a method which is more than about a page.