Yea, we have heard that request before... here is a method we are looking at adding a the Whidbey release of the .NET Framework on the System.String class.
public static bool IsNullOrEmpty( string str)
what do you think?
"The method might seem convenient, but most of the time I have found that this situation arises from trying to cover up deeper bugs.
Your code should stick to a particular protocol on the use of strings, and you should understand the use of the protocol in library code and in the code you are working with.
The NullOrEmpty protocol is typically a quick fix (so the real problem is still somewhere else, and you got two protocols in use) or it is a lack of expertise in a particular protocol when implementing new code (and again, you should really know what your return values are)."
[Miguel de Icaza]
I agree that there is potential for misuse, but this doesn't mean it isn't a good idea by any means. In certain places, my BLL code should be robust enough to know that an empty string input from the UI layer is the same thing as a null value, regardless of how it ends up in the DB (most likely as DBNull like it should be).
Should I force the developers using my code to write nice little conversion statements all over their UI layer like "emailAddress == String.Empty ? null : emailAddress"? Or should I realize that if they give my code a blank email address that they are giving me nothing, not a malformed email. I could spit back an error that says "Email Address is not in the proper format," but that is not true, the fact is that they didn't give me any email address (so if I needed one, I should spit back a more descriptive error that says, "you must give me an email address" instead).
Considering that languages like VB.NET blur the distinction between string and null, it is quite possible that the morts who are calling into my code might not even realize that there is a physical difference between an empty string and a null value. Making my code smart enough to adapt to these circumstances where it makes sense produces code that is a lot easier to interface with and saves a lot of developers a lot of time (as does using XP and VS.NET rather than Gnome and VI(M)).
I vote that we let Microsoft keep designing and Ximian keep cloning, things are better that way :-).