C# or VB.NET?

[CMoya]

What would you rather do? Call "string.Length" or call "len (string)"
that then calls "string.Length" internally? And I don't know how the len
function handles nulls cos I didn't write it and haven't seen the source.
However I know how myString.Length will react if myString is null and I
don't need trial and error or consulting docs to tell me.

I'd rather call Len(str) than do the following in a bunch of places in code:

if (str != null) {
num = str.Length()
}
else {
// do something else. in this case assign: num = 0
}
//(Even worse if I want to duplicate Left/Mid/Right)

What's wrong with calling a reusable Len() "utility" function that does the
same thing as the conditionals above?

Using those functions also makes it harder to understand c# examples. If
you at least use vb.net as intended then reading c# shouldn't be too much
problem, and switching to c# if you want to should be easier.

Is it any different than using utility functions written by other
developers in your team or written by developers employed before you joined
the team... or worse, copy and pasted from the web? Do all C# developers
work alone and bring their redundant encapsulated utility functions to a
project? What a nightmare (that I've personally seen.... at least back in
the day VB coders did this a lot with API vodoo calls-- but C# guys do it
for the most rudimentary things). These built-in utility (standard)
functions are designed to make your life easier and manage projects
easier.... the goal of all high-end computer languages. Except perhaps C#? I
dunno.

 

[CMoya]

It might help if you provide some examples, but writing strongly typed
code is usually seen as a good thing. It removes ambiguity and the
possibility for bugs. VB does give you more leeway but that doesn't make
it good. For example VB can do this, but is it good?

dim x as variant
x = 123
x = "Hello World"

Of course it's not good. If one object can be converted to another type
then it's usually possible in C# too, just with different syntax.

VB.NET does not support the Variant data type. Perhaps you meant "Object"
type. Which, BTW, C# allows just fine too.

 

[Aidy]

I'd rather call Len(str) than do the following in a bunch of places in

code:

So you'd rather your code was vague rather than explicit? What happens
when, in "version x", Microsoft change the way Len is written and you need
to handle your own nulls? If you find you do that code a lot, then write
your own Len function and use it.

These built-in utility (standard) functions are designed to make your life
easier and manage projects easier.... the goal of all high-end computer
languages. Except perhaps C#? I dunno.

Fair point. My goal isn't to make things "easier" in terms of coding or
management. My goal is to write tight, explicit, strongly typed code that
is easy to extend, re-use and has a lower chance of introducing bugs. If I
need to put a little extra effort in to do that then so be it.

 

[Mark Rae [MVP]]

dim x as variant
x = 123
x = "Hello World"

That's actually not valid VB.NET... In VS.NET 2008, if you type or paste the
above code IntelliSense will change Variant to Object. At that level,
there's no difference between the above and:

object x = new object();
x = 123;
x = "Hello World";

 

[CMoya]

--
-C. Moya
http://www.cmoya.com

So you'd rather your code was vague rather than explicit? What happens
when, in "version x", Microsoft change the way Len is written and you need
to handle your own nulls? If you find you do that code a lot, then write
your own Len function and use it.

The Len utility function hasn't changed in over 25 years. It's intrinsic.
It's like expecting the ++ operator to change in C. I don't see C# guys
writing var = var + 1 wrapper functions to replace ++.

Fair point. My goal isn't to make things "easier" in terms of coding or
management. My goal is to write tight, explicit, strongly typed code that
is easy to extend, re-use and has a lower chance of introducing bugs. If
I need to put a little extra effort in to do that then so be it.

And as a manager, it's my job to make sure that my developers aren't wasting
time reinventing the wheel.... duplicating code, violating the basic tenets
of encapsulation, and neglecting to use tried and true functions. Whether
they're written by other developers in my team or put into the VB runtime by
the VB.NET team.

 

[Aidy]

And as a manager, it's my job to make sure that my developers aren't

wasting time reinventing the wheel.... duplicating code, violating the
basic tenets of encapsulation, and neglecting to use tried and true
functions. Whether they're written by other developers in my team or put
into the VB runtime by the VB.NET team.

Yes, but loosely typed and coupled code may speed up development but you
lose in the long-run on bug fixing and future updates.

 

[Aidy]

That's actually not valid VB.NET...

"For example VB can do this"



I know, I was harking back to the history of VB where your typing can be as
loose as you want. It seems like MS are trying to carry that forward with
vb.net too.

 

[Aidy]

See my reply to Mark. We're all coders, we really should read posts before
commenting and be more pedantic

 

[CMoya]

Yes, but loosely typed and coupled code may speed up development but you
lose in the long-run on bug fixing and future updates.

Nobody is talking about loosely typed code.

 

[CMoya]

"For example VB can do this"



I know, I was harking back to the history of VB where your typing can be
as loose as you want. It seems like MS are trying to carry that forward
with vb.net too.

No, not really.

 

[ThatsIT.net.au]

I am employed to code in C# but in my own time and when I'm paid for jobs
outside of work, I use VB.

I have never come across any reason not to, and it much more fun to use,
Visual studio is much more friendly to VB

 

[ThatsIT.net.au]

what nonsence
very weak argumnet

This is probably the best argument against VB.

they the argument is lost

 

[ThatsIT.net.au]

better intellisence better code completion better snippets, just to name a
few