Null-conditional operators in C# 6

This is the seventh part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6. (Now Visual Studio 2015 is available, they’re not so “upcoming”).

I’m going to come straight out and say that this is my favourite new language feature in C# 6. It’s going to get used a lot and will save a lot of typing and make the code a lot more readable. Basically, this is another productivity boost – a common feature of C# 6 – and I’m sure something a lot of us will welcome.

Example Classes

For the examples I’ll be using, I’ve imagined some strange car insurance system where a car can only have 1 accident and each accident needs only 1 part to replace.

public class Car
{
    public string Registration { get; set; }

    public int? Age { get; set; }

    public Accident Accident { get; set; }
}

public class Accident
{
    public string Reason { get; set; }

    public Part ReplacedPart { get; set; }
}

public class Part
{
    public int Price { get; set; }

    public string Name { get; set; }
}

Obviously not realistic, but I’m hoping once you see the example you can see how this feature will work with any code bases you’re familiar with.

Basic Null-Conditional Operator

To prevent NullReferenceExceptions, you will often see code which makes sure something isn’t null, then does access a property

    string result = null;

    if (car != null)
    {
        result = car.Registration.Substring(0, 2);
    }

    return result;
}

The null-conditional operator – ?. – helps make that code much more succinct.

public string FirstTwoCharactersOfRegCSharp6(Car car)
{
    return car?.Registration.Substring(0, 2);
}

The above code is checking that car is not null before accessing the Registration property and will evaluate to null if it is.

Chaining

It doesn’t end there as you’re not limited to one null-conditional operator, so you can wave goodbye to the days of “Christmas Tree” code where you have multiple levels of if-else.

	return car?.Accident?.ReplacedPart?.Name

Like above, if at any point the property is null, the whole expression results in null.

Combined with Null Coalescing operator

Finally, you can combine this with existing features of the language for yet more neat code.

	var replacedPart = car?.Accident?.ReplacedPart?.Name ?? "Name not specified";

Summary

Like I said above, this is probably my favourite feature of C# 6. The code we write should be more elegant to produce, easier to read and therefore hopefully less error prone.

I confess to leaving off too many null pointer checks because I’m in the zone and a.n.other if-else feels like a pain, but now I have no excuse.

Expression-bodied members in C# 6

This is the sixth part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6. (Now Visual Studio 2015 is available, they’re not so “upcoming”).

Back to the syntactic sugar updates this time, but again, I think this will be used a lot once it gets out in the wild.

There’s not a great deal to say as it’s basically lambda expressions in method and property declarations. In the following code, there’s a class called Rectangle that has several properties like xPos, yPos, Width, Height, etc

Method Declarations

The new syntax can be applied to both methods that return values:

// Before C# 6
public Rectangle Translate(int xTranslate, int yTranslate)
{
    return new Rectangle(xPos + xTranslate, yPos + yTranslate);
}

// With C# 6
public Rectangle TranslateNew(int xTranslate, int yTranslate) 
    => new Rectangle(xPos + xTranslate, yPos + yTranslate);

And to those that return void:

// Before C# 6
public void DisplayLocation()
{
    Console.WriteLine("{0}, {1}", xPos, yPos);
}

// With C# 6
public void DisplayLocationNew() => Console.WriteLine("{0}, {1}", xPos, yPos);

To be honest, it’s not a massive change, but should help reduce a lot of 1 line methods to something much more readable.

Property Declarations

You can also use the same lambda syntax

Using the same example, let’s imagine you’ve decided to declare Area as a getter only property:

// Before C# 6
public int Area {
    get { return Width* Height; }
}

// With C# 6
public int AreaNew => Width * Height;

As you can see, you don’t need to use the get keyword as it’s implicit.

Summary

This is another great feature to help increase productivity. Not only will the code you write be easier to read and understand, it will take less typing.

Slight silence due to React and new Visual Studio

A very quick update – not that anyone reads this – but I’ve been up to the eyeballs in React for the last couple of weeks.

It’s very impressive and I’m definitely planning on writing a blog post or two on it, but not in the short term.

I’ve also been more that a little distracted with the new .NET and Visual Studio – http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing-net-framework-4-6.aspx.

Await in catch and finally blocks in C# 6

This is the fifth part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6.

This is definitely not syntactic sugar and if you’re doing any asynchronous programming you’ll be very pleased with this new feature.

    public async Task<int> CharacterCountAsync(string file)
    {
        int count = 0;

        try
        {
            using (var reader = new StringReader(file))
            {
                var contents = await reader.ReadToEndAsync();
                count = contents.Length;
            }
        }
        catch (Exception exc)
        {
            // C# 6 allows this
            await Logger.LogAsync(exc);
            throw;
        }
        finally
        {
            // C# 6 allows this
            await Logger.LogAsync("CharacterCountAsync Finished");
        }

        return count;
    }

I was toying with not posting about it as the name is very descriptive and the code is pretty self explanatory, so hopefully I haven’t missed anything!

Exception filters in C# 6

This is the fourth part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6.

I must admit, I didn’t initially understand the fuss with exception filters. I saw a few tweets from along the lines of “finally, C# gets exception filters like VB.NET and F#” but didn’t understand the excitement. I saw code examples like the following and dismissed it.

    public void Demo1(int randomNumber)
    {
        try
        {
            if (randomNumber % 2 == 0)
            {
                throw new Exception("Even");
            }
            else
            {
                throw new Exception("Odd");
            }
        }
        catch (Exception e) when (e.Message == "Even")
        {
            // Extra logging because something evil happens when Even
            Console.WriteLine("Extra Logging");
        }
        catch (Exception e) when (e.Message == "Odd")
        {
            throw;
        }
    }

The change looks to be quite simple and pretty much syntactic sugar to save us putting “if/else” or “switch” statements inside a catch block, but it’s actually much more useful and subtle.

Important yet subtle improvements

First, you can put anything inside the “when” statement as long as it returns a bool. True means the exception is caught inside the corresponding catch block, false means the exception is passed to the next catch block.

Second, and more importantly, exception filters are checking the exception before it’s caught. This means the stack trace is not unwound, preserving the line number the actual exception occurred, rather than reporting the line of the subsequent “throw” statement.

Let’s look at some code to explain that in more detail.

As usual, it’s difficult to come up with something meaningful yet simple enough to fit on one screen, so please go with it and hopefully your imagination will stretch to see how this could happen in a real code base!

Demo – Extra Logs – without exception filters

Sticking with the above example, let’s imagine something strange happens when the method receives an even number, so you decide to add some extra logging inside the catch block and re-throw:

public void WithoutFilters(int randomNumber)
{
    try
    {
        if (randomNumber % 2 == 0)
        {
            throw new Exception("Even");
        }
        else
        {
            throw new Exception("Odd");
        }
    }
    catch (Exception e)
    {
        if (e.Message == "Even")
        {
            Console.WriteLine("Extra Logging");
        }

        throw;
    }
}

You get the desired result, but the stack trace reports the exception coming from the final “throw” statement which isn’t exactly helpful.

Demo – Extra logs – With Exception Filters

Let’s update the code to use exception filters, taking advantage of the fact we can put a method in the “when”:

public void WithFilters(int randomNumber)
{
    try
    {
        if (randomNumber % 2 == 0)
        {
            throw new Exception("Even");
        }
        else
        {
            throw new Exception("Odd");
        }
    }
    catch (Exception e) when (Log(e))
    {
        // as log returns false, this never gets run
    }
}

public bool Log(Exception e)
{
    // Log something
    if (e.Message == "Even")
    {
        Console.WriteLine("Extra Logging");
    }

    return false;
}

Here, the Log method is called for every exception but as it returns false, the corresponding catch block is never entered. This means we get the logging required but the exception isn’t re-thrown, so the stack trace contains the correct line number.

I also think this is easier to read and should hopefully lead to less cut-and-paste code inside catch blocks.

Summary

Although not obvious benefit of exception filters, if used wisely, this new language feature should lead to better exception handling, a better debugging experience and more maintainable code.

I suspect I’ve missed other uses for this change, so let me know in the comments below if I have!

Index Initializers in C# 6

This is the third part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6.

This is another syntactic sugar feature, this time making initializing objects with indexers more elegant. Most of the examples I’ve seen are using it on Dictionary<Tkey, Tvalue>, for example:

    // prior to C# 6
    var previously = new Dictionary<string, string>
    {
        { "FirstName", "Fred" },
        { "SurName", "Blogs" },
        { "Age", "12" },
        { "Data", "Some other text here" },
    };

    // New C# 6 syntax
    var newExample = new Dictionary<string, string>
    {
        ["FirstName"] = "Fred",
        ["SurName"] = "Blogs",
        ["Age"] = "12",
        ["Data"] = "Some other text here",
    };

Not a massive change and I imagine some people like it and some don’t.

I think a better use of this is initializing JSON data as it really aids readability:

    // prior to C# 6
    var json1 = new JObject();
    json1["FirstName"] = "Bob";
    json1["SurName"] = "Geoffs";
    json1["Age"] = 12;

    // New C# 6 syntax
    var json2 = new JObject() {
        ["FirstName"] = "Bob",
        ["SurName"] = "Geoffs",
        ["Age"] = 12
    };

Again, it’s not a big change, but imho makes json2 much more readable.

Limitations?

I’m not sure if this is really a limitation, but it should be noted that you can’t use this new syntax when initializing a list, unless passing another list to the constructor.

Confused? Hopefully the following code clears that up

    // this is fine, obviously
    var currentList = new List<int> { 5, 6 };

    // can't do this 
    // var notAllowedList  = new List<int> {[0] = 5,[1] = 6 };

    // but you can do this
    var allowedList = new List(currentList ){[0] = 15,[1] = 16 };

I don’t know for certain, but I’m guessing the old syntax created the object – List, Dictionary etc – then called .Add() for each of the initializers. The new syntax appears to do something during object creation as the debugger states “notAllowedList” is null.

Either way, I don’t see why you would try something like the above so it’s not a big deal.

Static Members in C# 6

This is the second part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6.

This feature definitely fits in the syntactic sugar category and will should result in less typing as it allows you to drop the class prefix from any static members. For example, by changing “using System.Math” to “using static System.Math” at the top of your classes, you can call the “Sqrt” method without prefixing it with “Math.”

Let’s take a simple static class called “StaticClass” that defines an enumeration and a static method.


using System;

namespace CSharp6Features
{
    public class StaticClass
    {
        public enum DaysOfTheWeek {
            Monday,
            Tuesday,
            Wednesday,
            Thursday,
            Friday,
            Saturday,
            Sunday
        }

        public static void ShoutIfMonday(DaysOfTheWeek today)
        {
            if (today == DaysOfTheWeek.Monday)
            {
                Console.WriteLine("IT'S MONDAY");
            }
        }
    }
}

Normally if you want to use either of these two, you would need to prefix the call to “ShoutIfMonday” with “StaticClass.” and “Monday” with “StaticClass.DaysOfTheWeek.”, but with the new feature, the code becomes:

using static CSharp6Features.StaticClass;
using static CSharp6Features.StaticClass.DaysOfTheWeek;

namespace CSharp6Features
{
    public class UsingStatics
    {
        public void UsingStaticsExample()
        {
            // Before C# 6
            StaticClass.ShoutIfMonday(StaticClass.DaysOfTheWeek.Monday);

            // Using C# 6 "using static" language feature
            ShoutIfMonday(Monday);
        }
    }
}

As you can in the code above, just because you’ve added “using static” doesn’t prevent you from using the old syntax.

Warning: Do not over user

This is obviously great if you’re working with a lot of the Math methods, or want to drop “Console.” from all your code, but I think there’s a danger this can be used too much.

Having an enumeration for the days of the week and using “Monday” is just as readable, if not more so, than “DaysOfWeek.Monday”. But for obscure things, say in state machines, “MoveToConfirm” is a lot less readable than “AcceptingInput.MoveToConfirm”. To find out what the current state is, you’d have to move to the top of the class and inspect the using statement or hover over it.

Not the end of the world, but I suggest some caution.

Auto-Property Changes in C# 6

This is the first part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6.

In this post, I’m looking at the Auto-Property changes in C# 6. It’s probably going to be one of the larger posts as it covers 3 new language features:

  1. Auto-property Initializers
  2. Getter-only Auto-Properties
  3. Constructor assignment to getter-only auto-properties

The first can be classified as syntactic sugar, but the other 2 are really nice for immutable types. I may be wrong, but I think I’ll probably use these the most of all the new features. I’ve been playing with React a little bit recently, so I’m using immutable types more and more and I can see me using them in C# more often too.

Auto-Property Initializers

C# 3.0 added “auto-implemented properties” which made declaring properties easier. Instead of us adding the backing field, the compiler creates a private, anonymous backing field automatically.

Auto-Property Initializers takes this one step further, by initializing this backing field directly during declaration. This means we don’t have to initialize the properties inside the constructor.

public class AutoProperty
{
    // Before C# 6
    public int AutoPropOld { get; set; }

    public AutoProperty()
    {
        AutoPropOld = 5;
    }

    // C# 6
    public int AutoProp { get; set; } = 6;
}

Less typing and more readable, especially if you have a lot of other code between the property declaration and the constructor.

Getter-only Auto-Properties

Prior to C# 6, if you declared an auto-property it had to include both a getter and setter. This often isn’t what you want the public API of your types to be, so you could declare the setter to private. Unfortunately that doesn’t stop you writing to the property elsewhere in the same class. That isn’t necessarily a big problem, but in a shared codebase, someone might change the value of a property intended to be read-only causing weird bugs.

This “Getter-only Auto-Properties” feature closes that loop-hole. The following code shows just that and if you comment out the “NotPossible” method, you get a compilation warning – “Property or indexer ‘AutoProperty.GetterOnlyProp’ cannot be assigned to — it is read only”.

public class AutoProperty
{
    # Before C# 6
    public int GetterOnlyPropOld { get; private set; }

    # C# 6
    public int GetterOnlyProp { get; }

    // Compilation Error
    //public void NotPossible()
    //{
    //    GetterOnlyProp = 5;
    //}
}

Constructor assignment to getter-only auto-properties

I don’t know, but I imagine this final feature is there so you can write to Getter-Only properties without using “Auto-Property Initializers”. The name is very self explanatory, so I’ll just include some code.

public class AutoProperty
{
    public int CtorAssignment{ get; }

    public AutoProperty()
    {
        CtorAssignment = 6;
    }
}

Immutable Objects

Combining these changes together now lets you create immutable types much easier. You don’t need to manually declare a readonly backing field, use it in the Property getter and write directly to it in the constructor. It can now be achieved in much less code.

Instead of all this:

public class ImmutableExampleOld
{
    private readonly int _immutableBackingField;
    public int Immutable
    {
        get { return _immutableBackingField; }
    }

    public ImmutableExample()
    {
        _immutableField = 5;
    }
}

You can now write just:

public class ImmutableExampleCSharp6_Option1
{
    public int Immutable { get; } = 6;
}

Or if you want to initialize in the constructor:

public class ImmutableExampleCSharp6_Option2
{
    public int Immutable2 { get; }

    public ImmutableExampleCSharp6()
    {
        Immutable2 = 6;
    }
}

Summary

These three changes are small, but I imagine once you’ve used them for a while, you’ll be using them all the time. If you’re working with immutable types, you’ll be especially pleased.

Let me know if I’ve missed the point or got anything plain wrong.

Upcoming Language Feature Changes in C# 6

If you’re a C# programmer and haven’t been living in a cave, you’ll know big changes are coming. Now the Visual Studio 2015 Release Candidate is available to download, I figured it was a good time to jump on board and see what all the fuss is about.

Visual Studio 2015 isn’t just an IDE update. It seems almost everything is being updated, changed or replaced for vNext! One of the bigger updates is the new Rosyln compiler, which among a host of news tricks, are the new language features in C#. It’s here that I decided to start my playing.

I’m not going to write anything earth shattering, and there are lots of (better) blog posts on these changes, but I find the things I’ve written about not only stay in my head longer, but it helps me dig deeper that if I just played with it. I haven’t tried all of the features yet, and I may well miss the point of a few of them, but we’re all learning right?

This post will act as an index to the other posts, but for the moment I’m planning posts on the following features and their uses:

  1. Auto-Property Changes
  2. Static Members
  3. Index Initializer
  4. Exception filters
  5. Await in catch/finally
  6. Expression Body members
  7. Null-conditional operators
  8. String interpolation
  9. nameof operator

Please note, these changes aren’t being forced on you when you upgrade to VS2015. But playing with “new and shiny” is high up on every ones priorities so give them a try.

Cumulative Flow Diagram from TFS Data

One of the teams I’ve worked with frequently ended a sprint with 2 or more user stories “almost” ready. To them “almost” meant less than 2 hours, but in reality, due to sprint planning, task breakdowns etc, we more often than not finished those user stories on day 2 of the next sprint.

There were a number of reasons for this, but to aid in our investigation into why, I used a Cumulative Flow Diagram (CFD) each sprint.

There are any number of ways of creating CFDs and some people are lucky enough to be using a tool that does it for you. Unfortunately TFS, the tool I was using, wasn’t one of them. After some searching I eventually found a great post called Cumulative Flow Diagram – How to create one in Excel 2010

It was almost exactly what I wanted, but because it needed manual data entry, I was manually digging through TFS searching for the right info. That’s not too bad if you remember to do it every day, but I’d often not be able to due to meetings or some other commitment, let alone illness or annual leave.

What I wanted, was a way to extract the information on a daily basis without me having to open a web browser.

Less Manual Approach

Part 1 – What data do I need

This was fairly simple as I realised I need to know:

  • The User Story ID
  • Who the User Story is assigned to? That way I know if it’s in “Development” (not the testers or product owner), “Testing” (one of the testers) or “Ready” (the product owner)
  • The State, which is one of “Committed”, “In Progress”, “Done”

That way, I can calculate the current status of a User Story by the logic in the following table:

State Assigned To Status
Committed Empty To Do
Committed A Tester Testing
Committed Product Owner Ready
Committed Anyone Else In Progress
Done n/a Done

Part 2 – Write TFS Query

Getting the data out of TFS is relative simple. In the web interface, go to Work->Queries, create a new “My Queries” called CFD and fill it out as below, where “Iteration Path” is your current iteration:

CFD TFS Query Configuration

CFD TFS Query Configuration

It doesn’t matter how you configure the column options for this query as we’ll be extracting things via C# next.

Part 2 – Command Line Tool

Running the above query from C# is also simple. The below code clearly has a lot to be desired, but it was a quick 5 second proof of concept and as it’s been “good enough” I’ve never tweaked it.

using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.WorkItemTracking.Client;

using System;
using System.Configuration;

namespace CFDConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
	    var tfsServer = ConfigurationManager.AppSettings["TFS_SERVER"];
            var projectName = ConfigurationManager.AppSettings["PROJECT_NAME"];
            var queryFolder = ConfigurationManager.AppSettings["QUERY_FOLDER"];
            var queryName = ConfigurationManager.AppSettings["QUERY_NAME"];

            // Connect to the work item store
            var tpc = new TfsTeamProjectCollection(new Uri(tfsServer));
            var workItemStore = (WorkItemStore)tpc.GetService(typeof(WorkItemStore));

            // Run a saved query.
            var queryRoot = workItemStore.Projects[projectName].QueryHierarchy;
            var folder = (QueryFolder)queryRoot[queryFolder];
            var query = (QueryDefinition)folder[queryName];

            var queryResults = workItemStore.Query(query.QueryText);

            for (int i = 0; i < queryResults.Count; i++)
            {
                Console.WriteLine(
                    "{0},{1},{2}",
                    queryResults[i].Id, 
                    queryResults[i].Fields["Assigned To"].Value,
                    queryResults[i].State);
            }

            Console.ReadLine();
        }
    }
}

As you can see, I’ve placed some stuff in the App.config under App.Settings, but otherwise it’s very simple.

Part 3 – Scheduled Tasks

So I don’t have to remember to run this every day, I set up a scheduled tasks to run every morning at 8am, running the following command to output to a file called the current days date and time.

cfd_console.exe > %date:~10,4%_%date:~4,2%_%date:~7,2%__%time:~0,2%_%time:~3,2%_%time:~6,2%.txt

This way, for whatever time period you want, you just have to use those files. No outlook reminders or alarms!

Part 4 – Cumulative Flow Diagram from TFS Data

When you have a period of time you want to produce a CFD chart for, simply take the relevant .txt files and import the data into the excel template from the above post.

I’m sure this could be automated also, but as it only takes a few minutes every iteration I haven’t bothered.

Summary

The above way is still fairly manual, but it’s quicker than looking at PBIs and Tasks in TFS regularly. There’s also a lot to be desired with the coding, but it serves its purpose!

I could of course make this into an Excel app and possibly automate the whole thing, but for now, it’s more than good enough for my needs. One day maybe that will change, but in the meantime, feel free to take the above and adapt it to your needs.

Finally, if you’re not already creating a CFD for each sprint, I highly recommend you do. It’s a great easy way to explain to both the team and any stakeholders the work in progress and how it affects throughput.