I've been running StyleCop over my code and one of the recommendations SA1122 is to use string.Empty rather than "" when assigning an empty string to a value.

My question is why is this considered best practice. Or, is this considered best practice? I assume there is no compiler difference between the two statements so I can only think that it's a readability thing?

SO question and answer

Jon Skeet answer to question

  • 5
    I'm sure this was asked and answered on Stack Overflow - but I'm having trouble finding it. It's to do with the fact that it has to instantiate a new string object for "" but not string.Empty
    – ChrisF
    Commented Mar 19, 2012 at 20:28
  • @ChrisF Ahh, didn't think to look on stack overflow for this type of question. I'll have a gander.
    – dreza
    Commented Mar 19, 2012 at 20:30
  • 1
    dup of question on stackoverflow: stackoverflow.com/questions/151472/… Commented Mar 19, 2012 at 20:30
  • @ChrisF - It has been asked on SO. Over and over and over...
    – Oded
    Commented Mar 19, 2012 at 20:31
  • 1
    Here we go - stackoverflow.com/questions/151472/… - back from September 2008.
    – ChrisF
    Commented Mar 19, 2012 at 20:31

4 Answers 4


One valid reason is that it makes it clear this is not a typo or placeholder, that you really meant to use the empty string here.

I don't know if it's considered "best practice".

  • ""...this is not a typo or placeholder"". Can you explain this 2 cases, I really don't see it.
    – Alex 75
    Commented Feb 16, 2021 at 9:58

I'd imagine there are two reasons, one for readability, and two for a minor performance boost.

Readability is easy: it's a lot quicker to spot string.Empty than "". Searching for string.Empty is also generally going to be easier and maybe more accurate than looking for the literal. It also clarifies intent: you didn't just make a typo or forget to finish something, you really did want empty string.

The performance reason is due to interning. You see, the runtime keeps a table of previously used strings so that it can quickly do string comparisons without actually doing a character-by-character check. string.Empty is already an interned reference to "" where-as typing the literal may not give you the interned version, thus causing a slight performance hit.

  • 9
    one nitpick, typing the literal "" will always give you the same interned version of "", at least since .Net 2 and up. Commented Mar 19, 2012 at 20:34
  • Right, the interning article on MSDN is a bit hard to follow on that point. It does seem like "" and string.Empty should both point at the same interned string, but it seems to indicate some differences between .net runtime versions. I think any string literal that appears multiple times in code will be interned on the second and further uses, yes? Commented Mar 19, 2012 at 20:37
  • 4
    Also I should emphasize that when I say slight, I mean super-tiny. "Because of performance" is not a reason to go switching from one representation to the other, it's just a neat thing worth knowing about the runtime. Commented Mar 19, 2012 at 20:38
  • 5
    It should also be noted that the performance aspect is only true for compilation. As both compile down to the same IL, the runtime performance should is identical.
    – lzcd
    Commented Mar 19, 2012 at 22:06
  • 1
    that performance boost would only be on compile Commented Mar 19, 2012 at 22:31

string.Empty wins in a really corner case, which can lead to some magical bug and really hard to debug:

If there is a zero width space in "".


According to some documentation I found, it has to do with what's emitted by the compiler.

A quick search reveals : http://stylecop.soyuz5.com/SA1122.html

Why it's filed under "Readability Rules" with that description is puzzling.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.