Re: C# Vs VB.NET

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Lucvdv <replace_name@xxxxxxxx> wrote:
> > <"=?Utf-8?B?U2FyYXRoIEJhYnU=?=" <Sarath
> > Babu@xxxxxxxxxxxxxxxxxxxxxxxxx>> wrote:
> > > Can anyone let me know why most companies prefer C# when the same task can
> > > be accomplished using VB.NET in a simpler and easier way..?
> >
> > Perhaps because your idea of simpler and easier isn't theirs?
>
> The question is who is wrong.
>
> Neither and both, IMO: C# will be easier for C/C++ and Java developers,
> VB.Net will be preferred by those who were used to VB6.
>
> VB requires some more typing, but I find that makes the result more
> readable. I've seen C/C++/C# code where almost every } is followed by a
> comment to indicate what statement it belongs to, VB is self-documenting in
> that regard.


Just because you've seen some bad C# code doesn't mean it *has* to be
worse :)

(I've seen some really horribly written VB.NET code, but that doesn't
mean it all is.)

> In the DirectX SDK you find sample code for VB and C# that only differs in
> syntax, where program structure and even comment text are fully identical
> because it was written in one language and then simply syntax-translated to
> the other. Translation can usually be done line by line, keyword by
> keyword (the most work is C# to VB, finding the right } and replacing it by
> the right keyword each time).

Sure.

> > Personally I find C# simpler, partly because as a language it's so much
> > smaller, without all the legacy functions that VB.NET carries around
> > with it.
>
> Legacy functions are an extension you don't have to use.
> Just leave Microsoft.Visualbasic.Compatibility out.

They're part of the language though, aren't they? That means there are
more keywords which you have to avoid, unless I'm missing something.

> > I suspect if I used VB.NET regularly, the thing I'd miss most from C#
> > is the "using" statement - it's so much easier to write
> >
> > using (Stream s = ...)
> > {
> > ...
> > }
> >
> > than manually putting the try/finally in the right place.
>
> I don't see the relation to exception handling, or else I missed something
> in C# (I haven't used it much).
>
> The VB equivalent is
> With s As Stream = ...
> ...
> End With
> Different syntax, exact same thing (AFAIK).

No, far from the same thing. The using statement is equivalent to:

Stream temp = null;
try
{
// instantiate stream or whatever
temp = ...;
// do stuff
}
finally
{
if (temp != null)
{
temp.Dispose();
}
}

If you're opening streams in VB.NET and not calling Dispose or Close in
a finally block, you've got a potential resource leak.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Unsigned Indexing (was: some other sad story)
    ... [snipped lengthy discussion about whether the presence of an "unsafe" ... >> verifiably type safe from running. ... >> track of which programming language was used to write each piece ... > features including the unsafe keyword. ...
    (comp.programming)
  • Re: Lisp for the C21
    ... This has nothing to do with keyword arguments as such. ... Because it is a standardized way of doing and thus has language support (which ... It would not be difficult to add keyword arguments to an object system ... implemented in Scheme via macros. ...
    (comp.lang.functional)
  • Re: Working on new language
    ... I'll make sure to put some warts in the language:) ... syntax to me is misguided. ... So apart from the "so" keyword mentioned below I require ... It would be possible to separate arguments with commas, but the opens ...
    (comp.lang.misc)
  • Re: Possible TRY...CATCH...END TRY
    ... but I don't see retry as being useful enough, ... doesn't justify a new keyword being introduced. ... language construct already supports it. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Possible TRY...CATCH...END TRY
    ... but I don't see retry as being useful enough, ... doesn't justify a new keyword being introduced. ... language construct already supports it. ...
    (microsoft.public.dotnet.languages.vb)