Re: Checking for A Blank String

Tech-Archive recommends: Fix windows errors by optimizing your registry

Tom,

"Tom Leylan" <tleylan@xxxxxxxxxx> schrieb:
You can look up "robust" in a dictionary and I don't understand why you didn't.

I know the meaning of "robust". The whole discussion is now about using 'Len' vs. 'String.IsNullOrEmpty'. It's pretty clear that the shortest solution is not always the most robust one. However, I do not see the relation to my preference of 'Len'. 'Len' is faster to type and read and I do not consider it less robust than 'String.IsNullOrEmpty'.

I of course never wrote that the Len() function was "less robust" but that trick can often work in a discussion so I admire your attempt.

Well, then I suggest you specify more clearly what you are talking about.

Have you distributed your software to 3000 locations? When you found a bug did you pick up the costs associated with redistribution?

Where's the relation to the topic?

It should be clear that "typing fast" isn't the issue but rather correctness, robustness, verifiability, etc. are.

I consider both 'Len', 'String.IsNullOrEmpty' and 's IsNot Nothing AndAlso s.Length > 0' correct and robust solutions (lets forget the 'IsNullOrEmpty' JITter bug here). So this calculus is not of much use here. That's why I am using a different one: Ease of writing and reading.

Software development (as I have found it) isn't about memorizing the behavior of the functions in a particular language. If that were the most important thing those of us who write software solutions wouldn't get much done.

Then I am wondering how you are writing code at all.

not my goal. My goal is to accept the contract to convert my app from VB.Net to C# and to complete the task so I can get paid. My goal is to re-engineer the Java app into VB.net and to complete the task so I can get paid. My goal is not to save 7 characters when I type.

I believe anybody is free to use 'Len' or not. However, I do not see the problem you are having with it. 'Len' can be converted to another programming language as easily as 'String.IsNullOrEmpty'.

Null may not exist as a keyword but surely you aren't suggesting that VB developers don't know the concept, right? So "nothing" is the keyword, again I caution against memorization and vote in favor of learning concepts rather than (or at least in addition to) syntax.

Hm... This point was intended as a joke. No, I really do /not/ think this is a valid reason not to use 'String.IsNullOrEmpty', as I do not see the naming and behavior as a reason for abandoning it from the toolbox.

And of course it is nothing like using a screwdriver to hammer in a nail and most definitely not due to some ranking of the tools in the toolbox. What you are describing is the importance of using the hammer that is marked as "VB.Net" and avoiding at all cost the hammer marked ".Net Framework". Your special hammer is better than the hammer everybody else is using.

I gave the reasons why I prefer 'Len' over 'String.IsNullOrEmpty' in my previous post. There is at least one technical reason that prevents me from using 'String.IsNullOrEmpty'. My toolbox contains both the Visual Basic Runtime Library and the .NET Framework Class Library and I do not have a general (ideological) preference which tools to choose.

I doubt that any VB developer using the full repertoire available in the VB "toolbox" will have problems to understand what 'Len' is doing. I also believe that I can expect such knowledge from someone claming to know VB.

These particular doubts are unfounded. If you worked with software developers for any length of time you will find that what they know varies considerably. After you've looked up robust, take a moment to consider the number of people posting questions here which on the surface seem trivial. Many of these could be answered by checking the docs, a great number are posted by working developers. You're making statements that have no basis in fact in an attempt to "win" a discussion.

I do not want to win anything. It seems that you see discussions as fights instead of what they are -- just discussions. Be assured that I know that many developers don't have much knowledge about the tools they are using. However, as I said, there is no problem 'Len' has and 'String.IsNullOrEmpty' doesn't have.

Again (for the record) generally when I reply to you it is not to enlighten you as I expect only the VB-side of the story in your rebuttal but rather to influence others who may wish to become more than a "VB programmer" and aspire to becoming a software developer who uses VB. Furthermore I ask that readers simply take note of your use of the terms harder, low-level and complicated when something isn't VB and easy, fast, etc. when it is VB.

These points are all ungrounded prejudices, none of them apply. I am actually using different programming languages and I prefer use the tools they provide. The .NET Framework's method has been considered "low-level" because the VB.NET class library and other libraries are built on top of the ..NET Framework's classes, often providing access on a higher level, as .NET programming languages like VB.NET and C# do over IL.

DANGER ! String.IsNullOrEmpty can lead to runtime Null exceptions !!
<URL:http://msmvps.com/blogs/bill/archive/2006/04/04/89234.aspx>

The link is appreciated. Now any reader with a concern can see plainly that it does not in fact throw exceptions "in certain circumstances" but (if the article is correct) will throw an exception in one particular case.

At least to me as a non-native English speaker this means the same. However, I only remembered that there was a problem with this method and I didn't remember which one it was. I had to look for the article again to see what it has been about (the JITter making problems with this method).

Let me let you in on something, there are bugs in the .Net Framework and here is a secret, optimizers can make mistakes.

To other readers I'll suggest one avoid making rash coding decisions based upon a bug. Work around the bug, it will be patched. Other bugs will turn up in time, such is the life of a programmer. If there was never a bug in a VB library then by all means limit your development to VB and never use anything else (perhaps join the pro VB6 rant of at least one poster) because you have truly found the one great solution.

If there are two ways to archieve a certain thing and one of them is faulty, why choose the faulty one? It seems that your decisions are much more based on ideology than mine. I use 'Len' because there are problems attached with another way to archieve the same thing and you are wrongly extrapolating that to a general preference of VB's functions over the .NET Framework.

For everybody else, raise your eyes and take a look out over the development horizon. All tools are available to you including VB.Net of course.

I 100 % agree, but this even includes using the tools VB provides over the tools of the .NET Framework if their use has advantages.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

.

Quantcast