Len() function vs String.Length property; which to choose?

Question

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.

Huxham

See also discussion about VB.Net runtime for ex-VB6 programmers here – Raama

Answer 1

Because you're using VB.NET, your Strings can be Nothing and unless you explicitly check for that, most VB methods, including Len, will treat it the same as String.Empty i.e. "".

With Reflector you can see Len is implemented as a null check, returning 0 for Nothing 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 the String is not Nothing or check for Nothing everywhere.

Fresno

Somehow I'd assumed that they'd both return 0 if a value hadn't been assigned. It's another aspect of how I haven't yet started thinking in "variables as objects" terms. I think I may still opt to go the route that Andrew and Steve suggested to keep closer to more standard .Net syntax but this has been a wakeup call to initialise all string variables with zero length strings. Many thanks for that. I'd love to be able to give more than one "answer" mark (though I've voted up all of the answers since they all helped) but for helping me avoid that particular bear trap I'll give it to this one. – Huxham

IMHO checking for Nothing is not a reason enough to use Len which is provided for backward compatibility with VB6. I would rather write a wrapper to check for Nothing and use String.Length – Coronach

@Coronach On that logic Left, Mid and Right shouldn't be used in new code because you can extract .SubStrings using your own numerical manipulation of .Length etc. And although I know people suggest that as a valid path, I think it's just stupid to not use what the language provides. – Fresno

@MarkHurd IMHO it's not always wise to use everything that a language provide (e.g. eval in JS). As mentioned by others as well, these methods are for backward compatibility and for developers who are too accustomed to using them. If they had any value they would be in C# as well. Anyways if their usage is a testimony to your wisdom keep using them. – Coronach

@Coronach That's if C# was trying to copy VB.NET, but it explicitly wasn't. It took versions before they conceded named, optional parameters were useful (especially for legacy coding I agree). C# was trying to be C- (and Java-) like. – Fresno

Answer 2

So according to this:

Len, another classic BASIC function, returns the length of a string. System.String has the Length property that provides the same information. Is one better than the other?

Performance-wise, these two functions show little difference over 1000’s of iterations. There doesn’t appear to be any reason to prefer one over the other in this case plus there is no functional difference. I’m kind of partial to using the property value rather than the VB function since it encourages thinking of .NET strings as objects. However, at the core, it’s really only a personal preference thing.

If you trust their word, then there's your answer. Otherwise, coding up a test and iterating should give you the final answer.

Come

Thanks Andy. The thought of doing some tests crossed my mind but short of making a profession of it you can never be sure whether the test results are specific to the data sets that you're using. I therefore raised the question mainly to see whether anyone could give some insight into what was going on "under the hood". I didn't come across that site in my searches; very useful, I think. – Huxham

Answer 3

I'm not sure about the specifics of the Len() method (my language of choice is C#), but I would say definitely go with the Length property. Length is a member of the System.String class, whereas Len() isn't.

My guess is that Len() is just a VB shim on top of the Length property. Someone could probably make the argument that using Len() 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.

Buskus

Why guess? Mark Hurd didn't, he looked into it and found that Len is semantically different from Length. See his answer. – Raama

Thanks Andrew; I take your point. I expect that I'll probably still use a few "classic" VB idioms until I start "thinking .Net" but at least it seems that there's no real harm in doing so. (Except the occasional eye roll from more experienced .Net writers. 8^>) – Huxham

Answer 4

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 using String.Length is that it makes it easier to port the code to other .NET languages in the future.

Keefe

Answer 5

In addition to @Andrew's post, the Len() is string function from Visual Basic run-time library where as Length is a property of System.String class of .net framework API.

Integumentary

Answer 6

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.

Mayberry

You may be able to resolve this by adding a reference to the Microsoft.VisualBasic assembly. However, the move away from VB6 comfort functions to more modern .NET equivalents is worthwhile, so I also recommend System.String.Length. – Kylstra