string.Empty or String.Empty or ""?

[Charlie@CBFC]

Hi:

Is there any difference between string.Empty and String.Empty? And what is
the benefit of using it over "".

Thanks,
Charlie

[dma...@gmail.com]

Nope, there's no difference between the two. They're exactly the same.

The benefit of using either over "" is (I think) debatable. It sort of
depends on what you like. I guess with [sS]tring.Empty, you stand less
of a chance of messing up and making a mistake (like putting a space
between the quotes or something). I personally use String.Empty, and I
have some colleagues that are adamant about using it over "", but I
think it's a debate of minor importance, as there's no functional
difference.

-Dave

[Otis Mukinfus]

I think using string.Empty leaves no doubt regarding what you mean.
Therefore I use it instead of "".

Having been a debugger for most of my career in the programming biz, I
find it important to leave as little doubt as possible in your code.
maintenance programmers will appreciate it.

Otis Mukinfus
http://www.otismukinfus.com
http://www.tomchilders.com

[Mark R. Dawson]

Hi Charlie,
the difference between String.Empty and "" is minimal. I believe the only
difference is that "" will create a string object and String.Empty does not,
however the "" object is probably pulled from the string pool (string
interning) so in reality there is no difference, sinc ethere will only ever
be one instance of it.

It probably comes down to personal preference, I personally like to put
String.Empty since to me it is clearer than "" to read, but this is minial as
well.

Mark.
http://www.markdawson.org

[john smith]

To know for sure, you'd have to look at the MSIL (or resulting native
code from the MSIL even).

== "" implies a string comparison (same idea as a "repe cmpsb" between 2
strings in x86 asm - although it's done differently nowadays). Not sure
if the zero length string is created/allocated on the stack either...

== String.Empty implies a [zero] length check which is usually faster.
(Haven't looked how they've implemented it though...)

Chances are the compiler will replace (optimize) your == "" into the
same thing as == String.empty checks anyways (i.e. produce the same MSIL).

If performance of that specific code is an issue (from profiling your
code), then you can benchmark the 2 and use the faster one (if there is
one). Otherwise, you might as well use what is more legible, easier to
maintain and such.

I'm not 100% sure on the String/string difference though (can't recall
for sure).

There are even more options though...

== ""
== String.Empty
whatever.Equals(String.Empty)
whatever.Length == 0 [that's what I usually use]

And I just might be forgetting more :)

[Jon Skeet [C# MVP]]

Otis Mukinfus <ph...@emailaddress.com> wrote:
> I think using string.Empty leaves no doubt regarding what you mean.
> Therefore I use it instead of "".
>
> Having been a debugger for most of my career in the programming biz, I
> find it important to leave as little doubt as possible in your code.
> maintenance programmers will appreciate it.

While I agree with the latter sentiment, I can't see anything ambiguous
about "", which I find more readable, personally.

--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

john smith <jo...@smith.com> wrote:
> To know for sure, you'd have to look at the MSIL (or resulting native
> code from the MSIL even).
>
> == "" implies a string comparison (same idea as a "repe cmpsb" between 2
> strings in x86 asm - although it's done differently nowadays). Not sure
> if the zero length string is created/allocated on the stack either...
>
> == String.Empty implies a [zero] length check which is usually faster.

No it doesn't. It implies a string comparison with string.Empty. After
all, string.Empty is just a property which returns an empty string.

If you want a zero length check, do one explicity:

if (x.Length==0)

Of course, that has different semantics to =="" when x is null...

> (Haven't looked how they've implemented it though...)
>
> Chances are the compiler will replace (optimize) your == "" into the
> same thing as == String.empty checks anyways (i.e. produce the same MSIL).

No, they'll produce different IL, but they may be JITted to the same
native code. (I don't think they currently are, but I haven't checked.)

> If performance of that specific code is an issue (from profiling your
> code), then you can benchmark the 2 and use the faster one (if there is
> one). Otherwise, you might as well use what is more legible, easier to
> maintain and such.

This is very important. I doubt that many people (if any) have
*actually* been in a real situation where changing the type of
comparison has made a signficant difference in their application.

> I'm not 100% sure on the String/string difference though (can't recall
> for sure).

None whatsoever - they compile to the same IL.