Eric Wise

Business & .NET

An Argument For C#

I was reviewing some code the other day from one of my developers who recently made the jump from classic ASP to ASP .NET and I found that the developer was using a lot of the old VB core functions like cint(), dateadd() etc instead of their new .NET Framework counterparts.

In my opinion, it is preferred to use the .NET Framework methods whenever possible instead of the VB Specific ones both for potential compatibility for porting code to other .NET languages and because of my unverified belief that some of the Framework specific functions may be more efficient.

So I got to thinking about ways that we could pursue to help make these developers aware of the framework functions and more importantly break the "bad habit" of using the old school functionality beyond tools like FX Cop. The problem is not the talent or intelligence of the developers, but more of a habitual one. It struck me that this would be one of the main benefits of transitioning from vb 6.0 to C#... it would force you to leave behind the old school VB functions we all know and love and learn the Framework.

</End Musing>

Published Jun 30 2005, 07:55 AM by Eric Wise

Filed under: C#, VB .NET

Comments

mrpeabody said:

Eric, I just read this and shouted out a loud 'yes'... (Note: it is 2am here and my wife sleeping about 10 feet away didn't appreciate it...but well...) sometimes something hits you between the eyes that is so bleeding obvious, but never occurs to you.

Having come from VB6 and *gulp* VBA thru to VB.Net and 'playing' but not seriously coding with C#, this has given me motivation to spend more time on C#.

Old habits do die hard and when something 'works' using the 'old school' methods it's hard to force yourself to learn the new.

Thanks.

# June 30, 2005 7:09 AM

Leigh Kendall said:

If you're that concerned about using "old" (oooh scary...) VB "style" functions; just remove the Microsoft.VisualBasic import. Of course the assembly will still be referenced, but at least you'll be coerced into NOT using these big bad functions. Things like Cxxx will still work since they're compiled inline, but so what. How's that so different from how C# handles it using the silly (datatype) type casts?

I only use them [VB specific functions] if there isn't a suitable BCL equivalent that makes sense.

# June 30, 2005 8:43 AM

Adam Saxton said:

I don't even know why they allowed them in VB.NET to begin with. They broke a lot of other compatability items, why didn't they ditch those... or at least not reference teh dll by default to force people to learn the .NET methods. One thing I have seen is that people get stuck using these and it really hampers their ability to really use and learn the .NET Framework.

I, myself, came from the VB world originally... started with Classic ASP and then moved to VB.NET during the first early beta. I actually assumed that they wouldn't be there so I learned the .NET ways of doing things... later i found out they were there but by then i was over the .NET curve and my friend had forced me to move to C# :) I thank him for that.

# June 30, 2005 9:23 AM

Bob said:

Personally, when I started on VB.NET, it was ASP.NET pages in vb. I still used the old functions since there was nothing in the readme saying I should stop using them, for performance or other reasons.

I recently picked up c# and started using it on regular basis. At this point, I am moving back and forth between vb and c# quite often, and I don't really see to much of a difference, other than than the damned annoying requirement for me to type so much extra damned punctuation.

Anyone out there who can read IL reasonably well wanna try to see if cint and toint (or whatever it is) compile to the same code?

# July 1, 2005 8:20 AM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?