C# – Instantiating Null Objects with Null-Coalescing Operator

coperators

Consider the following typical scenario:

if(myObject == null) {
    myObject = new myClass();
}

I'm wondering what is thought of the following replacement using the null-coalescing operator:

myObject = myObject ?? new myClass();

I'm not sure whether I should be using the second form. It seems like a nice shorthand, but the myObject = myObject construct at the beginning seems like it could be a bit of a code-smell.

Is this a reasonable thing to do, or is there a better shorthand that I am missing? Or maybe, "It's three lines, get over it!"?

Edit:
As has been mentioned, perhaps calling this a typical scenario is something of an overstatement. I usually find that I encounter this situation when I'm retrieving an entity from a database that has a child reference type property that may or may not be populated yet:

myClass myObject = myClassService.getById(id);
myObject.myChildObject = myObject.myChildObject ?? new myChildClass();

Best Answer

I use the null coalescing operator all of the time. I like the conciseness of it.

I find this operator to be similar in nature to the ternary operator (A ? B : C). It takes a little practice before the reading of it is second nature, but once you're used to it I feel readability improves over the longhand versions.

Also, the situation you describe is only one scenario where the operator is useful. It's also handy to replace constructs like this:

if (value != null)
{
    return value;
}
else
{ 
    return otherValue;
}

return value != null ? value : otherValue;

with

return value ?? otherValue;

Related Solutions

C# – Property-coalescing operator for C#

I very much want a C# language feature that lets me safely do x.Prop.SomeOtherProp.ThirdProp without having to check each of those for null. In one codebase where I had to do those sorts of "deep property traversals" a lot, I wrote an extension method called Navigate that swallowed NullReferenceExceptions and instead returned a default value. So I could do something like this:

var propVal = myThing.Navigate(x => x.PropOne.PropTwo.PropThree.PropFour, defaultValue);

The downside of this is that it has a different code smell: swallowed exceptions. If you wanted to do something like this "right", you could take the lamdba as an expression, and modify the expression on the fly to add the null checks around each property accessor. I went for "quick and dirty" and didn't implement it this "better" way. But maybe when I have some spare thought cycles I'll revisit this and post it somewhere.

To more directly answer your question, I'm guessing the reason this isn't a feature is because the cost of implementing the feature exceeds the benefit from having the feature. The C# team has to pick and choose which features to focus on, and this one hasn't floated to the top yet. Just a guess though I don't have any insider info.

C# Coding Style – Using ‘var’ and Null Coalescing Operator ‘??’ Without Hampering Readability

Null coalescing operator (??)

Personally, I don't see any downsides to using this operator. Consider the following three code samples, from 'easy' to 'complex' new operators.

Without magic:

bool isNameSet = false;
string name;
if ( isNameSet )
{
    Console.WriteLine( name );
}
else
{
    Console.WriteLine( "No name set." );
}

Ternary operator:

bool isNameSet = false;
string name;
Console.WriteLine( isNameSet ? name : "No name set." );

Null coalescing:

string name = null;
Console.WriteLine( name ?? "No name set." );

The reason these operators were invented is because they represent very common programming operations. Not wanting to use them because you aren't used to them is just being stubborn. Languages evolve, features evolve, learn to use them!

var keyword

I have a somewhat different opinion about the var keyword. The type of a variable often gives extra information about your code. I find hiding the type by using the var keyword sometimes makes code less readable. You know less what to expect without using auto completion, or hovering over the identifiers to see what they actually are. In my opinion, this results in code which is slower to read/write.

I do use the keyword when I find that the type doesn't give much extra information.

Mainly in foreach loops, which I learned from Resharper as it is a setting there. Most of the time, you know what type of collection you are traversing, so you know you are expecting items from within that collection.
Linq queries. The result of linq queries are often very complex generic types. Displaying this type does more harm than good.
Long typenames which are simply initialized with their constructor. You can already tell what the type is by looking at the constructor.

As an example for the last statement:

ThisIsSomeSpecializedTypeRightHere duplication =
    new ThisIsSomeSpecializedTypeRightHere();
var justAsReadable =
    new ThisIsSomeSpecializedTypeRightHere();  // Less duplication.

// But I still prefer the following ...
int number = 9;
SomeCreatedType foo = Factory.CreateSomeType();

Best Answer

Related Solutions

C# – Property-coalescing operator for C#

C# Coding Style – Using ‘var’ and Null Coalescing Operator ‘??’ Without Hampering Readability

Related Topic