我更喜欢字符串而不是字符串。选择字符串。空而不是“”是选择一个并坚持下去的问题。使用字符串的优点。空是很明显你的意思，你不会不小心复制了不可打印的字符，如“\x003”在你的“”。

编译器应该让它们在长期运行时都是一样的。选择一个标准，这样你的代码就容易阅读，并坚持下去。

我亲眼目睹了两次“导致(小)问题”。一次是由于一个刚接触基于团队编程的初级开发人员的错误，另一次是一个简单的拼写错误，但事实是使用了字符串。空本来可以避免这两个问题。

是的，这在很大程度上是一种判断，但是当一种语言提供了多种方法来做事情时，我倾向于使用具有最多编译器监督和最强编译时强制的语言。那不是“”。这一切都是为了表达具体的意图。

如果你输入字符串。EMpty或string。空，编译器让你知道你做错了。立即。它根本不会编译。作为一个开发人员，你引用的是编译器(或其他开发人员)不能以任何方式误解的特定意图，当你做错了，你不能创建一个bug。

如果你输入“”当你想要“”时，反之亦然，编译器会很高兴地执行你让它做的事情。其他开发人员可能无法收集到您的特定意图。Bug。

早在字符串出现之前。Empty是我使用的标准库，它定义了EMPTY_STRING常量。我们仍然在case语句中使用这个常量。不允许为空。

只要可能，让编译器为你工作，并消除人为错误的可能性，无论多么小。在我看来，这比“可读性”更重要。

专用性和编译时强制。这是晚餐要吃的。

这完全是一个代码风格的偏好，就像。net如何处理字符串一样。然而，以下是我的观点:

我总是使用BCL类型名称访问静态方法，属性和字段:字符串。Empty或Int32.TryParse(…)或Double。ε

我总是在声明新实例时使用c#关键字:或者string foo = "bar";

我很少使用未声明的字符串字面量，因为我喜欢能够扫描代码，将它们组合成可重用的命名常量。编译器无论如何都会用字面量替换常量，所以这是一种避免神奇的字符串/数字，并通过名称赋予它们更多含义的方法。另外，更改值更容易。

这个话题已经很老很长了，所以如果在其他地方提到过这种行为，请原谅。(并指出我的答案，包括这个)

如果你使用字符串，我发现编译器的行为有所不同。空引号或双引号。如果你不使用用string初始化的string变量，区别就会显现出来。为空或带双引号。

在初始化字符串的情况下。空，然后编译器警告

CS0219 - The variable 'x' is assigned but its value is never used

永远不会触发，而在使用双引号初始化的情况下，您将获得预期的消息。

这种行为在Connect文章中有解释，链接:https://connect.microsoft.com/VisualStudio/feedback/details/799810/c-warning-cs0219-not-reported-when-assign-non-constant-value

基本上，如果我做对了，他们希望允许程序员用函数的返回值设置一个变量用于调试目的，而不用警告消息来打扰他，因此他们只在常量赋值和字符串的情况下限制警告。空不是常数，而是场。

几年后 微软已经关闭了https://connect .microsoft.com网站，因此没有更多可用的讨论。然而，这篇文章https://learn.microsoft.com/en-us/dotnet/csharp/misc/cs0219有一个有趣的评论，似乎证实了前面的原因:

只有当变量值为a时，编译器才会生成此警告 编译时常量。指定一个非常量表达式或方法 结果的局部变量，使观察这些更容易 调试器中的表达式。它还使结果可达， 在该变量可达时防止垃圾收集。

最好的代码是没有代码:

编码的基本性质是，作为程序员，我们的任务是认识到我们所做的每一个决定都是一种权衡。从简洁开始。根据测试的需要增加其他维度。

因此，代码越少越好:更喜欢“”而不是字符串。Empty或String.Empty。这两篇文章的篇幅长了六倍，但没有额外的好处——当然也没有额外的清晰度，因为它们表达的信息完全相同。