Why, oh why.

[Frank Rizzo]

I've seen recently some programmers using

string s = String.Empty;

instead of traditional

string s = "";

Is there any logical reason for this or just OOP snobbery?
Regards

 

[Siva M]

Some use it for better readability.

I've seen recently some programmers using

string s = String.Empty;

instead of traditional

string s = "";

Is there any logical reason for this or just OOP snobbery?
Regards

 

[Nicholas Paldino [.NET/C# MVP]]

Frank,

It's OOP snobbery, and I whole-heartedly subscribe to it =)

 

[Mythran]

I've seen recently some programmers using

string s = String.Empty;

instead of traditional

string s = "";

Is there any logical reason for this or just OOP snobbery?
Regards

Why use it? Well, sometimes it's a little more difficult to read "'""'"
than it is to read "'" & String.Empty & "'". That's just one reason...there
are others...but if you go along these lines, then for consistency,
String.Empty would be the way to go as well

Is it snobbery? Sure can be...I know I use it for that
reason...snobbery...what a word

Mythran

 

[Jay B. Harlow [MVP - Outlook]]

Frank,
When I use it, I use it for "consistency" with other types. A "Empty
Pattern" if you will (would the "Empty Pattern" be OOP snobbery?)

Such as:

String.Empty

CounterSample.Empty
XmlQualifiedName.Empty
EventArgs.Empty
Color.Empty
Guid.Empty
Rectangle.Empty
Point.Empty
AttributeCollection.Empty

....

A search for Empty on MSDN returns a plethora of other Types that have Empty
fields or properties.

NOTE: I'm not totally consistent with using String.Empty vs. "".

Hope this helps
Jay

| I've seen recently some programmers using
|
| string s = String.Empty;
|
| instead of traditional
|
| string s = "";
|
| Is there any logical reason for this or just OOP snobbery?
| Regards

 

[Frank Rizzo]

Frank,
When I use it, I use it for "consistency" with other types. A "Empty
Pattern" if you will (would the "Empty Pattern" be OOP snobbery?)

Such as:

String.Empty

CounterSample.Empty
XmlQualifiedName.Empty
EventArgs.Empty
Color.Empty
Guid.Empty
Rectangle.Empty
Point.Empty
AttributeCollection.Empty

Ah, the string type is a different league than color, guid, point,
etc... String is a fundamental type, while the others are not. You can
write very complex software and not use Point or Guild or
AttributeCollection ones. Try and do that without the string data type.

I am very productivity driven. I always seek out ways to type less, so
String.Empty makes no sene to me. I view String.Empty vs "" the same
way I view the term Refactoring: a 10 dollar word which five years ago
simply meant moving your code around a bit.

 

[Jay B. Harlow [MVP - Outlook]]

Frank,
| Ah, the string type is a different league than color, guid, point,
| etc... String is a fundamental type, while the others are not.
Yes its a fundamental type, however my statement is questions if it should
it be treated as such? Considering there is potentially an "Empty Pattern"
lurking in the framework?

| You can
| write very complex software and not use Point or Guild or
| AttributeCollection ones. Try and do that without the string data type.
OK. How does that apply to a potential "Empty Pattern" usage or not?

My point is, at a certain level using String.Empty and Point.Empty or simply
the "Empty Pattern", avoids an "Oddball Solution", where using "" to mean
empty for some types & using .Empty to mean "empty" for other types is
potentially an Oddball Solution. Note Empty here does not mean Nothing!

Hope this helps
Jay

| Jay B. Harlow [MVP - Outlook] wrote:
| > Frank,
| > When I use it, I use it for "consistency" with other types. A "Empty
| > Pattern" if you will (would the "Empty Pattern" be OOP snobbery?)
| >
| > Such as:
| >
| > String.Empty
| >
| > CounterSample.Empty
| > XmlQualifiedName.Empty
| > EventArgs.Empty
| > Color.Empty
| > Guid.Empty
| > Rectangle.Empty
| > Point.Empty
| > AttributeCollection.Empty
|
| Ah, the string type is a different league than color, guid, point,
| etc... String is a fundamental type, while the others are not. You can
| write very complex software and not use Point or Guild or
| AttributeCollection ones. Try and do that without the string data type.
|
| I am very productivity driven. I always seek out ways to type less, so
| String.Empty makes no sene to me. I view String.Empty vs "" the same
| way I view the term Refactoring: a 10 dollar word which five years ago
| simply meant moving your code around a bit.
|
| >
| > ....
| >
| > A search for Empty on MSDN returns a plethora of other Types that have
Empty
| > fields or properties.
| >
| > NOTE: I'm not totally consistent with using String.Empty vs. "".
| >
| > Hope this helps
| > Jay
| >
| > | > | I've seen recently some programmers using
| > |
| > | string s = String.Empty;
| > |
| > | instead of traditional
| > |
| > | string s = "";
| > |
| > | Is there any logical reason for this or just OOP snobbery?
| > | Regards
| >
| >

 

[Michael S]

Ah, the string type is a different league than color, guid, point, etc...
String is a fundamental type, while the others are not. You can write
very complex software and not use Point or Guild or AttributeCollection
ones. Try and do that without the string data type.

I am very productivity driven. I always seek out ways to type less, so
String.Empty makes no sene to me.

I Agree
- Michael S

 

[Michael S]

I've seen recently some programmers using

string s = String.Empty;

instead of traditional

string s = "";

Is there any logical reason for this or just OOP snobbery?
Regards

It's snobbery that will fight you.
As a string is a reference-type an instance can be null or empty.
Hence you often need to check for both. You often see code like

if ((myStr != null) && (myStr != String.Empty)) //.C# 1.1
if (myStr != String.NullOrEnpty) //.C# 2.0

I tend to avoid that crap by always setting my own allocated strings to ""
and never let them be null.
Then I can code more C-stylish by just checking for the former

if (myString != "")

Saves a lot of time. However, one must be very careful with strings you get
from .NET framework.
In our shop we have written a StringUtil.AsString(string str) that never
returns null. Saves a lot of headaches.

That strings can be null sucks. Why didn't Hjelsberg do it the Delphi way
and let "" be equal to null. Bet he tried but couldn't convince the .NET
team to do it that way. But I consider this a design-flaw as bad as Visual
Basic 6 four magic constants of the apocalypse (Verity Stob) - Nothing,
Null, Empty and Error idioticy.

Mina 2 öre
- Michael S

 

[erick]

System.String.Empty is a static readonly public field. When you call it from
any part of your application, there is no extra allocation of a new string
since there is only one protected copy that is shared among everyone. Every
time you use "" you are allocating a new string instead of using System.String.Empty.
Even though string are classes, they are imutables so everytime you reasing
the "" it is creating a new copy.
Empty, MinValue, MaxValue...etc are not only good ways to keep a standard
of your default values but also to "reuse" them without extra memory allocation.

Erick Sgarbi

 

[Jay B. Harlow [MVP - Outlook]]

Erick,
| Every
| time you use "" you are allocating a new string instead of using
System.String.Empty.
String literals are interned. Every time you use "" you are receiving the
exact same string instance as String.Empty!

Try the following code:

object s1 = String.Empty;
object s2 = "";
object s3 = new string('\0', 0);
Debug.WriteLine(s1 == s2, "s1 == s2");
Debug.WriteLine(s1 == s3, "s1 == s3");


s1 == s2 as they are the same instance, while s1 != s3 as they are different
instances. Using object variables forces the compiler to use object
references instead of the String overloaded operators.

Hope this helps
Jay

|
| System.String.Empty is a static readonly public field. When you call it
from
| any part of your application, there is no extra allocation of a new string
| since there is only one protected copy that is shared among everyone.
Every
| time you use "" you are allocating a new string instead of using
System.String.Empty.
| Even though string are classes, they are imutables so everytime you
reasing
| the "" it is creating a new copy.
| Empty, MinValue, MaxValue...etc are not only good ways to keep a standard
| of your default values but also to "reuse" them without extra memory
allocation.
|
| Erick Sgarbi
|
| > I've seen recently some programmers using
| >
| > string s = String.Empty;
| >
| > instead of traditional
| >
| > string s = "";
| >
| > Is there any logical reason for this or just OOP snobbery? Regards
| >
|
|

 

[Jon Skeet [C# MVP]]

That strings can be null sucks.

On the contrary. I find it really, really useful to be able to
distinguish between a variable which has been set to an empty string,
and one which has been set to a null value. They can often be
semantically *very* different.

 

[Frank Rizzo]

On the contrary. I find it really, really useful to be able to
distinguish between a variable which has been set to an empty string,
and one which has been set to a null value. They can often be
semantically *very* different.

I agree with your reasoning, however, cases where string needs to be
null are very few and far in between. Perhaps there should have been a
nullable string class NullableString and leave the System.String as
non-nullable.

 

[Jon Skeet [C# MVP]]

I agree with your reasoning, however, cases where string needs to be
null are very few and far in between. Perhaps there should have been a
nullable string class NullableString and leave the System.String as
non-nullable.

I find I need a nullable string more often than I need nulls of most
other types - Forms, Streams, Encodings etc. Personally, I don't find
it a problem at all that strings can be null - just like other
parameters etc, you need to check them in appropriate places if only
certain values are valid.

Of course, this is where something like Spec# comes in handy...

 

[Michael S]

I find I need a nullable string more often than I need nulls of most
other types - Forms, Streams, Encodings etc. Personally, I don't find
it a problem at all that strings can be null - just like other
parameters etc, you need to check them in appropriate places if only
certain values are valid.

Of course, this is where something like Spec# comes in handy...

Well, I mostly do web applications and 99% of the strings I allocate is for
HTML output.
I think most asp.net devs are quite sick and tired of all them null pointer
exceptions you always get when fast-coding.

I also do a lot of import/export using XML. It's a nightmare. if a node is
missing on a xpath-expression you get the darn null again. It is so useless.
Of course we made our own XML-wrapper that never yeilds a null. Problem
solved ugly.

I agree theer are cases where you could find it useful for a nullable
string. But those cases are way far inbetween your regular use of strings.
For most applications, all them if-statements and util-methods gives bloated
code and lesser performance.

In Delphi, you have primitives, records, classes and strings. String being a
magic (and pretty smart) special type.

In .NET they wanted a simple system of value-types and reference-types and
had to cram the string in either two. Strings then wind up naturally as a
reference-type. But I think this was the wrong thing to do. I'd rather see
value-types, reference-types and magic-types. The simple dualistic approach
we got now is a pain in the arse.

Too bad they didn't come up with nullable types from scratch. That would
have saved the day. Then we could have string and string?. a cast between a
null string? to string would yeild "". That would have been pretty neat.

Guess it's too late for that now...

Happy Nulling
- Michael S

 

[Michael S]

Every > time you use "" you are allocating a new string instead of using
System.String.Empty.

This is simply not true.

if you read the specs on C# you may think this is so. Even if you read the
specs for CIL you may still believe this is what would happen. But it's not.
The CLR and the JITter could care no less about C# and CIL specs.

The CLR holds a VERY global Hashtable for all constants in the runtime. This
table are manged by CLR and hence have priviliged acess to cross application
domains. So if your application have a

myStr = myStr1 + "QWERTY" + myStr2;

and my application has

aStr = "QWERTY" + anyStr;

the CLR would have only one single copy of QWERTY in memory and the Jitter
would perform a lookup when compiling and map straight to that adress. Our
applications would share the same QWERTY.

As there are plenty of "" in most applications, the address of this empty
string would be one of the first constant to load and also combat well for a
place in hardware-cache.

Anyways, calling String.Empty does not give less performance. C# may call
that a static property getter, CIL may call it a static getter method, but
the JITter don't care, but knows CIL and the FCL all too well and will
optimize. Hence it will simply compare to "".

What you read as C# is not what's happening in the runtime.

Regards
- Michael S

 

[Bruce Wood]

I agree theer are cases where you could find it useful for a nullable

string. But those cases are way far inbetween your regular use of strings.

Not if you're reading them from databases, they aren't. As well, you
provided your own example: XML with missing nodes. A null string means
"missing". An empty string means "present and empty". They're two
different things. For database handling, I did the same thing you did
for the XML: wrote a method that reads strings and supplies a default
if missing (usually the empty string, but sometimes null). However, I
think that simply eliminating the difference would be a bad idea.

As for String.Empty, I agree with Frank, although I wouldn't use the
word "snobbery." "Pedantic," maybe. I don't care much about typing
extra characters, but it's harder to read... all to satisfy some sense
of O-O "purity." I have better things to do with my time.

 

[Jon Skeet [C# MVP]]

This is simply not true.

if you read the specs on C# you may think this is so.

You certainly shouldn't. From the C# spec:

<quote>
When two or more string literals that are equivalent according to the
string equality operator (§14.9.7), appear in the same assembly, these
string literals refer to the same string instance.
</quote>

It doesn't say whether the intern pool is per assembly, per AppDomain
or per host (I believe it's per AppDomain), only specifying that it
must be at *worst* per assembly, but it does at least specify that
much.

 

[Jon Skeet [C# MVP]]

Well, I mostly do web applications and 99% of the strings I allocate is for
HTML output.
I think most asp.net devs are quite sick and tired of all them null pointer
exceptions you always get when fast-coding.

And do you really believe that *all* the places you get
NullReferenceExceptions, you would actually want an empty string?
Removing null strings in favour of always having empty strings instead
just means you defer finding those bugs until you check whether or not
you *really, really* meant to get an empty string.

I also do a lot of import/export using XML. It's a nightmare. if a node is
missing on a xpath-expression you get the darn null again.

And you'd rather see an empty string *every* time? Again, I'd rather
find the bug early...

 

[Willy Denoyette [MVP]]

This is simply not true.

if you read the specs on C# you may think this is so.

You certainly shouldn't. From the C# spec:

<quote>
When two or more string literals that are equivalent according to the
string equality operator (§14.9.7), appear in the same assembly, these
string literals refer to the same string instance.
</quote>

It doesn't say whether the intern pool is per assembly, per AppDomain
or per host (I believe it's per AppDomain), only specifying that it
must be at *worst* per assembly, but it does at least specify that
much.



In V1.x when you load an assembly, all string literals are intern'ed, The
interning buffer is per AppDomain, but they can be intern'ed accross
AppDomains when assemblies are loaded domain neutral.
Note that v2.0 makes it possible to opt-in or opt-out of this behavior by
marking an assembly as not requiring string literal interning (see
CompilationRelaxationsAttribute NoStringInterning).

Willy.