Jeremy Davis
Jeremy Davis
Sitecore, C# and web development
Article printed from: https://blog.jermdavis.dev/posts/2014/bonus-chatter-my-favourite-proposed-feature-for-c-v6

Bonus chatter: My favourite proposed feature for C# v6

Published 04 March 2014
Updated 25 August 2016
C# ~1 min. read

Having been away on holiday recently, I've been doing a bit of catching up on the backlog of RSS-based reading that a week out of the office has generated. And one item stuck out at me as particularly interesting: some of the new features being discussed for the v6 release of the C# compiler. I came across a couple of articles discussing presentations given by Mads Torgersen (the C# Programme Manager) at the end of last year discussing some interesting feature proposals

One thing stuck out at me as being particularly useful to the code I find myself dealing with in Sitecore solutions – something described as "Monadic Null Checking". A rather technical name for a simple but useful syntax improvement.

When you're using Model classes for your Sitecore templates, via a mapping tool like Glass, you often find yourself creating models that might look a bit like:

public class ExampleModel
{
    public virtual string Title { get; set; }
    public virtual Image SummaryImage { get; set; }
}

					

The mapping framework can fill this class in using the data from Sitecore Items – but what happens when that Image field defined here is not filled in by your content editors? Up until now you've generally ended up writing code that's looked a bit like this:

public void DoSomething(ExampleModel model)
{
    if (model.SummaryImage != null)
    {
        // do stuff with the data. For example:
        myImageControl.AlternatText = model.SummaryImage.Alt;
    }
}

					

You end up littering your code with if() clauses to make sure that the properties of the object are not null before you make use of them. And it's a common QA issue to find that when you test new code with the sort of edge-case data which content editors sometimes create, you get Null Reference exceptions in places where these guard clauses have been forgotten.

But in the future this could be simpler with a new approach to null-checking. The new ?. operator is translated by the compiler into exactly the sort of null test we've been writing above. So our code becomes something like:

public void DoSomething(ExampleModel model)
{
    // do stuff with the data. For example:
    myImageControl.AlternatText = model.SummaryImage?.Alt;
}

					

If the value of SummaryImage is null, then the compiler never references the Alt child property – hence preventing the Null Reference issue without the extra code.

While you still have to remember to use this alternative syntax, it's much shorter and (to me at least) the shorter code is easier to read and understand. Especially where you get into more complex scenarios with nested objects. And it's much less hassle to remember to type ?. every time you access a property than it is to write the whole guard.

↑ Back to top