C＃String.IsNullOrEmpty：好还是坏？
在工作中我误用String.IsNullOrEmpty和Session变量的事件后，我的同事现在拒绝接受我对String.IsNullOrEmpty的使用。 经过一些研究，显然在MSDN（ 链接 ）上列出了IsNullOrEmpty的错误（在底部阅读注释）：
截至2006年4月4日，有一个错误（可能在JIT中）使得此方法在启用优化时失败。 众所周知，它会同时影响C＃和VB。
更多信息可以在这里找到（ 链接 ）。 微软的这个漏洞在Orcas后被“推测”固定，但不幸的是我的雇主仍在使用VS2005。 但如果问题在2008年修复，那么就这样吧。 那对我来说没问题。
虽然我的同事拒绝我的IsNullOrEmpty我的代码是盲目的无知（IMO），他当然不能告诉我为什么不使用它而不是滥用会话变量。 我在代码中使用了IsNullOrEmpty，没有任何问题。 就个人而言，除了在一个语句中做两件事之外，我发现它更具可读性。
在谷歌上搜索关于这个主题的意见后，我发现网站采取了优点/立场。 以下是我读过的一些网站：
https://blog.rthand.com/post/2006/06/22/1063.aspx
Is String.IsNullOrEmpty Hazardous to your Code's health in .Net 2.0/3.0?
一个站点（ http://dotnetperls.com/isnullorempty ）很好地总结了方法（恕我直言）：
在这里，我们查看了字符串类型的IsNullOrEmpty方法，它为我们提供了一种检查字符串是否可以保存或使用的良好且相对有效的方法。 但是，为了提高性能，最好使用手动空检查。 空字符串也可以通过其他方式进行测试，我的研究表明检查长度最快。
假设在VS2008 / 2010 /等中修复了错误（并且正常工作），是否有任何理由不在 VS2005及更高版本中使用String.IsNullOrEmpty？ 我意识到这对于这种愚蠢的小方法看起来有点过分，但我想知道是否有更多的幕后工作，如果有人有其他解释。
此问题已在.NET 2.0 sp1中修复。 现在没有理由避免使用它。
如果您使用的是.NET 2，那么无论如何都应该有很多其他原因 – 我认为没有理由为不再存在的错误避免这种情况。
我之前听说过这个bug，而且从我可以收集的内容来看，它永远不会出现在任何真正的代码中，只会出现在代码中，而不是真正做任何事情的代码。 此外，错误不在于IsNullOrEmpty方法本身，因此无论您如何检查字符串都会发生错误。
如果该方法完全符合您的要求，您应该使用它。 但是，您不应该在每种情况下使用它来检查空字符串。 有时您只想检查字符串是否为空，如果它为空则不是。
如果字符串变量为null，则只会跳过代码块：
if (!String.IsNullOrEmpty(str)) { ... } 如果字符串变量为null，则会导致exception：
if (str.Length > 0) { ... }
如果变量不应该为null，则可能需要exception而不是将null值视为空字符串的代码。 如果出现问题，您希望尽早捕获它，因为从原因开始exception的时间越长，就越难将问题追溯到源。
你可以编写一个传递空字符串的unit testing和一个传递空字符串来测试这些东西的unit testing，然后在VS2005中运行它，然后在2008年之后看看发生了什么
我们对string.IsNullOrEmpty使用扩展方法：
public static bool IsNullOrEmpty(this string target) { return string.IsNullOrEmpty(target); }
使用这种方法，即使它在某些先前版本中被破坏，错误修复只是一行代码。
以及能够在可能为null的字符串实例上使用该方法的附加实用程序：
string myString = null; if (myString.IsNullOrEmpty()) { // Still works }
在链接中的错误报告中，您将其包括在内：
Microsoft .NET Framework 2.0 Service Pack 1（SP1）中已修复此错误。
既然如此，只要你安装了SP1 for .NET 2就可以使用VS 2005。
至于是否使用它，请查看CodingHorror的这篇文章 。
我很确定它已在SP1上修复，但无论如何你可以创建自己的null或空方法:)
与任何语言或其中的一部分一样，所有这些都是为了了解利弊，并根据该信息做出明智的决定。 恕我直言。
在API中实现参数检查时，我通常会分别检查每个条件并抛出不同的exception： ArgumentNullException用于空引用，或者，根据API规范， ArgumentException用于空字符串。 在这种情况下，使用String.IsNullOrEmpty不允许您区分这两个单独的错误条件。
if (str == null) { throw new ArgumentNullException("str"); } if (str == string.Empty) { throw new ArgumentException("The string cannot be empty.", "str"); }
如果它在您的版本中被破坏，那么只需要一个静态方法来进行检查就是微不足道的，所以这样做：
public static bool isNull(String s) { return s == null || s.trim().length == 0; }
对于一些应该相对容易修复的问题，没有任何意义。
您无需在任何地方更改它，但您可以使用另一个静态方法全局替换一个静态方法。
我想知道为什么人们使用string.Empty，这不是一件好事，因为它是一个初始化的字符串＆这个概念只存在于.Net框架中，这是一个有效的字符串，len为0（db服务器在这之间做出非常明确的命运并且会抱怨如果你有逻辑检查null但你得到并且空字符串）。 我认为string.IsNullOrEmpty是我见过的前5个最糟糕的做法/function之一，因为不知怎的，它鼓励/使人们看起来没问题，人们可以将它们作为初始化并被视为null。 这个function应该从未添加过，我认为.Net的人应该尝试逐步淘汰:)谁还需要空字符串呢？ 除非因为现有项目使用它，否则我从未使用它