string = "" or = string.Empty?

  • Thread starter Thread starter Sami
  • Start date Start date
string str = string.Empty is the proper and more efficient way.

Thanks,
Click to expand...

Well, it's not more efficient as they are both string literals, but the
code more closely resembles the intention.

If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.
 
Well, it's not more efficient as they are both string literals, but the
code more closely resembles the intention.

If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.
Click to expand...

I've been told that string.Empty does not require any user memory, and
every time you reference "" you use a little bit more user memory to
store the literal.
 
[...]
If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.
Click to expand...

I've been told that string.Empty does not require any user memory, and
every time you reference "" you use a little bit more user memory to
store the literal.
Click to expand...

You've been told wrong then. At worst, all uses of the explicit literal
"" will use the same object, due to string pooling (I think in C# they
call it interning...same thing).
Click to expand...

Evenif the references are in difference classes in the same project?
 
Although I prefer the latter of the two, I don't think it makes much
difference.

Personally, I would use string.Length == 0.
 
Joe said:
[...]
If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.
I've been told that string.Empty does not require any user memory, and
every time you reference "" you use a little bit more user memory to
store the literal.
Click to expand...
You've been told wrong then. At worst, all uses of the explicit literal
"" will use the same object, due to string pooling (I think in C# they
call it interning...same thing).
Click to expand...

Evenif the references are in difference classes in the same project?
Click to expand...

Even different classes residing in different assemblies loaded in
different app domains.

Arne
 
Göran Andersson said:
Well, it's not more efficient as they are both string literals, but the
code more closely resembles the intention.

If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.
Click to expand...

The classic reason for using names instead of values is
that if you want to change the value, then you only need
to change it one place.

Very good reason. But it does not apply here. You will
never want to change the value of the empty string.

And "" is actually easier to read, so I will consider that
the proper way.

You could forget to put something within the "" but you could
also forget to write something instead of String.Empty - I can
not see the difference.

Arne
 
The classic reason for using names instead of values is
that if you want to change the value, then you only need
to change it one place.

Very good reason. But it does not apply here. You will
never want to change the value of the empty string.

And "" is actually easier to read, so I will consider that
the proper way.

You could forget to put something within the "" but you could
also forget to write something instead of String.Empty - I can
not see the difference.

Arne
Click to expand...

I personally like to use "", because sometimes you can mistake
string.Empty for being null.
It's essentially the same thing, although there might be some
difference under the hood.
But I believe that string.Empty just does = "", so it's just one more
level of redirection (although I have to check up on the value of
string.Empty)
If you have a doubt about what something does in the .NET Framework,
just google for DotNetReflector and download it. It's a great program
that uses reflection to disassemble the IL code of any .NET assembly
(including mscorlib and the like) and then convert it to C# or some
other languages (although some code is obfuscated).
 
Jonathan said:
Although I prefer the latter of the two, I don't think it makes much
difference.

Personally, I would use string.Length == 0.
Click to expand...
And if FxCop is to be believed this is actually the most efficient way --
but it's only applicable if you know the value isn't null. Of course,
there's String.IsNullOrEmpty() for such cases.

Personally, I've never understood why it should make any difference at all.
If the compiler and the jitter don't treat these things as equivalent,
they're the ones that suck, not my code. Making the programmer worry about
the best way to test if strings are empty is not a good division of
responsibilities.

Take a look at http://dotnetperls.com/Content/Empty-String.aspx. Now think
about this: what cool things have you shipped lately that depended on how
fast you tested for empty strings? Do you find programming more enjoyable
worrying about this? Would you enjoy keeping track of a moving target if the
characteristics change in another release of the framework?
 
Peter said:
But since the original question was about _assigning_ strings, not
comparing them, whether FxCop is correct or not doesn't matter. It has
no bearing on what the "preferred" way to _assign_ an empty string to a
variable would be.

I do agree with everything else you wrote. Surely the question of
comparing empty strings is significant only in a particularly unusual
program. But that's not what the OP was asking about. :)
Click to expand...
Yes, we're going off on a tangent. But for assigning, I'd like to think the
same line of reasoning applies. Assigning either "" or String.Empty should
make no difference whatsoever (and in this case, unlike empty string
testing, I think it actually doesn't, but I'm not well-versed in CLR
internals enough to positively state it). I suppose you can think of
String.Empty as the language-independent way of writing the empty string
literal -- just in case your language designer forgot to supply a way to
write one...
 
I personally like to use "", because sometimes you can mistake
string.Empty for being null.
It's essentially the same thing, although there might be some
difference under the hood.
But I believe that string.Empty just does = "", so it's just one more
level of redirection (although I have to check up on the value of
string.Empty)
If you have a doubt about what something does in the .NET Framework,
just google for DotNetReflector and download it. It's a great program
that uses reflection to disassemble the IL code of any .NET assembly
(including mscorlib and the like) and then convert it to C# or some
other languages (although some code is obfuscated).
Click to expand...

Empty is a readonly member variable of the String class which is set in
String's default constructor as an empty string literal (IE: ""). But, just
because it is a member variable does NOT mean it isn't treated differently
by the compiler and compiled into more efficient code depending on how it's
called.

HTH,
Mythran
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

String.Empty or "" 14
I read a programming handbok and they recomment to use String.Empty instead of "" . I can't see why 9
String and StringBuilder 28
Supported cultures on an OS? CultureInfo.GetCultures won't work... 0
Initializing variables? 1
Regex woes 8
Null Object Error. Driving me crazy. Please, help me out ... 2
string.Empty 40

Back
Top