C# String.IsNullOrEmpty：好还是坏？

在工作中发生一次我将 String.IsNullOrEmpty 与 Session 变量一起滥用的事件之后，我的一位同事现在拒绝接受我对 String.IsNullOrEmpty 的使用。经过一番研究，显然 MSDN 上列出了 IsNullOrEmpty 的错误（link http://msdn.microsoft.com/en-us/library/system.string.isnullorempty(VS.80).aspx）（阅读底部的注释）：

截至 2006 年 4 月 4 日，存在一个错误 （可能在 JIT 中）这使得 当优化时方法失败 打开。已知会影响两者 C# 和 VB。

更多信息可以在这里找到 （link http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=113102）。微软这个 bug 应该是在 Orcas 之后修复的，但不幸的是我的雇主仍然使用 VS2005。但如果问题在 2008 年以后得到解决，那就这样吧。这对我来说没问题。

虽然我的同事用 IsNullOrEmpty 拒绝我的代码对我来说是盲目的无知（IMO），但他当然不能告诉我为什么not除了误用会话变量之外，还可以使用它。我在我们的代码中使用了 IsNullOrEmpty ，没有任何问题。就我个人而言，我发现除了在一个语句中做两件事之外，它更具可读性。

在谷歌上搜索有关该主题的意见后，我发现了一些持赞成/反对立场的网站。以下是我读过的一些有关此内容的网站：

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

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

一个站点（http://dotnetperls.com/isnullorempty http://dotnetperls.com/isnullorempty）很好地总结了该方法（恕我直言）：

这里我们查看 IsNullOrEmpty 字符串类型的方法，其中 为我们提供了一个良好且相对的 检查是否存在的有效方法 字符串可以保存或使用。然而， 为了性能，可能更好 使用手动空检查。空字符串 还可以通过其他方式进行测试，并且 我的研究表明，检查 长度最快。

假设错误修复已在 VS2008/2010/等中到位（并且正常工作），是否有任何原因not在 VS2005 及更高版本中使用 String.IsNullOrEmpty？我意识到对于这样一个愚蠢的小方法来说，这似乎有点矫枉过正，但我​​想知道幕后是否还有更多的事情发生，以及是否有人有其他解释。

此问题已在 .NET 2.0 sp1 中修复。现在没有理由避免使用它。

如果您使用 .NET 2，无论如何您都应该出于许多其他原因而使用 sp1 - 我认为没有理由为了不再存在的错误而避免这种情况。