String.Empty or ""

S

shapper

Hello,

On an ASP.NET MVC View I am using the following:

<%=Html.TextBox("Title", Model.Post.Title != null ? Model.Post.Title :
String.Empty)%>

In general is there a difference between using "" or String.Empty?

For example using:
String a = Model.Post.Title != null ? Model.Post.Title : String.Empty;

Or

String b = Model.Post.Title != null ? Model.Post.Title : "";

If there is no difference what is more correct to use?

Thanks,
Miguel
 
S

shapper

There is no practical difference.  String interning (a variation of string  
pooling) makes them basically the same.



If one could say that one was more correct than the other, then there  
would be a difference.  :p

Pete

Thank You Pete.
Miguel
 
H

Hillbilly

String.IsEmptyOrNull does it all in one operation.


There is no practical difference. String interning (a variation of string
pooling) makes them basically the same.



If one could say that one was more correct than the other, then there
would be a difference. :p

Pete

Thank You Pete.
Miguel
 
A

Arne Vajhøj

shapper said:
For example using:
String a = Model.Post.Title != null ? Model.Post.Title : String.Empty;

Or

String b = Model.Post.Title != null ? Model.Post.Title : "";

If there is no difference what is more correct to use?

There will be a difference the day the decide to make the
empty string something else than "".

:)

The code does the same thing and I believe that String.Empty
is an absurdity that should never have been invented.

Arne
 
C

Cowboy \(Gregory A. Beamer\)

There is no functional difference. That being said, I prefer string.Empty,
as it is more clear what my intention is. You decide what is easiest for
you.

--
Gregory A. Beamer
MCP: +I, SE, SD, DBA

*********************************************
| Think outside the box!
|
*********************************************
 
C

Cor Ligthert[MVP]

Cowboy (Gregory A. Beamer) said:
There is no functional difference. That being said, I prefer string.Empty,
as it is more clear what my intention is. You decide what is easiest for
you.
And I prefer more "", because I don't like functions which are longer to
type and do exactly the same behind the scene.

Those functions come in my ideas from the days that a string was not a value
type but a byte array and therefore more complex to test.

As "" is used nobody asks what it does, while with Empty you see already
here that people are thinking about it.

:)

Cor
 
T

Tom Shelton

And I prefer more "", because I don't like functions which are longer to
type and do exactly the same behind the scene.

Those functions come in my ideas from the days that a string was not a value
type but a byte array and therefore more complex to test.

String is not a value type. It has some behaviors that are similar - but, it
is still a reference type.
As "" is used nobody asks what it does, while with Empty you see already
here that people are thinking about it.

I prefere string.Empty myself.
 
A

Arto Viitanen

Tom said:
I prefere string.Empty myself.

I also prefer String.Empty, since for example in code

dog = "";
cat = " ";
mouse = "";

the difference of cat to others is harder to notice.
 
G

Göran Andersson

shapper said:
Hello,

On an ASP.NET MVC View I am using the following:

<%=Html.TextBox("Title", Model.Post.Title != null ? Model.Post.Title :
String.Empty)%>

In general is there a difference between using "" or String.Empty?

For example using:
String a = Model.Post.Title != null ? Model.Post.Title : String.Empty;

Or

String b = Model.Post.Title != null ? Model.Post.Title : "";

If there is no difference what is more correct to use?

Thanks,
Miguel

The only practical difference is that String.Empty already exists in the
mscorlib.dll, while the "" string will be added to your assembly.
However, if you use "" more than once in your code it will reuse the
same string, so there will never be more than one literal "" string in
your assembly. So the added data is absolutely nothing to be concerned
about.

There are however two reasons to use String.Empty rather than "" in your
code:

1. It's clearer that you actually mean an empty string and not just
started typing something and forgot to write anything in the string. If
you always use String.Empty for empty strings you can easily spot a
string that may be unintentionally left empty.

2. The difference between the empty string "" and strings like " " and
"'" is not very obvious. If you use String.Empty the difference is
really very obvious.
 
A

Arto Viitanen

Arne said:
The code does the same thing and I believe that String.Empty
is an absurdity that should never have been invented.

I guess it is the same reason why there are Decimal.Zero, Byte.MinValue,
Boolean.FalseString etc. And yes, I don't know the reason either.
 
P

Patel

Hello,

On an ASP.NET MVC View I am using the following:

<%=Html.TextBox("Title", Model.Post.Title != null ? Model.Post.Title :
String.Empty)%>

In general is there a difference between using "" or String.Empty?

For example using:
String a = Model.Post.Title != null ? Model.Post.Title : String.Empty;

Or

String b = Model.Post.Title != null ? Model.Post.Title : "";

If there is no difference what is more correct to use?

Thanks,
Miguel

Better you use String.Empty rather than "", because while you typing
"" in case if you add extra space to this like " ", then you wont get
the expected results(Because String.Empty != " ").
I will give you an another example :
if (value == 1) or if (1 == value)
which one you prefer? (if (1 == value) right?) .
in first example : (if (value == 1)) if we forget one =, this will be
assignment stmnt.
In second example, if you do the same mistake, it will give the
compiler error.

So less chance to do mistake...

--Patel
 
H

Hans Kesting

Patel formulated the question :
I will give you an another example :
if (value == 1) or if (1 == value)
which one you prefer? (if (1 == value) right?) .
in first example : (if (value == 1)) if we forget one =, this will be
assignment stmnt.
In second example, if you do the same mistake, it will give the
compiler error.

So less chance to do mistake...

--Patel

That is true in C/C++, because that doesn't have a 'bool' type.
The C# compiler catches that "if (value = 1)" with an error: "Cannot
implicitly convert type 'int' to 'bool'".

You could still get into problems with boolean variables:
if (boolVar = true) ..
(although you still get a compiler warning)
but that is better written as:
if (boolVar) ..

Hans Kesting
 
B

Ben Voigt [C++ MVP]

Arto said:
I guess it is the same reason why there are Decimal.Zero,
Byte.MinValue, Boolean.FalseString etc. And yes, I don't know the
reason either.

Byte.MinValue is part of a pattern -- if you are given typeof(SomeType), you
can ask what its MinValue is and write code that handles both signed and
unsigned types. I'd guess this is very handy for the XML serializer (for
example).

Boolean.FalseString might change with locale.

String.Empty is useful because String is actually a reference type even
though its behavior is very similar to value type semantics. So
String.Empty is actually equal to String.Empty reference-wise as well as
value-wise. The same isn't true for empty strings created at runtime (e.g.
new StringBuilder().ToString()).
 
B

Ben Voigt [C++ MVP]

Hans said:
Patel formulated the question :

That is true in C/C++, because that doesn't have a 'bool' type.

C++ has a bool type. But many things convert to bool implicitly.
The C# compiler catches that "if (value = 1)" with an error: "Cannot
implicitly convert type 'int' to 'bool'".

You could still get into problems with boolean variables:
if (boolVar = true) ..
(although you still get a compiler warning)
but that is better written as:
if (boolVar) ..

But neither method helps with

if (boolA = boolB) ...

Good we have a warning then. And if you meant assignment you can say:

if (true == (boolA = boolB)) ...
 

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

Top