I'm making the transition from VB6 to VB.Net (VS 2010) and have a basic rather than expansive understanding of the latter. I obviously have quite a bit of code to... I hesitate to use the word "upgrade" when "port" would be more apt given that the upgrade wizard in past versions of VS may as well have just commented out the code and said "Hey, why don't you re-start from scratch?"
In one procedure which I'm bringing across the Len()
function was used to determine the length of a string variable. That still works in VB.Net (though I imagine that it's actually a call to the Strings.Len
Method), but the other alternative is to just query the .Length
property of the variable.
The question is which to use and why. I've looked through the relevant MSDN pages and all they seem to tell me is that the method/property exists. Nothing is said about performance issues, particularly when loops of large numbers of calls might be involved.
My question, then, is whether anyone is aware of any tested and confirmed benefit of using one approach over the other, or whether it's merely a question of personal preference. Any pointers on similar situations that I might encounter as I make the progression would also be appreciated though given the Stack Overflow guidelines it's just this one issue that I'm interested in seeing whether there's a specific answer to.
Recently I faced problem with my old VB.Net code that was using Len() function. I upgraded my project to Core which was referencing the old VB.net dll file and it was using Len() function. I got run time compatibility error - Method not found: 'Int32 Microsoft.VisualBasic.Strings.Len(System.String)'
I have to change all such old function that Core has deprecated. So I stand by using String.Length over Len() as suggested by Steven Doggart.
In addition to @Andrew's post, the Len() is string function from Visual Basic run-time library where as
Length
is a property ofSystem.String
class of .net framework API.The
Len
method is provided for backwards compatibility with old VB6 (and earlier) non-.NET code. There's nothing technically wrong with using it. It will work, and just as well, at that. But, it's better to use the new .NET way of doing things whenever possible. Outside of getting you more into the ".NET mindset", though, the only real tangible benefit of usingString.Length
is that it makes it easier to port the code to other .NET languages in the future.So according to this:
If you trust their word, then there's your answer. Otherwise, coding up a test and iterating should give you the final answer.
I'm not sure about the specifics of the
Len()
method (my language of choice is C#), but I would say definitely go with theLength
property.Length
is a member of theSystem.String
class, whereasLen()
isn't.My guess is that
Len()
is just a VB shim on top of theLength
property. Someone could probably make the argument that usingLen()
is more idiomatic, from a VB point of view. I think I'd prefer to use the property built in to the class, rather than just use a different mechanism just because it's provided by the language.Because you're using VB.NET, your
Strings
can beNothing
and unless you explicitly check for that, most VB methods, includingLen
, will treat it the same asString.Empty
i.e.""
.With Reflector you can see
Len
is implemented as a null check, returning0
forNothing
and otherwise returning.Length
, and the JITter will likely in-line the call.So, if you're using other VB methods, I'd suggest using
Len
too, unless you know theString
is notNothing
or check forNothing
everywhere.