I am reading Effective C# by Bill Wagner. In Item 14 - Minimize Duplicate Initialization Logic, he shows the following example of using the new opt
I never use string.Empty, I can't see the point of it. Maybe it makes it easier for people that are really new to programming, but I doubt it's useful even for that.
I use string.Empty
purely for readability.
If someone else needs to read/change my code later they know that I meant to check for or set something to an empty string. Using just ""
can sometimes cause bugs and confusion because I may have just forgot to put the string that I wanted in there.
For example:
if(someString == string.Empty)
{
}
vs
if(someString == "")
{
}
The first if
statement just seems so much more deliberate and readable to me. Because this is just a preference though, I really do not see the train-smash in having to use ""
instead of string.Empty
.
From the original question:
I thought that we would use it to be sure that we have a system-independent means of referring to the empty string.
In what way can the empty string vary from system to system? It's always a string with no characters! I'd be really scared if I ever found an implementation where string.Empty == ""
returned false :) This is not the same as something like Environment.NewLine
.
From Counter Terrorist's bounty post:
I want String.Empty can be used as a default parameter in the next C# release. :D
Well that's certainly not going to happen.
While I would personally have liked a very different defaulting mechanism too, the way optional parameters work has been in .NET since the start - and it always means embedding a constant into the metadata, so that the calling code can copy that constant into the call site if no corresponding argument is provided.
With string.Empty
it's really pointless - using ""
will do what you want; is it that painful to use the string literal? (I use the literal everywhere - I never use string.Empty
- but that's a different argument.)
That's what surprises me about this question - the complaint revolves around something which doesn't actually cause a real problem. It's for more important in cases where you want the default to be computed at execution time because it might actually vary. For example, I could imagine cases where you want to be able to call a method with a DateTime
parameter and have it default to "the current time". At the moment, the only vaguely elegant workaround I know for that is:
public void RecordTime(string message, DateTime? dateTime = null)
{
var realDateTime = dateTime ?? DateTime.UtcNow;
}
... but that's not always appropriate.
In conclusion:
string.Empty
it's pointless anywayAs a FYI, it looks like the same constraint is imposed on values passed to attribute constructors - they must be constant. Since string.empty is defined as :
public static readonly string Empty
rather than an actual constant, it cannot be used.
Perhaps the best solution to this problem is an overload of this method, in this way:
public static void PrintString()
{
PrintString(string.Empty);
}
I think the idea behind string.Empty is it enhances readability. It is not like newline where there is any difference between how it is represented on different platforms. It's ashame it can't be used in a default parameter. However, it will not cause any issues if you port between Windows and something like Mono on Linux.