C# String.IsNullOrEmpty: good or bad?

Question

After an incident at work where I misused String.IsNullOrEmpty with a Session variable, a fellow coworker of mine now refuses to accept my usage of String.IsNullOrEmpty. After some research, apparently there's a bug listed for IsNullOrEmpty on MSDN (link) (read note at the bottom):

As of April 4, 2006, there is a bug (possible in the JIT) that makes this method fail when optimizations are turned on. It is known to affect both C# and VB.

More information can be found here (link). Microsoft the bug is 'supposedly' fixed post-Orcas, but unfortunately my employer still uses VS2005. But if the problem is fixed in 2008+ so be it. That's just fine with me.

While my colleague's refusal of my code with IsNullOrEmpty to me is blind ignorance (IMO) he certainly can't tell me why not to use it other than the misuse with the session variable. I've used IsNullOrEmpty all over our code with no issues whatsoever. Personally, I find it much more readable in addition of doing two things in one statement.

After googling for opinions on the subject, I've found sites that take the pros/con stance. Here are some of the sites I've read about this:

https://blog.rthand.com/post/2006/06/22/1063.aspx

http://www.omegacoder.com/?p=105

One site (http://dotnetperls.com/isnullorempty) sums up the method (IMHO) pretty well:

Here we looked that IsNullOrEmpty method on the string type, which provides us with a good and relatively efficient method of checking whether a string is OK to save or use. However, for performance, it may be better to use manual null checks. Empty strings can also be tested in other ways, and my research here shows that checking length is fastest.

Assuming the bug fix is in place (and working correctly) in VS2008/2010/etc., is there any reason not to use String.IsNullOrEmpty with VS2005 and beyond? I realize this may seem a little overkill over such a silly little method, but I'd like to know if there's more behind the scenes going on and if anyone has alternative explanations.

Answer 1

I wonder why people use string.Empty, it's not a good thing because it's an initialized string & this concept exists only in .Net frame everywhere this is a valid string with len of 0(db servers make very clear destinction between this and will complain if you have logic checking for null but you get and empty string). I think that string.IsNullOrEmpty is one of the top 5 worst practices/functions I have ever seen because somehow it encourages/makes it look ok people to init their strings and can be treated as null. This function should have never been added and I think the .Net guys should try to phase it out:) Who needs and empty string anyway ? I've never used it unless I had to because of existing projects used it

Answer 2

As with any language or portion thereof, it's all about knowing the pros/cons and making an educated decision based on that information. IMHO.

Answer 3

We use an extension method for string.IsNullOrEmpty:

public static bool IsNullOrEmpty(this string target)
{
  return string.IsNullOrEmpty(target);
}

Using this approach, even if it were broke in some previous version, a bugfix is only one line of code.

And the added utility of being able to use the method on a string instance that might be null:

string myString = null;
if (myString.IsNullOrEmpty())
{
  // Still works
}

Answer 4

In that bug report in the link you include it states:

This bug has been fixed in the Microsoft .NET Framework 2.0 Service Pack 1 (SP1).

Since that is the case it shouldn't matter if you're using VS 2005 as long as you have SP1 for .NET 2 installed.

As for whether or not to use it, check out this post by CodingHorror.

Answer 5

you could write a unit test that passes an empty string and one that passes an null string to test this stuff, and run it in VS2005 and after in 2008 and see what happened

Answer 6

I am pretty sure it was fixed on the SP1 but anyway you can create your own null or empty method :)