Getting Started

FP is easy, really it is! Despite what many people think, it’s easier to learn than OOP. FP has fewer new concepts to learn.

If you don’t believe me, try explaining polymorphism to a nontechnical member of your family! Those of us who are comfortable with object orientation have often been doing it so long that we’ve forgotten how hard it may have been to get our heads around it at the beginning.

FP isn’t hard to understand at all, just different. I’ve spoken to plenty of students coming out of higher education who embrace it with enthusiasm. So, if they can manage it…​

The myth does seem to persist, though, that getting into FP requires learning a whole load of stuff first. But what if I told you that if you’ve been doing C# for any length of time, you’ve already most likely been writing functional code for a while? In the next section, I’ll show you what I mean.

Writing Your First Functional Code

Before we start with some functional code, let’s look at a bit of nonfunctional. This is a style you most likely learned somewhere near the beginning of your C# career.

public IEnumerable<Film> GetFilmsByGenre(string genre)
{
    var allFilms = GetAllFilms();
    var chosenFilms = new List<Film>();

    foreach (var f in allFilms)
    {
        if (f.Genre == genre)
        {
            chosenFilms.Add((f));
        }
    }
    return chosenFilms;
}

var actionFilms = GetFilmsByGenre("Action");

public IEnumerable<Film> GetFilmsByGenre(string genre)
{
    var allFilms = GetAllFilms();

    foreach (var f in allFilms)
    {
        if (f.Genre == genre)
        {
            yield return f;
        }
    }
}

var actionFilms = GetFilmsByGenre("Action");

public IEnumerable<Film> GetFilmsByGenre(
    IEnumerable<Film> source,
    string genre) =>
    source.Where(x => x.Genre == genre);

var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");

Focusing on Results-Oriented Programming

A common feature of functional code is that it focuses much more heavily on the end result rather than on the process of getting there. An entirely procedural approach to building a complex object would be to instantiate it empty at the beginning of the code block, and then fill in each property as we go along:

var sourceData = GetSourceData();
var obj = new ComplexCustomObject();

obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;

if(sourceData.AlternateTuesday)
{
    obj.PropertyC = sourceData.CaptainKirk;
    obj.PropertyD = sourceData.MrSpock;
}
else
{
    obj.PropertyC = sourceData.CaptainPicard;
    obj.PropertyD = sourceData.NumberOne;
}

return obj;

The problem with this approach is that it’s open to abuse. This silly little imaginary code block is short and easy to maintain. What often happens with production code, however, is that the code can end up becoming incredibly long, with multiple data sources that all have to be preprocessed, joined, and reprocessed. We can end up with long blocks of if statements nested in if statements, to the point that the code starts resembling the shape of a family tree.

For each nested if statement, the complexity effectively doubles. This is especially true if multiple return statements are scattered around the codebase. The risk increases of inadvertently ending up with a null or other unexpected value if the increasingly complex codebase isn’t thought through in detail. FP discourages structures like this and isn’t prone to this level of complexity, or to the potential unexpected consequences.

Our preceding code sample defines PropertyC and PropertyD in two places. The code is not too hard to work with here, but I’ve seen examples that define the same property in around half a dozen places across multiple classes and subclasses.² I don’t know whether you’ve ever had to work with code like this, but it has happened to me an awful lot.

These sorts of large, unwieldy codebases get harder to work with over time. With each addition, the speed at which the developers can do the work goes down, and the business leaders can end up getting frustrated because they don’t understand why their “simple” update is taking so long.

Functional code should ideally be written into small, concise blocks, focusing entirely on the end product. The expressions it prefers are modeled on the individual steps required to solve a mathematical problem, so you really want to write functional code like small formulas, each precisely defining a value and all the variables that make it up. There shouldn’t be any hunting up and down the codebase to work out where a value comes from.

Here’s an example:

function ComplexCustomObject MakeObject(SourceData source) =>
    new ComplexCustomObject
    {
       PropertyA = source.Something + source.SomethingElse,
       PropertyB = source.Ping * source.Pong,
       PropertyC = source.AlternateTuesday
            ? source.CaptainKirk
            : source.CaptainPicard,
       PropertyD = source.AlternateTuesday
            ? source.MrSpock,
            : source.NumberOne
    };

I know we’re repeating the AlternateTuesday flag, but now all the variables that determine a returned property are defined in a single place. This approach makes the code much simpler to work with in the future.

If a property is so complicated that it will need either multiple lines of code or a series of LINQ operations that take up a lot of space, I’d create a break-out function to contain that complex logic. I’d still have my central, result-based return at the heart of it all, though.

Understanding Enumerables

I sometimes think enumerables are one of the most underused and least understood features of C#. An enumerable is the most abstract representation of a collection of data—so abstract that it doesn’t contain any data itself, but just a description held in memory of how to go about getting the data. An enumerable doesn’t even know the number of items available until it iterates through everything—all it knows is where the current item is and how to iterate to the next.

This process is called lazy evaluation, or deferred execution. Being lazy is a good thing in development. Don’t let anyone tell you otherwise.³

In fact, we can even write our own customized behavior for an enumerable. Under the surface is an object called an enumerator. By interacting with that, we can either get the current item or iterate on to the next. We can’t use the enumerable or the enumerator to determine the length of the list, and the iteration works in only a single direction.

Have a look at the following code sample. First, a set of simple logging functions pop a message in a List of strings:

private IList<string> c = new List<string>();


public int DoSomethingOne(int x)
{
    c.Add(DateTime.Now + " - DoSomethingOne (" + x + ")");
    return x;
}

public int DoSomethingTwo(int x)
{
    c.Add(DateTime.Now + " - DoSomethingTwo (" + x + ")");
    return x;
}

public int DoSomethingThree(int x)
{
    c.Add(DateTime.Now + " - DoSomethingThree (" + x + ")");
    return x;
}

Then a bit of code calls each of those DoSomething() functions in turn with different data:

var input = new[]
{
    75,
    22,
    36
};

var output = input.Select(x => DoSomethingOne(x))
    .Select(x => DoSomethingTwo(x))
    .Select(x => DoSomethingThree(x))
    .ToArray();

What do you think the order of operations is? You might think that the runtime would take the original input array, apply DoSomethingOne() to all three elements to create a second array, then again with all three elements into DoSomethingTwo(), and so on.

If we were to examine the content of that List of strings, we’d find something like this:

18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)

It’s almost the exact same as we might get if we were running this through a for or foreach loop, but we’ve effectively handed over control of the order of operations to the runtime. We’re not concerned with the nitty-gritty of temporary holding variables, what goes where and when. Instead we’re just describing the operations we want and expecting a single answer back at the end.

The resulting list of strings might not always look exactly like this; it depends on what the code that interacts with the enumerable (via LINQ or a foreach) looks like. But the intent always remains that enumerables actually produce their data only at the precise moment it’s needed. It doesn’t matter where they’re defined; it’s when they’re used that makes a difference.

By using enumerables instead of solid arrays, we’ve managed to implement some of the behaviors we need to write declarative code.

Incredibly, the preceding logfile would still look the same if we were to rewrite the code like this:

var input = new[]
{
    1,
    2,
    3
};

var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));

temp1, temp2, and finalAnswer are all enumerables, and none of them will contain any data until iterated.

Here’s an experiment to try. Write some code like this sample. Don’t copy it exactly, maybe something simpler like a series of selects amending an integer value somehow. Put in a break point and move the operation pointer on until the final answer has been passed, then hover over finalAnswer in Visual Studio. You’ll most likely find that it can’t display any data to you, even though the line has been passed. That’s because the enumerable hasn’t performed any of the operations yet.

Things would change if we did something like this:

var input = new[]
{
    1,
    2,
    3
};

var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();

Because we’re specifically now calling ToArray() to force an enumeration of each intermediate step, then we really will call DoSomethingOne() for each item in input before moving on to the next stop.

The logfile will look something like this now:

18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)

For this reason, I nearly always advocate for waiting as long as possible before using ToArray() or ToList(),⁴ because this way we can leave the operations unperformed for as long as possible. And potentially, the operations may never be performed if later logic prevents the enumeration from occurring at all.

Exceptions exist for performance or for avoiding multiple iterations. While the enumerable remains un-enumerated, it doesn’t have any data, but the operation itself remains in memory. If you pile too many enumerables on top of one another—especially if you start performing recursive operations—you might find that you fill up far too much memory and performance takes a hit, and possibly even end up with a stack overflow.

Preferring Expressions to Statements

In the rest of this chapter, I’m going to give more examples of how you can use LINQ more effectively to avoid the need for statements like if, where, and for, or to mutate state (i.e., change the value of a variable). In some situations, it won’t be possible to replace these statements with out-of-the-box C#. But that’s what the rest of this book is for.

var films = GetAllFilmsForDirector("Jean-Pierre Jeunet")
    .OrderByDescending(x => x.BoxOfficeRevenue);

var i = 1;

Console.WriteLine("The films of visionary French director");
Console.WriteLine("Jean-Pierre Jeunet in descending order");
Console.WriteLine("of financial success are as follows:");

foreach (var f in films)
{
    Console.WriteLine($"{i} - {f.Title}");
    i++;
 }

Console.WriteLine("But his best by far is Amelie");

var films = GetAllFilmsForDirector("Jean-Pierre Jeunet")
    .OrderByDescending(x => x.BoxOfficeRevenue);

Console.WriteLine("The films of visionary French director");
Console.WriteLine("Jean-Pierre Jeunet in descending order");
Console.WriteLine("of financial success are as follows:");

var formattedFilms = films.Select((x, i) => $"{i} - {x.Title}");
Console.WriteLine(string.Join(Environment.NewLine, formattedFilms));

Console.WriteLine("But his best by far is Amelie");

var a = Enumerable.Range(8, 5);
var s = string.Join(", ", a);
// s = "8, 9, 10, 11, 12"
// That's 5 elements, each 1 higher than the last,
// starting with 8.

var nineTimesTable = Enumerable.Range(1,10)
    .Select(x => x + " times 9 is " + (x * 9));

var message = string.Join("
", nineTimesTable);

var coords = Enumerable.Range(1, 5)
    .SelectMany(x => Enumerable.Range(1, 5)
        .Select(y => (X: x, Y: y))
);

var values = coords.Select(x => this.gridRepo.GetVal(x.Item1,x.Item2);

var gridCoords = Enumerable.Repeat(5, 5).Select((x, i) => x - i)
    .SelectMany(x => Enumerable.Repeat(5, 5)
        .Select((y, i) => (x, y - i))
);

var values = coords.Select(x => this.gridRepo.GetVal(x.Item1,x.Item2);

var total = 0;
foreach(var x in listOfIntegers)
{
    total += x;
}

var total = listOfIntegers.Sum();

var films = GetAllFilmsForDirector("Alfred Hitchcock");
var totalRevenue = films.Sum(x => x.BoxOfficeRevenue);

var numbers = new []
{
    83,
    27,
    11,
    98
};

bool IsEvenNumber(int number) => number % 2 == 0;

var sortedList = numbers.OrderBy(x => x).ToArray();
var sortedListCount = sortedList.Count();

var median = IsEvenNumber(sortedList.Count())
    ? sortedList.Skip((sortedListCount/2)-1).Take(2).Average()
    : sortedList.Skip((sortedListCount) / 2).First();

// median = 55.

var films = GetAllFilmsForDirector("Christopher Nolan");

var totalBudget = 0.0M;
var totalRevenue = 0.0M;

foreach (var f in films)
{
    totalBudget += f.Budget;
    totalRevenue += f.BoxOfficeRevenue;
}

var films = GetAllFilmsForDirector("Christopher Nolan");

var (totalBudget, totalRevenue) = films.Aggregate(
    (Budget: 0.0M, Revenue: 0.0M),
    (runningTotals, x) => (
            runningTotals.Budget + x.Budget,
            runningTotals.Revenue + x.BoxOfficeRevenue
        )
);

var deltas = GetDeltas().ToArray();
var startingValue = 10;
var currentValue = startingValue;
var i = -1;

foreach(var d in deltas)
{
    if(currentValue == 0)
    {
        break;
    }
    i++;
    currentValue = startingValue + d;

}

return i;

var deltas = GetDeltas().ToArray();

int GetFirstPositionWithValueZero(int currentValue, int i = -1) =>
    currentValue == 0
        ? i
        : GetFirstPositionWithValueZero(currentValue + deltas[i], i + 1);

return GetFirstPositionWithValueZero(10);

GetFirstPositionWithValueZero(10, -1)
    GetFirstPositionWithValueZero(12, 0)
        GetFirstPositionWithValueZero(0, 1)
        return 1;
    return 1;
return 1;

Making Your Code Immutable

There’s more to FP in C# than just LINQ. Another important feature I’d like to discuss is immutability (i.e., a variable may not change value once declared). To what extent is immutability possible in C#?

First, C# 8 and upward provide some newer developments with regards to immutability. See Chapter 3 for that. For this chapter, I’m restricting myself to what is true of just about any version of .NET.

To begin, let’s consider this little C# snippet:

public class ClassA
{
    public string PropA { get; set; }
    public int PropB { get; set; }
    public DateTime PropC { get; set; }
    public IEnumerable<double> PropD { get; set; }
    public IList<string> PropE { get; set; }
}

Is this immutable? It very much is not. Any of those properties can be replaced with new values via the setter. The IList also provides a set of functions that allows its underlying array to be added to or removed from.

We could make the setters private, meaning we’d have to instantiate the class via a detailed constructor:

public class ClassA
{
    public string PropA { get; private set; }
    public int PropB { get; private set; }
    public DateTime PropC { get; private set; }
    public IEnumerable<double> PropD { get; private set; }
    public IList<string> PropE { get; private set; }

    public ClassA(
        string propA,
        int propB, DateTime propC,
        IEnumerable<double> propD,
        IList<string> propE)
    {
        this.PropA = propA;
        this.PropB = propB;
        this.PropC = propC;
        this.PropD = propD;
        this.PropE = propE;
    }

}

Is it immutable now? No, honestly it’s not. It’s true that we can’t outright replace any of the properties with new objects outside ClassA, which is great. The properties can be replaced inside the class, but the developer can ensure that no such code is ever added. We should hopefully have some sort of code review system to ensure that as well.

PropA and PropC are fine; strings and DateTime are both immutable in C#. The int value of PropB is fine too; ints don’t have anything we can change except their value. Several problems still remain, however.

PropE is a List, which can still have values added, removed, and replaced, even though we can’t replace the entire object. If we didn’t need to hold a mutable copy of PropE, we could easily replace it with an IEnumerable or IReadOnlyList.

The IEnumerable<double> value of PropD seems fine at first glance, but what if it was passed to the constructor as a List<double>, which is still referenced by that type in the outside world? It would still be possible to alter its contents that way.

There’s also the possibility of introducing something like this:

public class ClassA
{
    public string PropA { get; private set; }
    public int PropB { get; private set; }
    public DateTime PropC { get; private set; }
    public IEnumerable<double> PropD { get; private set; }
    public IList<string> PropE { get; private set; }
    public SubClassB PropF { get; private set; }

    public ClassA(
        string propA,
        int propB, DateTime propC,
        IEnumerable<double> propD,
        IList<string> propE,
        SubClassB propF)
    {
        this.PropA = propA;
        this.PropB = propB;
        this.PropC = propC;
        this.PropD = propD;
        this.PropE = propE;
        this.PropF = propF
    }

}

All properties of PropF are also potentially going to be mutable, unless this same structure with private setters is followed there too.

What about classes from outside our codebase? What about Microsoft classes or those from a third-party NuGet package? There’s no way to enforce immutability.

Unfortunately, C# doesn’t provide any way to enforce universal immutability, not even in its most recent versions. Having a native C# method of ensuring immutability by default would be lovely, but there isn’t one—and isn’t ever likely to be for reasons of backward compatibility. My own solution is that when coding, I simply pretend that immutability exists in the project and never change any object. Nothing in C# provides any level of enforcement whatsoever, so you’d simply have to make a decision for yourself, or within your team, to act as if it does.

Putting It All Together: A Complete Functional Flow

I’ve talked a lot about simple techniques we can use to make our code more functional right away. Now, I’d like to show a complete, if minute, application written to demonstrate an end-to-end functional process.

We’re going to write a simple CSV parser. In this example, we want to read in the complete text of a CSV file containing data about the first few series of Doctor Who.⁷ We want to read the data, parse it into a plain old C# object (POCO, a class containing only data and no logic), and then aggregate it into a report that counts the number of episodes, and the number of episodes known to be lost for each season.⁸ I’m simplifying CSV parsing for the purposes of this example; don’t worry about quotes around string fields, commas in field values, or any values requiring additional parsing. Third-party libraries are available for all of that! I’m just proving a point.

This complete process represents a nice, typical functional flow. Take a single item, break it into a list, apply list operations, and then aggregate back down into a single value again.

Table 2-1 shows the structure of our CSV file.

We want to end up with a report that has just these fields:

• Season Number

• Total Episodes

• Total Missing Episodes

• Percentage Missing

Let’s get rolling with some code:

var text = File.ReadAllText(filePath);

// Split the string containing the whole contents of the
// file into an array, where each line of the original file
// (i.e., each record) is an array element
var splitLines = text.Split(Environment.NewLine);

// Split each line into an array of fields, splitting the
// source array by the ',' character.  Convert to Array
// for each access.
var splitLinesAndFields = splitLines.Select(x => x.Split(",").ToArray());

// Convert each string array of fields into a data class.
// parse any nonstring fields into the correct type.
// Not strictly necessary, based on the final aggregation
// that follows, but I believe in leaving behind easily
// extendible code
var parsedData = splitLinesAndFields.Select(x => new Story
{
    SeasonNumber = int.Parse(x[0]),
    StoryName = x[1],
    Writer = x[2],
    Director = x[3],
    NumberOfEpisodes = int.Parse(x[4]),
    NumberOfMissingEpisodes = int.Parse(x[5])
});

// group by SeasonNumber, this gives us an array of Story
// objects for each season of the TV series
var groupedBySeason = parsedData.GroupBy(x => SeasonNumber);

// Use a 3-field tuple as the aggregate state:
// S (int) = the season number.  Not required for
//                the aggregation, but we need a way
//                to pin each set of aggregated totals
//                to a season
// NumEps (int) = the total number of episodes in all
//                serials in the season
// NumMisEps (int) = The total number of missing episodes
//                from the season
var aggregatedReportLines = groupedBySeason.Select(x =>
    x.Aggregate((S: x.Key, NumEps: 0, NumMisEps: 0),
        (acc, val) => (acc.S,
            acc.NumEps + val.NumberOfEpisodes,
            acc.NumMisEps + val.NumberOfMissingEpisodes)
    )
);

// convert the tuple-based results set to a proper
// object and add in the calculated field PercentageMissing
// not strictly necessary, but makes for more readable
// and extendible code
var report = aggregatedReportLines.Select(x => new ReportLine
{
    SeasonNumber = x.S,
    NumberOfEpisodes = x.NumEps,
    NumberOfMIssingEpisodes = x.NumMisEps,
    PercentageMissing = (x.NumMisEps/x.NumEps)*100
});

// format the report lines to a list of strings
var reportTextLines = report.Select(x =>
    $"{x.SeasonNumber}	 {x.NumberOfEpisodes}	" +
    $"{x.NumberofMissingEpisodes}	{x.PercentageMissing}");

// join the lines into a large single string with New Line
// characters between each line
var reportBody = string.Join(Environment.NewLine, reportTextLines);
var reportHeader = "Season	No Episodes	No MissingEps	Percentage Missing";

// the final report consists of the header, a new line, then the reportbody
var finalReport = $"{reportHeader}{Environment.NewLine}{reportTextLines}";

In case you’re curious, the results would look something like this (the characters are tabs, which make the output a bit more readable):

Season   No Episodes   No Missing Eps   Percentage Missing,
1         42               9                  21.4
2         39               2                  5.1
3         45               28                 62.2
4         43               33                 76.7
5         40               18                 45
6         44               8                  18.2
7         25               0                  0
8         25               0                  0
9         26               0                  0

...

We could have made the code sample more concise and written just about all of this together in one long, continuous fluent expression like this:

var reportTextLines = File.ReadAllText(filePath)
        .Split(Environment.NewLine)
        .Select(x => x.Split(",").ToArray())
        .GroupBy(x => x[0])
        .Select(x =>
    x.Aggregate((S: x.Key, NumEps: 0, NumMisEps: 0),
        (acc, val) => (acc.S,
            acc.NumEps + int.Parse(va[4]),
            acc.NumMisEps + int.Parse(val[5]))
    )
)
.Select(x => $"{x.S}, {x.NumEps},{x.NumMisEps},{(x.NumMisEps/x.NumEps)*100}");


var reportBody = string.Join(Environment.NewLine, reportTextLines);
var reportHeader = "Season,No Episodes,No MissingEps,Percentage Missing";

var finalReport = $"{reportHeader}{Environment.NewLine}{reportHeader}";

Nothing is wrong with this sort of approach, but I like splitting it into individual lines for a couple of reasons:

• The variable names provide some insight into what our code is doing. We’re sort of semi-enforcing a form of code commenting.

• It’s possible to inspect the intermediate variables, to see what’s in them at each step. This makes debugging easier, because as I said in the previous chapter—it’s like being able to look back on your work in a mathematics problem, to see at which step you went wrong.

The two approaches don’t have any ultimate functional difference, nothing that would be noticed by the end user, so which style you adopt is more a matter of personal taste. Write in whatever way seems best to you. Do try to keep the code readable and easy for everyone to follow.

Taking It Further: Develop Your Functional Skills

Here’s a challenge for you. If some or all of the techniques described to you here are new, go off and have fun with them for a bit. Challenge yourself to writing code with the following rules:

• Treat all variables as immutable: do not change any variable value after it’s set. Basically, treat everything as if it were a constant.

• None of the following statements are permitted: if, for, foreach, while. An if statement is acceptable only in a ternary expression—i.e., the single-line expression in the style someBoolean ? valueOne : valueTwo.

• Where possible, write as many functions as small, concise arrow functions (aka lambda expressions).

Either do this as part of your production code or go out and look for a code challenge site. Try Advent of Code or Project Euler, something you can get your teeth into.

If you don’t want to go through the bother of creating an entire solution for these exercises in Visual Studio, LINQPad can always provide a quick and easy way to rattle off some C# code.

After you have the hang of this, you’ll be ready to move on to the next step. I hope you’re having fun so far!