17

Possible Duplicate:
What is the difference between String.Empty and “”

Is "" equivalent to String.Empty?

Which is preferred for initializing string values?

Community
  • 1
  • 1
Joan Venge
  • 315,713
  • 212
  • 479
  • 689

8 Answers8

31
public sealed class String {
    //...
    public static readonly String Empty = "";
    //...
}

Use null when you want to represent that there is no value;

Use String.Empty when you want to represent that there is a value, but the value is a blank string.

yfeldblum
  • 65,165
  • 12
  • 129
  • 169
  • 8
    Fairly importantly, it's also readonly :) – Jon Skeet Jun 22 '09 at 16:36
  • I'd say that for lack of a String.Unknown, null can also be used to represent an unknown value (as well as no value). – Michael Meadows Jun 22 '09 at 16:36
  • 2
    Whether `null` means `does not exist` or `exists but is unknown` depends on the way you use it in your program, and the developer should either make the code clear or document it. But there should certainly and absolutely not be a `String.Unknown` because that does not belong in class `String`. – yfeldblum Jun 22 '09 at 16:44
11

String.Empty because it is a static variable, rather than "" which has to create a new string, and null means that you must then set the string equal to a new instance of a string.

(thanks for the correction)

CodeMonkey1313
  • 15,717
  • 17
  • 76
  • 109
  • 3
    Technically, String.Empty is not a constant. It's a static readonly field. If it was a constant, there would be no difference between "" and string.Empty. – Mehrdad Afshari Jun 22 '09 at 16:33
  • String.Empty is not a constant, it's a field. Its backing value is a constant, but you have some limitations by String.Empty not being a constant. For example, you can't use it as a value in a case clause of a switch statement. – Michael Meadows Jun 22 '09 at 16:35
  • 2
    Note that "" *might* create an extra string *once*. It's not like it's going to create a new string every time you go round the code. – Jon Skeet Jun 22 '09 at 16:40
8

Yes. And String.Empty, but please don't worry about it.

The difference between String.Empty and “” are pretty small, but there is a difference. “” actually creates an object, it will likely be pulled out of the string intern pool and String.Empty creates no object, so if you are really looking for ultimate memory efficiency, I suggest String.Empty. However, you should keep in mind the difference is so trival you will like never see it in your code…

Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321
Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539
7

Use whichever you find most readable.

I challenge anyone to find a realistic application where there's a significant performance difference... it just won't happen. However, different people find different approaches more readable.

Personally, I'm a "" person. I find it less cluttered, and I've never encountered a problem where I actually used " " (or something similar) accidentally. (That's one of the objections frequently raised.)

If you prefer string.Empty, I'm certainly not going to claim you're "wrong". I would suggest, however, that if you're working on a team you discuss it to find out what most people think is more readable, and stick to that. Consistency is generally a good thing.

EDIT: Just to allay some fears which might be induced by the claim that "" will create a new string... it may create a new string once (possibly per AppDomain, possibly per process; I'm not sure and it really doesn't matter). It won't create a new string every time you use it. For example, consider this code:

public void Foo()
{
    string x = "";
    for (int i=0; i < 10000000; i++)
    {
        string y = "";
        // Do something here
    }
    string z = "";
}

You are guaranteed that x, y and z will refer to the same string. At most, invoking Foo will mean a single empty string is created, and only the first time you call it, and only if you haven't used an empty string literal anywhere else in the program yet. The code above is not going to create 10 million new strings.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • "it may create a new string once" - why would it do that? I'd have thought the empty string literal "" would already be in the intern pool as it has been referenced by the String.Empty property. – Joe Jun 22 '09 at 17:53
  • @Joe: I suspect in *some* cases it wouldn't be, but they'd be complicated cases involving things like CompilerRelaxations.NoStringInterning. I strongly suspect it wouldn't usually create *any* strings, but "at most one" is good enough in terms of performance and less likely to be wrong in weird corner cases :) – Jon Skeet Jun 22 '09 at 18:36
5

It is considered better practise to use string.Empty, however they are effectively equal. They are not the same as null, however.

Ed James
  • 10,385
  • 16
  • 71
  • 103
2

FROM http://msdn.microsoft.com/en-us/library/system.string.empty.aspx

The value of this field is the zero-length string, "".

In application code, this field is most commonly used in assignments to initialize a string variable to an empty string. To test whether the value of a string is String..::.Empty, use the IsNullOrEmpty method.

Johnno Nolan
  • 29,228
  • 19
  • 111
  • 160
1

They are equal . But String.Empty is constant .

"" - is way of creating String .

joe
  • 34,529
  • 29
  • 100
  • 137
1

The answer you are looking for is here.

What is the difference between String.Empty and "" (empty string)?

use String.Empty

Community
  • 1
  • 1
David Basarab
  • 72,212
  • 42
  • 129
  • 156