Avoid Duplicating Code

It’s great that so many C# and VB.NET developers are taking advantage of LINQ. Unfortunately, using LINQ can encourage you to misuse lambdas. Consider the following simple example:

var results = from x in 0.Through(10)
              select x * x;

Square is a useful utility function. It shouldn’t be defined as a lambda because that ensures code duplication instead of reuse. It’s more obvious using extension method-syntax:

var results =
    0.Through(10)
    .Select(x => x * x);

The problem is that in versions of C# prior to 4.0, it is painful to define Square as a reusable method because Select is a function with multiple generic parameters. You are forced to painfully specify the type parameters or use an unnecessary lambda:

//specifying the generic types
var results =
    0.Through(10)
    .Select<int, int>(Math.Square);

//using an unnecessary lambda
var results =
    0.Through(10)
    .Select(x => Math.Square(x));

Even in C# 4.0, the query syntax retains the unnecessary lambda problem:

var results = from x in 0.Through(10)
              select Math.Square(x);

Fortunately, the extension method syntax is fixed in 4.0:

var results =
    0.Through(10)
    .Select(Math.Square);

Avoid Multi-Line Lambdas

It’s easy to recognize that Square should not be a lambda, but some functions are less obvious:

IEnumerable<Ninja> MakeFearsomeFightingTeam(SecretOoze ooze,
                                           IEnumerable<Turtle> turtles,
                                           Pizza pizza)
{
    return
        turtles
        .Select(turtle =>
        {
            var transformed = ooze.Transorm(turtle);
            transformed.Say("Cowabunga!");
            transformed.Eat(pizza);
            return transformed;
        });
}

You should avoid writing multi-line lambdas like this where possible. In this case, it makes the code harder to read, especially if you add another operation after the Select. It’s difficult to understand what the lambda is doing upon first glance. Also, there’s a good chance that you will want to reuse the behavior of the lambda elsewhere in your program.

IEnumerable<Ninja> MakeFearsomeFightingTeam2(SecretOoze ooze,
                                            IEnumerable<Turtle> turtles,
                                            Pizza pizza)
{
    return
        turtles
        .Select(turtle => Ninjaify(ooze, pizza, turtle));
}

Ninja Ninjaify(SecretOoze ooze, Pizza pizza, Turtle turtle)
{
    var transformed = ooze.Transorm(turtle);
    transformed.Say("Cowabunga!");
    transformed.Eat(pizza);
    return transformed;
}

The named instance method gives a description to the behavior that was in the multi-line lambda, and the Select statement is more readable. The sacrifice is that Ninjaify has to take extra arguments because it cannot rely on closure. There is also no guarantee that the definition of Ninjaify will remain close to where it is used as you add more code. Additionally, C#’s syntax requires that you use an unnecessary lambda to pass the turtle argument to Ninjaify. The answer is to use a locally defined method:

IEnumerable<Ninja> MakeFearsomeFightingTeam3(SecretOoze ooze,
                                            IEnumerable<Turtle> turtles,
                                            Pizza pizza)
{
    Func<Turtle, Ninja> Ninjaify =
        turtle =>
        {
            var transformed = ooze.Transorm(turtle);
            transformed.Say("Cowabunga!");
            transformed.Eat(pizza);
            return transformed;
        };

    return
        turtles
        .Select(Ninjaify);
}

Like a lambda, the locally defined method uses closure to avoid redefining variables, and it has the readability benefit of being defined near to where it is used. Since it is a named method, it provides a useful description of it’s behavior, and it doesn’t disrupt the flow of your Select method. It’s the best of both worlds. The only downside is that it can’t be called outside the scope of the MakeFearsomeFightingTeam3 method.

Unfortunately, C# requires you to write the full type signature for the function. The compiler will fail with a “cannot assign lambda expression to implicitly-typed local variable” if you try to use the var keyword. This is a real pain for more complicated signatures, and it limits you from using locally defined methods to their full potential.

Going Further With F#

In F#, the type signature problem goes away:

let MakeFearsomeFightingTeam4 ooze turtles pizza =
    let ninjaify turtle =
        let transformed = ooze.Transform(turtle)
        transformed.Say("Cowabunga!")
        transformed.Eat(pizza)
        transformed

    turtles
    |> Seq.map ninjaify

Here, you can see the benefit of F#’s type inference system and functional programming roots. The behavior of the code is retained, but the extraneous type signature is not required.

F# also fixes the problem of requiring an unnecessary lambda for named methods outside the scope of the MakeFearsomeFightingTeam4 method. Automatic currying makes it easy to pass the arguments that would be captured by closure:

let ninjaify ooze pizza turtle =
    let transformed = ooze.Transform(turtle)
    transformed.Say("Cowabunga!")
    transformed.Eat(pizza)
    transformed

let MakeFearsomeFightingTeam5 ooze turtles pizza =
    turtles
    |> Seq.map (Ninjaify ooze pizza)

In Summary

• Use lambdas for one line, single use functions
• Prefer locally defined functions to multi-line lambdas, but be wary of complicated type signatures in C#
• If a function is reusable, move it to the appropriate class or module, and use it instead of a lambda or locally defined function
• Use F# to avoid messy type signatures and unnecessary lambdas

During CodeMash this past January, I had the opportunity to talk with Chris Smith about F#. One of the things that he considered to be a sweet spot for the language was programming “in the small”. At the time, I didn’t completely agree with his claim, but after writing more F# and functional C# code, I see where he was coming from.  Programming in the small is an important part of developing software, and it is an area where F# excels.

What is programming in the small?

Brian McNamara of the F# team has a great post where he describes how functional programming impacts code in the “large”, “medium”, and “small”. His post is well worth a read if you know a little bit about functional programming, but for those of you coming from a C# or Java background, I’ll summarize here. Programming in the small is the code that goes inside a method body. As Brian puts it, this is the code that actually “does stuff”. In this context, programming in the medium is code at the class/interface/module level, and programming in the large is code that spans multiple classes and interfaces. For the rest of this post, I’m going to focus on the programming in the small, but it’s good to put everything in context.

How does functional programming improve the code you write in the small?

Before we dive into F#, let’s start with techniques for programming in the small that are more familiar to C# developers. Consider the following code to square a list of numbers:

IList<int> values = new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 }; 

IList<int> squaredValues = new List<int>(); 

for (int i = 0; i < values.Count; i++)
{
    squaredValues.Add(values[i] * values[i]);
}

In the C/C++ days, we were stuck with this. Although this is a simple algorithm, you can see that there is significant amount of overhead describing things that we shouldn’t have to bother with. Instead of saying “square each item in the list” we have to say “Make a new list. Then with each number from zero to the number of items in the list, index into the list with this number and square that value. Finally add that number to the new list”.

C#, like many languages,  gives us a better way to express this algorithm:

var values = Enumerable.Range(0, 10); 

IList<int> squaredValues = new List<int>(); 

foreach (int value in values)
{
    squaredValues.Add(value * value);
}

With a foreach loop, we can see that the code gets better.  Now we say “Make a new list. Then for each element in the input list, square it and add it to the new list”.

Now let’s take a look at a solution that uses a functional approach. No, we’re not going to write F# code yet. Instead, we’re going to write a LINQ query. We’re doing this because LINQ uses some of the functional techniques that makes F# great at programming in the small.

var values = Enumerable.Range(0, 10); 

var squaredValuesQuerySyntax =
    from value in values
    select value * value;

Now our code says “for each value in the list, square it” which is exactly what we were trying to describe in the first place. Even for this trivial example, we wrote less, cleaner code to solve our problem.

Now for F#. The last snipped of C# code is almost the same as what we would write in F# once we re-write our LINQ expression to use extension method syntax:

var squaredValuesExtensionMethodSyntax = values.Select(value=>value*value);

Now, here is the equivalent F# code:

let values = [0..10] 

let results = values |> Seq.map (fun value -> value * value)

In F#, we use the let keyword instead of var, the map function instead of Select, and the |> operator instead of using an extension method. Other than that, the flow of our code is the same as we did with LINQ.

The Story So Far

So, the question is, what makes the functional code above better?

The key observation is that the above code separates the looping algorithm from the squaring algorithm. It’s like we used dependency injection, but it happened at the method level- in the small, instead of at the class level.

Most programmers know that duplicating code is a bad practice, but while coding in imperative languages, many of us ignore that advice when writing loops. Loops are considered to be idioms, and somehow get a free pass from the Don’t Repeat Yourself rule.

Functional languages take a different approach. Instead of constantly re-writing for the same chunks of “simple” loop logic, they use small, single purpose functions to capture the common looping code. The advantage of this approach is twofold. First, you write less code to express looping constructs. Second, you can easily glue these small functions together to perform more complicated operations. It’s the same technique that makes the *nix and PowerShell terminals so powerful.

Going Further With F#

We’ve seen how using functional techniques can improve C# in the small, but what makes F# better at programming in the small? This question would take a book to answer, but here are a few reasons:

-Better library support. F#’s Seq module is far more robust than LINQ and offers many extra “glue” functions to help you stitch your code together.

-Better compiler support. Consider the following example:

public static int Square(int value)
{
    return value * value;
}

public void ProblemsWithTypeInference()
{
    var values = Enumerable.Range(0, 10);

    var results = values.Select<int, int>(Square);
}

We want to say values.Select(Square) without having to specify the type arguments. After all, the compiler has enough information to infer the types. Unfortunately, in C#, the code will not compile if we omit the generic type parameters. [UPDATE: The code will compile without the generic type parameters in C# 4.0. Still, there are a number of other areas where C#’s syntax lags behind F# when using functional techniques.] In F#, this code looks like this:

let Square x = x * x

let GoodTypeInference =
    [0..10]
    |> Seq.map Square

Aside from not having to specify the type of the map function (F#’s equivalent of Select), we didn’t have to specify the type anywhere else either. The F# compiler simply infers the types of each variable or method. This makes code inside the method body extremely concise and easy to work with.

-Functional constructs including option types, discriminated unions, pattern matching, and much more. If you’re coming from a C# background, you probably don’t know a lot about these constructs, but they truly separate F# from C# and were designed specifically to aid the functional style that makes programming in the small better. A few hours spent learning about even a few of these F# language features is well worth the time invested.