.empty

  • Thread starter Thread starter cj
  • Start date Start date
C

cj

What is string.empty used for?

I can't say: if string.empty then
I have to use: if string = "" then

which is ok, I just want to know what .empty is for.
 
cj said:
What is string.empty used for?

I can't say: if string.empty then
I have to use: if string = "" then

which is ok, I just want to know what .empty is for.
Click to expand...

\\\
If x = String.Empty Then
...
End If
///

is semantically equivalent to

\\\
If x = "" Then
...
End If
///
 
CJ,

There are endless methods to tell that a string exist however does not
contain any character.

One of those is string.empy another one string="" and string=nothing
although that initializes.

In this newsgroup is once taken the string="" for the string without any
character.

However I would not botter to much. The only dangerous one can be the
string=nothing, because that test as well on a string that was in advance no
string (Is Nothing)

I hope this helps,

Cor
 
To add on what Herfried and Cor have already said, I prefer the use of
String.Empty to "". Yes, they're syntactically correct, but the few extra
keystrokes are worth the added clarity. Is there a space in there that I
can't see becuase of the IDE's font setting? Is one of the double quotes
really two single quotes? Better to avoid the potential for confusion and
just use String.Empty.

- Mitchell S. Honnert
 
Well, I see I typed my question a bit off again. When I posted
if string.empty

I meant it to be interpreted
if mystring.empty

which I assumed would return a True or False and it doesn't.
I didn't expect for anyone to think I meant using it like
if mystring = string.empty

But ok, I see what .empty is all about now. And I don't like it.
mystring = "" has been around for ages now an is obvious beyond any
doubt to me so I surely don't think saying mystring = string.empty is
any better. Heck I was confusing in my post. But then that's just my
opinion. :)

Thanks to everyone for explaining .empty to me!
 
cj said:
Well, I see I typed my question a bit off again. When I posted
if string.empty

I meant it to be interpreted
if mystring.empty

which I assumed would return a True or False and it doesn't.
I didn't expect for anyone to think I meant using it like
if mystring = string.empty
Click to expand...

That's because 'String.Empty' is shared.
But ok, I see what .empty is all about now. And I don't like it.
Dito.

mystring = "" has been around for ages now an is obvious beyond any doubt
to me so I surely don't think saying mystring = string.empty is any
better.
Click to expand...

Full ACK. I wonder why the VB compiler doesn't emit 'String.Empty' for
empty-string literals.
 
Herfried said:
Full ACK. I wonder why the VB compiler doesn't emit 'String.Empty' for
empty-string literals.
Click to expand...
Wouldn't that be nice - from the little I understand of I.L.Code, the
compiler does come up with something a bit different in each case (not
surprisingly).

Given ...

If s1 = String.Empty Then

.... the ILCode produced looks like:

IL_0001: ldloc.0
IL_0002: ldsfld string [mscorlib]System.String::Empty
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
....CompilerServices.StringType::StrCmp( string, string, bool )

But if you use the "old-fashioned" ...

If s1 = "" Then

.... the compiler produces this instead:

IL_0001: ldloc.0
IL_0002: ldstr ""
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
....CompilerServices.StringType::StrCmp( string, string, bool )

So does it really matter?
Is "ldstr" so much slower than "ldsfld" that "String.Empty" really is
worth all the extra typing?

<advocate owner="devil" >
Is String.Empty really so much more readible than ""?

Regards,
Phill W.
 
Phill W. said:
Full ACK. I wonder why the VB compiler doesn't emit 'String.Empty' for
empty-string literals.
Click to expand...
Wouldn't that be nice - from the little I understand of I.L.Code, the
compiler does come up with something a bit different in each case (not
surprisingly).

Given ...

If s1 = String.Empty Then

... the ILCode produced looks like:

IL_0001: ldloc.0
IL_0002: ldsfld string [mscorlib]System.String::Empty
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

But if you use the "old-fashioned" ...

If s1 = "" Then

... the compiler produces this instead:

IL_0001: ldloc.0
IL_0002: ldstr ""
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

So does it really matter?
Click to expand...

IMO no.
Is "ldstr" so much slower than "ldsfld" that "String.Empty" really is
worth all the extra typing?
Click to expand...

IMO no.
<advocate owner="devil" >
Is String.Empty really so much more readible than ""?
Click to expand...

IMO no.

However, it's true that the 'ldsfld' instruction is slightly faster than the
'ldstr' instruction. I don't see any reason for the VB compiler not to emit
'ldsfld' + 'String.Empty' instead of 'ldstr' for "", as both are
semantically equivalent and thus no problem could arise.
 
Is String.Empty really so much more readible than ""?
More readable enough that it's worth the few extra keystrokes, yes. I
personally don't get the near obsession some programmers have with saving a
few keystrokes. As a percentage of all overall development, the time it
takes to actually type the code is small. Besides, in most cases, you write
the code once, but it's read dozens of time. So, even if you take three
extra seconds to type a more explicit reference (be it String.Empty or
anything else), you more than make up for the "investment" of the single
write during the multiple reads.

Is this a big deal? Not really. I happen to prefer String.Empty to ""
because I believe the former to be a bit more clear and that's enough for
me. What I find interesting, though, is that this discussion seems to
paralel in a way the arguments of C# vs. VB.NET. C# people love that fact
that they save a few keystrokes with their cryptic language. I prefer to
type a bit extra and have my code more easilly understood by more people.
Sure, if you know C#, then you know what weird combination of punctuation
marks you have to create to get the functionality you need, but is this
in-built obfuscation really worth the relatively small savings in
keystrokes? I prefer VB.NET, so obviously I don't think so. To me, it's
like driving ten miles out of your way to save a penny per gallon on gas.

I'm not trying to start another C# vs. VB.NET holy flame war here. It's just
that the principle of "" vs String.Empty reminded me of some of the same
points, albeit on a much smaller scale.

- Mitchell S. Honnert

Phill W. said:
Herfried said:
Full ACK. I wonder why the VB compiler doesn't emit 'String.Empty' for
empty-string literals.
Click to expand...
Wouldn't that be nice - from the little I understand of I.L.Code, the
compiler does come up with something a bit different in each case (not
surprisingly).

Given ...

If s1 = String.Empty Then

... the ILCode produced looks like:

IL_0001: ldloc.0
IL_0002: ldsfld string [mscorlib]System.String::Empty
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

But if you use the "old-fashioned" ...

If s1 = "" Then

... the compiler produces this instead:

IL_0001: ldloc.0
IL_0002: ldstr ""
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

So does it really matter?
Is "ldstr" so much slower than "ldsfld" that "String.Empty" really is
worth all the extra typing?

<advocate owner="devil" >
Is String.Empty really so much more readible than ""?

Regards,
Phill W.
Click to expand...
 
For me, nothing shouts empty string like "". It's the most obvious and
readable way of denoting an empty string. My use of it has nothing to
do with typing extra keystrokes. I suspect some others feel the same
way.

And IMHO C# is not that different from VB any more. It's all getting
more cryptic and it's all beginning to take more typing--hummm, worst of
both worlds. But they're both doing more things now days like
interfacing with more databases and with the web and all this makes
things more complicated.

Is String.Empty really so much more readible than ""?
Click to expand...
More readable enough that it's worth the few extra keystrokes, yes. I
personally don't get the near obsession some programmers have with saving a
few keystrokes. As a percentage of all overall development, the time it
takes to actually type the code is small. Besides, in most cases, you write
the code once, but it's read dozens of time. So, even if you take three
extra seconds to type a more explicit reference (be it String.Empty or
anything else), you more than make up for the "investment" of the single
write during the multiple reads.

Is this a big deal? Not really. I happen to prefer String.Empty to ""
because I believe the former to be a bit more clear and that's enough for
me. What I find interesting, though, is that this discussion seems to
paralel in a way the arguments of C# vs. VB.NET. C# people love that fact
that they save a few keystrokes with their cryptic language. I prefer to
type a bit extra and have my code more easilly understood by more people.
Sure, if you know C#, then you know what weird combination of punctuation
marks you have to create to get the functionality you need, but is this
in-built obfuscation really worth the relatively small savings in
keystrokes? I prefer VB.NET, so obviously I don't think so. To me, it's
like driving ten miles out of your way to save a penny per gallon on gas.

I'm not trying to start another C# vs. VB.NET holy flame war here. It's just
that the principle of "" vs String.Empty reminded me of some of the same
points, albeit on a much smaller scale.

- Mitchell S. Honnert

Phill W. said:
Herfried said:
mystring = "" has been around for ages now an is obvious beyond any
doubt to me so I surely don't think saying mystring = string.empty is
any better.
Full ACK. I wonder why the VB compiler doesn't emit 'String.Empty' for
empty-string literals.
Click to expand...
Wouldn't that be nice - from the little I understand of I.L.Code, the
compiler does come up with something a bit different in each case (not
surprisingly).

Given ...

If s1 = String.Empty Then

... the ILCode produced looks like:

IL_0001: ldloc.0
IL_0002: ldsfld string [mscorlib]System.String::Empty
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

But if you use the "old-fashioned" ...

If s1 = "" Then

... the compiler produces this instead:

IL_0001: ldloc.0
IL_0002: ldstr ""
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

So does it really matter?
Is "ldstr" so much slower than "ldsfld" that "String.Empty" really is
worth all the extra typing?

<advocate owner="devil" >
Is String.Empty really so much more readible than ""?

Regards,
Phill W.
Click to expand...
Click to expand...
 
For me, nothing shouts empty string like ""
What do these shout to you?
"''
'"'
''"

They all look like "", but they're not. Again, this issue is rather
trivial, but it's enough to push me to use String.Empty.
And IMHO C# is not that different from VB any more. It's all getting more
cryptic and it's all beginning to take more typing--hummm, worst of both
worlds. But they're both doing more things now days like interfacing with
more databases and with the web and all this makes things more
complicated.
Click to expand...
I personally don't think that VB is getting either more complex or cryptic.
Sure, it may have been difficult for VB6 developers to transition to VB.NET,
but this isn't the proper measure of the complexity of a programming
language. I've always contended that VB.NET would be much easier than VB6
to teach a person who is completely new to programming. VB.NET, along with
the .NET Framework, may make VB *richer*, but because of the regularization
of the language and the thought put into the design of the Framework, VB is
actually less complex, not more.

As for being cryptic, I don't think even C# people would deny that their
language of choice is cryptic. (It's a point of pride.) Whereas VB will
use a word or series of words, C# will use a punctuation mark or other
single-character symbol. In other words, more cryptic. Bringing it back to
our discussion, trying googling "" and see what you get. Now try
"String.Empty". The reason that you will frequently see posts to the
languages.csharp ng asking what this or that punctuation mark means is that
the person either tried to google the punctuation mark and got a zillion
result or didn't bother googling it in the first place because they knew
they'd get a zillion results.

Remember, eschew obfuscation. :-)

- Mitchell S. Honnert


cj said:
For me, nothing shouts empty string like "". It's the most obvious and
readable way of denoting an empty string. My use of it has nothing to do
with typing extra keystrokes. I suspect some others feel the same way.

And IMHO C# is not that different from VB any more. It's all getting more
cryptic and it's all beginning to take more typing--hummm, worst of both
worlds. But they're both doing more things now days like interfacing with
more databases and with the web and all this makes things more
complicated.

Is String.Empty really so much more readible than ""?
Click to expand...
More readable enough that it's worth the few extra keystrokes, yes. I
personally don't get the near obsession some programmers have with saving
a few keystrokes. As a percentage of all overall development, the time
it takes to actually type the code is small. Besides, in most cases, you
write the code once, but it's read dozens of time. So, even if you take
three extra seconds to type a more explicit reference (be it String.Empty
or anything else), you more than make up for the "investment" of the
single write during the multiple reads.

Is this a big deal? Not really. I happen to prefer String.Empty to ""
because I believe the former to be a bit more clear and that's enough for
me. What I find interesting, though, is that this discussion seems to
paralel in a way the arguments of C# vs. VB.NET. C# people love that
fact that they save a few keystrokes with their cryptic language. I
prefer to type a bit extra and have my code more easilly understood by
more people. Sure, if you know C#, then you know what weird combination
of punctuation marks you have to create to get the functionality you
need, but is this in-built obfuscation really worth the relatively small
savings in keystrokes? I prefer VB.NET, so obviously I don't think so.
To me, it's like driving ten miles out of your way to save a penny per
gallon on gas.

I'm not trying to start another C# vs. VB.NET holy flame war here. It's
just that the principle of "" vs String.Empty reminded me of some of the
same points, albeit on a much smaller scale.

- Mitchell S. Honnert

Phill W. said:
Herfried K. Wagner [MVP] wrote:
. . .
mystring = "" has been around for ages now an is obvious beyond any
doubt to me so I surely don't think saying mystring = string.empty is
any better.
Full ACK. I wonder why the VB compiler doesn't emit 'String.Empty' for
empty-string literals.

Wouldn't that be nice - from the little I understand of I.L.Code, the
compiler does come up with something a bit different in each case (not
surprisingly).

Given ...

If s1 = String.Empty Then

... the ILCode produced looks like:

IL_0001: ldloc.0
IL_0002: ldsfld string [mscorlib]System.String::Empty
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

But if you use the "old-fashioned" ...

If s1 = "" Then

... the compiler produces this instead:

IL_0001: ldloc.0
IL_0002: ldstr ""
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

So does it really matter?
Is "ldstr" so much slower than "ldsfld" that "String.Empty" really is
worth all the extra typing?

<advocate owner="devil" >
Is String.Empty really so much more readible than ""?

Regards,
Phill W.
Click to expand...
Click to expand...
Click to expand...
 
Mitchell,

Simple question, What do you do if you have to set a single quote in a
string.

"'" you have than in my idea the same problem. Therefore I think that your
solution is strict personal. Nothing wrong with it, that is what makes VBNet
a better "language". You are not hold to one word, just like any other true
language beside AFAIK languages as Latin.

Just my thought,

Cor

Mitchell S. Honnert said:
For me, nothing shouts empty string like ""
Click to expand...
What do these shout to you?
"''
'"'
''"

They all look like "", but they're not. Again, this issue is rather
trivial, but it's enough to push me to use String.Empty.
And IMHO C# is not that different from VB any more. It's all getting
more cryptic and it's all beginning to take more typing--hummm, worst of
both worlds. But they're both doing more things now days like interfacing
with more databases and with the web and all this makes things more
complicated.
Click to expand...
I personally don't think that VB is getting either more complex or
cryptic. Sure, it may have been difficult for VB6 developers to transition
to VB.NET, but this isn't the proper measure of the complexity of a
programming language. I've always contended that VB.NET would be much
easier than VB6 to teach a person who is completely new to programming.
VB.NET, along with the .NET Framework, may make VB *richer*, but because
of the regularization of the language and the thought put into the design
of the Framework, VB is actually less complex, not more.

As for being cryptic, I don't think even C# people would deny that their
language of choice is cryptic. (It's a point of pride.) Whereas VB will
use a word or series of words, C# will use a punctuation mark or other
single-character symbol. In other words, more cryptic. Bringing it back
to our discussion, trying googling "" and see what you get. Now try
"String.Empty". The reason that you will frequently see posts to the
languages.csharp ng asking what this or that punctuation mark means is
that the person either tried to google the punctuation mark and got a
zillion result or didn't bother googling it in the first place because
they knew they'd get a zillion results.

Remember, eschew obfuscation. :-)

- Mitchell S. Honnert


cj said:
For me, nothing shouts empty string like "". It's the most obvious and
readable way of denoting an empty string. My use of it has nothing to do
with typing extra keystrokes. I suspect some others feel the same way.

And IMHO C# is not that different from VB any more. It's all getting
more cryptic and it's all beginning to take more typing--hummm, worst of
both worlds. But they're both doing more things now days like interfacing
with more databases and with the web and all this makes things more
complicated.

Is String.Empty really so much more readible than ""?
More readable enough that it's worth the few extra keystrokes, yes. I
personally don't get the near obsession some programmers have with
saving a few keystrokes. As a percentage of all overall development,
the time it takes to actually type the code is small. Besides, in most
cases, you write the code once, but it's read dozens of time. So, even
if you take three extra seconds to type a more explicit reference (be it
String.Empty or anything else), you more than make up for the
"investment" of the single write during the multiple reads.

Is this a big deal? Not really. I happen to prefer String.Empty to ""
because I believe the former to be a bit more clear and that's enough
for me. What I find interesting, though, is that this discussion seems
to paralel in a way the arguments of C# vs. VB.NET. C# people love that
fact that they save a few keystrokes with their cryptic language. I
prefer to type a bit extra and have my code more easilly understood by
more people. Sure, if you know C#, then you know what weird combination
of punctuation marks you have to create to get the functionality you
need, but is this in-built obfuscation really worth the relatively small
savings in keystrokes? I prefer VB.NET, so obviously I don't think so.
To me, it's like driving ten miles out of your way to save a penny per
gallon on gas.

I'm not trying to start another C# vs. VB.NET holy flame war here. It's
just that the principle of "" vs String.Empty reminded me of some of the
same points, albeit on a much smaller scale.

- Mitchell S. Honnert

Herfried K. Wagner [MVP] wrote:
. . .
mystring = "" has been around for ages now an is obvious beyond any
doubt to me so I surely don't think saying mystring = string.empty is
any better.
Full ACK. I wonder why the VB compiler doesn't emit 'String.Empty'
for empty-string literals.

Wouldn't that be nice - from the little I understand of I.L.Code, the
compiler does come up with something a bit different in each case (not
surprisingly).

Given ...

If s1 = String.Empty Then

... the ILCode produced looks like:

IL_0001: ldloc.0
IL_0002: ldsfld string [mscorlib]System.String::Empty
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

But if you use the "old-fashioned" ...

If s1 = "" Then

... the compiler produces this instead:

IL_0001: ldloc.0
IL_0002: ldstr ""
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

So does it really matter?
Is "ldstr" so much slower than "ldsfld" that "String.Empty" really is
worth all the extra typing?

<advocate owner="devil" >
Is String.Empty really so much more readible than ""?

Regards,
Phill W.
Click to expand...
Click to expand...
Click to expand...
 
Mitchell S. Honnert said:
What do these shout to you?
"''
'"'
''"

They all look like "", but they're not. Again, this issue is rather
trivial, but it's enough to push me to use String.Empty.
Click to expand...

Mhm... There is a clear difference between them when shown in VS' standard
text-editor font... I don't see such a huge problem that would cause me not
to use "" any more.

Just my 2 Euro cents...
 
Therefore I think that your solution is strict personal.
I believe that what you are saying is that the use of String.Empty is a
personal preference for me? If so, you're exactly right. I have some
objective justification for my use of String.Empty, but nothing so important
that it can't be reasonably overridden by personal preference.

- Mitchell S. Honnert

Cor Ligthert said:
Mitchell,

Simple question, What do you do if you have to set a single quote in a
string.

"'" you have than in my idea the same problem. Therefore I think that your
solution is strict personal. Nothing wrong with it, that is what makes
VBNet a better "language". You are not hold to one word, just like any
other true language beside AFAIK languages as Latin.

Just my thought,

Cor

Mitchell S. Honnert said:
For me, nothing shouts empty string like ""
Click to expand...
What do these shout to you?
"''
'"'
''"

They all look like "", but they're not. Again, this issue is rather
trivial, but it's enough to push me to use String.Empty.
And IMHO C# is not that different from VB any more. It's all getting
more cryptic and it's all beginning to take more typing--hummm, worst of
both worlds. But they're both doing more things now days like
interfacing with more databases and with the web and all this makes
things more complicated.
Click to expand...
I personally don't think that VB is getting either more complex or
cryptic. Sure, it may have been difficult for VB6 developers to
transition to VB.NET, but this isn't the proper measure of the complexity
of a programming language. I've always contended that VB.NET would be
much easier than VB6 to teach a person who is completely new to
programming. VB.NET, along with the .NET Framework, may make VB *richer*,
but because of the regularization of the language and the thought put
into the design of the Framework, VB is actually less complex, not more.

As for being cryptic, I don't think even C# people would deny that their
language of choice is cryptic. (It's a point of pride.) Whereas VB will
use a word or series of words, C# will use a punctuation mark or other
single-character symbol. In other words, more cryptic. Bringing it back
to our discussion, trying googling "" and see what you get. Now try
"String.Empty". The reason that you will frequently see posts to the
languages.csharp ng asking what this or that punctuation mark means is
that the person either tried to google the punctuation mark and got a
zillion result or didn't bother googling it in the first place because
they knew they'd get a zillion results.

Remember, eschew obfuscation. :-)

- Mitchell S. Honnert


cj said:
For me, nothing shouts empty string like "". It's the most obvious and
readable way of denoting an empty string. My use of it has nothing to
do with typing extra keystrokes. I suspect some others feel the same
way.

And IMHO C# is not that different from VB any more. It's all getting
more cryptic and it's all beginning to take more typing--hummm, worst of
both worlds. But they're both doing more things now days like
interfacing with more databases and with the web and all this makes
things more complicated.


Mitchell S. Honnert wrote:
Is String.Empty really so much more readible than ""?
More readable enough that it's worth the few extra keystrokes, yes. I
personally don't get the near obsession some programmers have with
saving a few keystrokes. As a percentage of all overall development,
the time it takes to actually type the code is small. Besides, in most
cases, you write the code once, but it's read dozens of time. So, even
if you take three extra seconds to type a more explicit reference (be
it String.Empty or anything else), you more than make up for the
"investment" of the single write during the multiple reads.

Is this a big deal? Not really. I happen to prefer String.Empty to ""
because I believe the former to be a bit more clear and that's enough
for me. What I find interesting, though, is that this discussion seems
to paralel in a way the arguments of C# vs. VB.NET. C# people love
that fact that they save a few keystrokes with their cryptic language.
I prefer to type a bit extra and have my code more easilly understood
by more people. Sure, if you know C#, then you know what weird
combination of punctuation marks you have to create to get the
functionality you need, but is this in-built obfuscation really worth
the relatively small savings in keystrokes? I prefer VB.NET, so
obviously I don't think so. To me, it's like driving ten miles out of
your way to save a penny per gallon on gas.

I'm not trying to start another C# vs. VB.NET holy flame war here. It's
just that the principle of "" vs String.Empty reminded me of some of
the same points, albeit on a much smaller scale.

- Mitchell S. Honnert

Herfried K. Wagner [MVP] wrote:
. . .
mystring = "" has been around for ages now an is obvious beyond any
doubt to me so I surely don't think saying mystring = string.empty
is any better.
Full ACK. I wonder why the VB compiler doesn't emit 'String.Empty'
for empty-string literals.

Wouldn't that be nice - from the little I understand of I.L.Code, the
compiler does come up with something a bit different in each case (not
surprisingly).

Given ...

If s1 = String.Empty Then

... the ILCode produced looks like:

IL_0001: ldloc.0
IL_0002: ldsfld string [mscorlib]System.String::Empty
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

But if you use the "old-fashioned" ...

If s1 = "" Then

... the compiler produces this instead:

IL_0001: ldloc.0
IL_0002: ldstr ""
IL_0007: ldc.i4.0
IL_0008: call int32 [Microsoft.VisualBasic]
...CompilerServices.StringType::StrCmp( string, string, bool )

So does it really matter?
Is "ldstr" so much slower than "ldsfld" that "String.Empty" really is
worth all the extra typing?

<advocate owner="devil" >
Is String.Empty really so much more readible than ""?

Regards,
Phill W.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top