VB runtime functions in VB.NET for VB6 programmers [closed]

Question

I'm preparing a class on Visual Basic 2005 targeting Visual Basic 6 programmers migrating to the .NET platform.

My primary concern is to teach my students the best practices for developing in .NET, and I am wondering about whether to consider the use of the VB runtime functions VB.NET legitimate or not.

I have read that many of the VB functions in VB.NET actually invoke methods on the .NET Framework, so it appears they exist primarily to ease the transition from earlier versions of Visual Basic to VB.NET. However, the VB.NET team seems to recommend to use them whenvever possible since they claim they put some optimizations in there on top of the .NET framework APIs.

What's your take on this?

Answer 1

Where I'm at, I have to move back and forth between C# and VB.Net frequently. With that in mind, we really don't like the old VB functions, especially the strings functions: Trim(), Replace(), Len(), UCase(), etc. They just look odd in a .Net program, and I wouldn't want to see them in code I had to work on.

The only exception there might be Len(), if you read code in your head using the of verbage. In that case, reading Len(theString) as length of theString seems to make sense. In the others, it's more of an operation performed by the string, and so I want to see the . (dot) notation.

On the other hand, I've had a hard time weaning myself from the conversion operators: CStr, CInt, CDbl, etc.

I can't tell you why I like one type and not the other; it could just be that I find Convert.To___() too verbose, or maybe it has something to do with them being operators rather than functions.

Edit
This point kinda got lost in the rest of my post, so I want to emphasize it again:

In a lot of places, VB.Net co-exists with C#. I don't think you see as many VB.Net-only shops as you might for C#. It's just not as popular, and a lot of the VB.Net shops move to VB.Net just as a transition state while the programmers also learn C#. In these mixed environments, it's makes a lot of sense if the old VB functions are strictly forbidden in new code. You never know when a module will need to be moved over, and there is some mind-share overhead in having to be able to grok both styles at once. So it's really a bad idea not to understand both.

Answer 2

Well, I guess you have to take them at face value. I am a C# programmer primarily, but have been working on a VB.NET web application for the last 6-8 weeks.

My seat of the pants estimation suggests that using conversion functions such as CInt, CDate etc to be as fast as using Convert.Toxxx methods.

My advice would be: if it makes it easier, and it doesn't have a performance penalty then go for it! I would also teach them the .NET approach as well and let the user decide.

BTW, as a C# guy, I love the ease of the Cxxx routines. Just because they are only available in VB.NET doesn't mean you shouldn't use them (IMHO). Horses for courses and all that.