In C#, I want to initialize a string value with an empty string.
How should I do this? What is the right way, and why?
string willi = string.Empty;
I have personally witnessed "" resulting in (minor) problems twice. Once was due to a mistake of a junior developer new to team-based programming, and the other was a simple typo, but the fact is using string.Empty would have avoided both issues.
Yes, this is very much a judgement call, but when a language gives you multiple ways to do things, I tend to lean toward the one that has the most compiler oversight and strongest compile-time enforcement. That is not "". It's all about expressing specific intent.
If you type string.EMpty or Strng.Empty, the compiler lets you know you did it wrong. Immediately. It simply will not compile. As a developer you are citing specific intent that the compiler (or another developer) cannot in any way misinterpret, and when you do it wrong, you can't create a bug.
If you type " " when you mean "" or vice-versa, the compiler happily does what you told it to do. Another developer may or may not be able to glean your specific intent. Bug created.
Long before string.Empty was a thing I've used a standard library that defined the EMPTY_STRING constant. We still use that constant in case statements where string.Empty is not allowed.
Whenever possible, put the compiler to work for you, and eliminate the possibility of human error, no matter how small. IMO, this trumps "readability" as others have cited.
Specificity and compile time enforcement. It's what's for dinner.
I use "" because it will be colored distinctively yellow in my code... for some reason String.Empty is all white in my Visual Studio Code theme. And I believe that matters to me the most.
I performed this very simple test using following method in a console application:
private static void CompareStringConstants()
{
string str1 = "";
string str2 = string.Empty;
string str3 = String.Empty;
Console.WriteLine(object.ReferenceEquals(str1, str2)); //prints True
Console.WriteLine(object.ReferenceEquals(str2, str3)); //prints True
}
This clearly suggests that all three variables namely str1
, str2
and str3
though being initialized using different syntax are pointing to the exactly same string (of zero length) object in memory . I performed this test in .NET 4.5 console application. So internally they have no difference and it all boils down to convenience of which one you want to use as a programmer. This behavior of string class is known as string interning in .NET. Eric Lippert has a very nice blog here describing this concept.
Use whatever you and your team find the most readable.
Other answers have suggested that a new string is created every time you use ""
. This is not true - due to string interning, it will be created either once per assembly or once per AppDomain (or possibly once for the whole process - not sure on that front). This difference is negligible - massively, massively insignificant.
Which you find more readable is a different matter, however. It's subjective and will vary from person to person - so I suggest you find out what most people on your team like, and all go with that for consistency. Personally I find ""
easier to read.
The argument that ""
and " "
are easily mistaken for each other doesn't really wash with me. Unless you're using a proportional font (and I haven't worked with any developers who do) it's pretty easy to tell the difference.
The empty string is like empty set just a name that everybody uses to call ""
. Also in formal languages strings created from an alphabet that have zero length are called the empty string. Both set and string have a special symbol for it. Empty string: ε and empty set: ∅. If you want to talk about this zero length string you will call it the empty string so everybody knows exactly what you are referring to. Now in case you name it the empty string why not use string.Empty
in code, its shows the intention is explicit. Downside is that it’s not a constant and therefore not available everywhere, like in attributes. (It's not a constant for some technical reasons, see the reference source.)
The best code is no code at all:
The fundamental nature of coding is that our task, as programmers, is to recognize that every decision we make is a trade-off. […] Start with brevity. Increase the other dimensions as required by testing.
Consequently, less code is better code: Prefer ""
to string.Empty
or String.Empty
. Those two are six times longer with no added benefit — certainly no added clarity, as they express the exact same information.