C# String.IsNullOrEmpty: good or bad?
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
This issue was fixed in .NET 2.0 sp1. There is no reason to avoid its use now.
If you're using .NET 2, you should have sp1 for many other reasons anyways - I see no reason to avoid this for a bug that no longer exists.