views:

1302

answers:

7

My coworker is new to C# and didn't know about the coalesce operator. So, I saw him write a line of code like this:

string foo = "" + str;

The idea being that if str is null, this expression would return an empty string. Of course, that could be rewritten as this:

string foo = str ?? "";

And I feel that would be more readable. But is it really that big a deal? Are the readability benefits enough to suggest going back and making those lines look like the second? Or is this one of those things that I should learn to let go (provided that my coworker is educated on the best way to do this in the future)?

EDIT: Just a note, I appreciate the efficiency comments, but this isn't really being used in any situations where that performance would be critical. So while that info is interesting, it's not necessarily what I feel is important.

+6  A: 

IMO, it is much better to clearly define such logic i.e. don't use string concatenation to avoid null string and use conditional statement or ?? operator.

Regarding other comments:

there is also a performance benefit to using the null-coalescing operator, since no concatenation need take place (and, therefore, no extra string instance is being created unnecessarily)

Not true. C# compiler compiles "" + string2 to the 100% same code as string1 ?? "". Moreover C# compiler translates + operator to call to string.Concat method which in turn checks arguments with string.IsNullOrEmpty function and doesn't allocate a new string in this case.

Also I would recommend the use of String.Empty over "" as it is a constant and does not require the creation of a new String

.NET framework supports string interning so "" and string.Empty point to the same memory region

aku
+1  A: 

I would prefer your second example to the first as it is more proactive against str being null and is more expressive. Also I would recommend the use of String.Empty over "" as it is a constant and does not require the creation of a new String (and yes this is an extreme nitpick but important to note).

Andrew Hare
"" is the same thing as String.Empty starting from .NET 2.0 (.NET FW supports string interning) i.e. new instance of string class will not be created
aku
Nice catch - thank you!
Andrew Hare
String.Empty is more readable and does not look like someone forgot to enter something.
BeowulfOF
I agree - I definitely prefer the _look_ of String.Empty but aku is 100% correct in pointing out that there is no performance benefit.
Andrew Hare
I prefer "" because it's shorter. Also, I read something about String.Empty being readonly and causing some concatenations to happen at runtime rather than compile time.
Greg
+1  A: 

The second line looks more readable to me, it makes clear the intent of the right side expression.

Raminder
+3  A: 

I don't think one is any more readable than the other personally. I prefer this:

string foo = str ?? "";

simply because I really like the ?? operator.

If you are a brand newbie, I think that this would be a little easier to understand:

string foo = str == null ? "" : str;

or

string foo = "";
if (str != null) foo = str;

However, you kinda need to ask youself, "How simple do you really want to get?"

wcm
+1  A: 

While I prefer the second line from the technical perspective, the first line is actually more readable to me...

Brian Knoblauch
A: 

here is an article about string.empty vs ""

http://blogs.msdn.com/brada/archive/2003/04/22/49997.aspx

Mike_G
this article is 6 years old
aku
just try this code Console.WriteLine(ReferenceEquals("", string.Empty));
aku
+1  A: 

I'd use the coalesce operator or foo = str == null ? "" : str; for two reasons:

  1. The first example does not have the same behaviour in other curly-brace languages (particularly Java and JavaScript), where appending a null reference to an empty string results in a string containing the text null. As a result, the first example requires much more mental effort to ensure it will result in the correct behaviour in the language being authored. Even given other clues it is C# (such as the lowercase type string), anything that requires the developer to slow down and think "what is the intent of this code" results in lost productivity. It could also introduce bugs when moving from language to language.

  2. The second example more clearly expresses the intent of the code, which as described in the original question is:

    when str is null set foo to an empty string

    As opposed to the first example, which can be read as:

    set foo to an empty string with str appended (which may have the side effect of setting foo to an empty string when str is null)

As programmers, we should probably be trying to express the intent of our code, rather than relying on side-effects of other operations to give us the results we want.

Grant Wagner