string.Empty vs null.Which one do you use?

Question

Recently a colleague at work told me not to use string.Empty when setting a string variable but use null as it pollutes the stack?

He says don't do

string myString=string.Empty; but do string mystring=null;

Does it really matter? I know string is an object so it sort of makes sense.

I know is a silly question but what is your view?

Solution 1

null and Empty are very different, and I don't suggest arbitrarily switching between them. But neither has any extra "cost", since Empty is a single fixed reference (you can use it any number of times).

There is no "pollution" on the stack caused by a ldsfld - that concern is.... crazy. Loading a null is arguably marginally cheaper, but could cause null-reference exceptions if you aren't careful about checking the value.

Personally, I use neither... If I want an empty string I use "" - simple and obvious. Interning means this also has no per-usage overhead.

---

At the IL level, the difference here between "" and Empty is just ldstr vs ldsfld - but both give the same single interned string reference. Furthermore, in more recent .NET versions the JIT has direct interception of these, yielding the empty string reference without actually doing a static field lookup. Basically, there is exactly no reason to care either way, except readability. I just use "".

Solution 2

It doesn't 'pollute the stack', there's no technical reason but there is a big difference between setting a variable to a reference to an object (even if it's an empty string) and null. They are not the same thing and should be used in different ways.

null should be used to indicate the absence of data, string.Empty (or "") to indicate the presence of data, in fact some empty text. Is there a specific case where you're not sure what is the most appropriate?

Edit, added examples:

• You might use string.Empty as the default postfix for a person's name (most people don't have PhD for example)

• You might use null for a configuration option that wasn't specified in the config file. In this case, string.Empty would be used if the config option was present, but the desired configured value was an empty string.

Solution 3

They are different as others already answered.

static void Main(string[] args)
{
    string s1 = null;
    string s2 = string.Empty;
    string s3 = "";
    Console.WriteLine(s1 == s2);
    Console.WriteLine(s1 == s3);
    Console.WriteLine(s2 == s3);
}

Results:

1. false - since null is different from string.empty
2. false - since null is different from ""
3. true - since "" is same as string.empty

The problem with managing empty string vs. null strings is becoming a problem when you need to either persist it into a flat file or transfer it through communications, So I find it might be useful for other who visit this page to give a nice solution to that particular problem.

For the purpose of saving strings into a file or communications:
you will probably want to convert the string into bytes.
a good practice I recommend is to add 2 segments of header bytes to your converted string.

segment 1 - meta info which is stored in 1 byte and describes the length of the the next segment.

segment 2 - holds the length of the string to be saved.

example:
string "abcd" - to simplify I'll convert it using ASCII encoder and will get {65,66,67,68}.
calculate segment 2 will yield 4 - so 4 bytes are the length of the converted string.
calculate segment 1 will yield 1 - as just 1 byte was used to hold the length information of the converted string information (which was 4, i.e. if it was 260 I would get 2)

The new stripe of bytes will now be {1,4,65,66,67,68} which can be saved to a file.

The benefit in respect to the subject is that if I had an empty string to save I would get from conversion an empty array of bytes in the length of 0 and after calculating the segments I will end up having {1,0} which can be saved and later on loaded and interpreted back into an empty string. On the other hand if I had null value in my string I would end up having just {0} as my byte array to save and again when loaded can be interpreted back to null.

There are more benefits such as knowing what the size to be loaded or accumulate if you jag multiple strings.

Back to the subject - it will.. well kind of pollute the stack as the same principals described are being used by any system to differentiate nulls from empty.. so yes string.Empty does take more memory than null, though I wouldn't call it pollution.. it just 1 more byte.

Solution 4

It's been answered to death, but null means no value, not initialized. string.Empty means "" (a blank string) as it is stated on MSDN.

The safest way to check for an empty or null string is using string.IsNullOrEmpty.

View more solutions

Comments

[Miserable Variable]

@Marc +1 for null and Empty are very different. Not differentiating between the two results in the abominable if (str != null && !str.equals("")

[user712923]

I never thought that way ,I have to admit.Given what you just said ,do you mind to give me an example.I know your explanation is self explanatory but still... thanks

[user712923]

thanks for your answer.The reason I ask is because the tone used by my collegue when talking was more of a telling off one rather than an informative one,so I said to myself let me ask on stackoverflow.

[Kieren Johnstone]

Well, the only reason to choose one or the other is based on the place you would use it. I.e. use string.Empty or "" when you want to use an empty string and null when you want to indicate there is no data. You might use string.Empty as the default postfix for a person's name (most people don't have PhD for example) - and null for a configuration option that wasn't specified in the config file. In that second case, string.Empty would be used if the config option was present, but the desired configured value was an empty string.

[Marc Gravell]

@user712923 if he comes back with any concrete concerns, I'd love to hear them

[Jalal Said]

@Marc: ASAIK "" creates an object where string.Empty is not.. check this and this. It have something to do with string intern pool....

[Marc Gravell]

@Jalal - the difference is slight, and may even change between implementations. Either way, it isn't a string instance per usage

[Vinko Vrsalovic]

@Hemal: String.IsNullOrEmpty()

[Konrad Rudolph]

+1 for using "" instead of a six times longer boilerplate code. Whoever advocated this nonsense?! @Jalal That Brad Abrams posting is seriously outdated and if the compiler still doesn’t optimise those two codes to do the same, then shame on Microsoft! But it’s not our job to fix their work. And in fact, we don’t need to: In the second link, Lasse (in the comments) has compared the assembly outputs of comparing with either variant: they are identical.

[Jalal Said]

@Konrad: One example is what is happening when concatenate constant strings: the string class uses intern pool so when you make a new string, the class check if the string is already in the pool and then if not added it to the pool.. Because of that when "" it will search the entire pool to check if it already there or not, and that is way when using the string.Empty; it will use that predefined value and the search will no longer exists. the class also exposeed this methods: string.Intern/IsInterned check this

[Konrad Rudolph]

@Jalal This article is also completely outdated, and I doubt much of it still applied now. It’s a trivial optimization for the compiler/JIT to intern "". Furthermore, checking the string interning pool is a very cheap operation, no “search[ing of] the entire pool” happens.

[Jalal Said]

@Konrad: it is not a big deal after all, really, but for me it is just that not every time create new "" where I have a static variable out there. Imagine you have a static field in Image class called Image.Empty then I will certainly not use new Image(1, 1) for example.. it is also not about how many characters the code is..

[Konrad Rudolph]

@Jalal Notice how I’m not advocating using new String(new char[]{}) so your comparison doesn’t really work. Furthermore: “it is also not about how many characters the code is” – no: in a way, it is. Unnecessary code leads to visual clutter, reducing legibility.

[Marc Gravell]

@Jalal it doesnt matter how many times I use the literal "" in an assembly - that is one single string instance. Any comparison to new Image(...) is meaningless

[Jalal Said]

@Marc: The Image.Empty example here just to demonstrate the code reusability. when I have a static field that already declared there I will use it.

[Miserable Variable]

@Vinko see other explanations here why differentiating between null and empty string is a good thing.

[Marc Gravell]

@Jalal even if it (subjectively, perhaps) makes the code less readable and obvious, with no extra efficiency to warrant it?

[Vinko Vrsalovic]

@Hemal I was specifically referring to your abonimable code snippet.

[Miserable Variable]

@Vinko understood. I had meant that the need for such checks is abominable, not the code itself. Speaking as one who has to daily use his handwritten StringUtils.isNullOrEmpty(String) (in Java) :)

[zanlok]

Yes. This is why we should all remain in the habit of checking .Length==0 or using .Compare()

[Cole Tobin]

This question asks about c# not js

[OfirD]

@Kieren Johnstone, if one has no postfix name, why wouldn't use null to indicate "no postfix"?