The Null-Conditional Operator

Here is a small piece of code that I inherited recently.  It has a very simple task, get the client’s postcode or return ‘unknown’

public string GetPostCodeOfClientsOffice(Client client)
{
  if ((client == null) || (client.Office == null)
   || (client.Office.Address == null) || (client.Office.Address.PostCode == null))
  {
    return "unknown";
  }
  return client.Office.Address.PostCode;
}

how much nicer it becomes when we use the new null conditional operator

public string GetPostCodeOfClientsOffice(Client client)
{
 return client?.Office?.Address?.PostCode ?? "unknown";
}

Note that the type of client?.Office?.Address?.PostCode is nullable String.

This isn’t restricted to properties, the following method can also be refactored

public int GetNumberOfClientsAwatingFeedback(List clients)
{
 if (clients != null) {
  return clients.Where(client=>client.NeedsFeedback).Count;
 }
 return 0;
}

which is expressed more simply as

public int GetNumberOfClientsAwatingFeedback(List clients)
{
 return clients?.Where(client=>client.NeedsFeedback).Count ?? 0;
}

Nameof Expressions

When we have methods that expect non null properties we might typically see code like this

public MemberParty GetMainClientAffiliation(Client client)
{
 If (client == Null)
  throw new ArgumentNullException("client");
 If (client.MemberParty == Null)
  throw new ArgumentNullException("MemberParty ");
 return client.MemberParty ;
}

Notice here that the method refers to client affiliation and the property it returns is ‘MemberParty ‘. Not a very ubiquitous approach.

When we refactor to use affiliation however, the following occurs

public Affiliation GetMainClientAffiliation(Client client)
{
 If (client == Null)
  throw new ArgumentNullException("client");
 If (client.Affiliation == Null)
  throw new ArgumentNullException("MemberParty ");
 return client.Affiliation;
}

Aargh, the dreaded magic string has caught us out.  C# 6.0 to the rescue

public Affiliation GetMainClientAffiliation(Client client)
{
 If (client == Null)
  throw new ArgumentNullException(nameof(client));
 If (client.Affiliation == Null)
  throw new ArgumentNullException(nameof(client.Affiliation));
 return client.Affiliation;
}

Now we have strongly typed properties and safe refactoring. Not a massive advance but something that has caught me out many times over the years.

Expression bodied properties and functions

Let’s say we have the following code

public class Client
{
 public string FirstName { get; set; }
 public string LastName { get; set; }

 public string FullName { 
  get{ 
   return string.Format("{0} {1}",FirstName,LastName); 
  }
 }
}

we can now rewrite this as

public class Client
{
 public string FirstName { get; set; }
 public string LastName { get; set; }

 public string FullName => string.Format("{0} {1}",FirstName,LastName);
}

Note that these are not lambda expressions, they are just syntactic sugar intended to simplify your code and make it more readable.

String Interpolation

even better, we can change this to

public class Client
{
 public string FirstName { get; set; }
 public string LastName { get; set; }

 public string FullName => $"{FirstName} {LastName}";
}

Much more readable!

Also if we wanted to override the ToString method for this class, we might use several new features together in the following way

 public override string ToString() => $"Full name: {FullName} City: {Address?.City ?? "Unknown"}";

These are a few of the new language features. Like I said at the start, most of the effort this time around went into Roslyn but I really appreciate that the subtle changes they did make add to the beauty of the language.