Recently I’ve been learning a little F#. This is actually the third time I’ve tried to pick it up… The first two times I just couldn’t get my head around it. This time, I think it’s making sense! Whether or not I ever get to use it commercially/in production, I think it’s been a valuable excercise. Just the basics of F# I’ve picked up so far have already start influencing how I’m writing C# in a good way.

There are a lot of things in F# that would save me a lot of time and/or drastically improve quality. One such feature is the handling of “nulls” using the Option type.

The Option type is similar to the Nullable<T> type used nullable with value types in .NET, but it can be applied to reference types too. Because of this, types are (by default) not nullable in F# ( generally …).

Take the following code that prints out a customers name:

type Customer = { Name : string }

let printCustomerName customer =
    printfn "Customer name is %s" customer.Name

In C#, this code would need to have a null check before accessing the Name property to avoid a possible NullReferenceException. In F#, because the argument is a Customer and not a Customer option, this check is not needed. The F# compiler will ensure that only Customer types can be passed as an argument to this function (note: if you’re consuming this code from another .NET language, all bets are off!).

I recently gave a talk to my colleagues about some of the interesting F# features I’d come across so far; the Option type being one of them. After the talk, one of my colleagues was debugging a NullReferenceException and I (jokingly) said that every time I hear someone debugging a NullReferenceException or see a null check, I’m going to exclaim “You wouldn’t have that in F#!”.

Well; it’s been only a week. Already; the number of times this thought has popped into my head is way above what I thought it would be. The number of null checks going into our code on a daily basis and the number of NullReferenceExceptions raised by our (sadly, very legacy) codebase is staggering. I don’t know why we put up for this crap for so long! Runtime NullReferenceExceptions are embarassing, and thousands of null checks just add to code noise. Why can’t we have our cake and eat it?

This is just one of many F# features that I geniunely believe could have a big enough impact on your code (both quality, and readability) that it should be a factor when picking your programming language. It has access to the same BCL that C# does. It has access to the same third party libraries and NuGet packages. It can even interact with your existing C# code. Unfortunately, there are still some significant reasons not to switch; the tooling is nowhere near as good as with C# (even only considering stock VS functionality), and StackOverflow has only a fraction of the answers you’ll want in F# vs C#. Both of these will improve in time and I think the idea of using F# for much of your .NET coding will become even more compelling.