Tuesday, December 25, 2007
Twelve Days of Refactor! X-mas, Day Six: Compress to Lambda Expression

Presents

Merry X-mas friends! It is indeed X-mas day, and I have returned with a special gift for you. Today, I'm doing my part to bring peace on earth and goodwill toward developers by showing one way that Refactor! Pro can simplify the dreaded lambda expressions. I'll achieve this by showing three refactorings which can be used together to transform some very C-ish code into modern C# 3.0 code.

And now, it's time to continue my anthem.

There's a hush. All is quiet. Then, in the silence, a still, small voice is heard. It grows louder and louder until...

"On the sixth day of X-mas my true love (DevExpress) gave to me..."

Compress to Lambda Expression

I'm not exactly sure why, but every time that I mention "lambda expressions" to developers, their faces show confusion and terror. My guess is that this reaction is caused by one of three things:

  1. A fear of Greek letters (i.e. "lambda")
  2. A fear of all things pointy (i.e. the => operator that lambda expressions bristle with.)
  3. A fear of all things functional (i.e. passing functions around like candy.)

It's for these reasons that I'll demonstrate a couple of other refactorings first. We'll work our way up to lambda expressions. Let's start with something more familiar.

using System;
using System.Collections.Generic;

namespace TwelveDaysOfXmas
{
  class CompressToLambdaExpression
  {
    public static int SumList(List<int> list)
    {
      int sum = 0;
      for(int i = 0; i < list.Count; i++)
        sum += list[i];
      return sum;
    }
  }
}

The code above is an example of the sort of imperative code that we write all of the time. What do I mean by "imperative?" Well, it's like writing a recipe for the computer—describing, in excruciating detail, the steps to solve a problem. There's nothing terribly wrong with that. After all, it's how our computer processors work. They execute a list of instructions—one at a time. However, there is another way that this code can be written.

On the other side of the coin from imperative code is declarative code. Declarative code describes what should be done instead of specifically how it should be done. Writing code declaratively has many potential benefits over the imperative style.

  1. It can be easier to read.
  2. It can be easier for the compiler/runtime to optimize.
  3. It can promote code reuse.

We can write the above code a bit more declaratively by using a foreach loop.

using System;
using System.Collections.Generic;

namespace TwelveDaysOfXmas
{
  class CompressToLambdaExpression
  {
    public static int SumList(List<int> list)
    {
      int sum = 0;
      foreach (int number in list)
        sum += number;
      return sum;
    }
  }
}

That's better! To save keystrokes, Refactor! Pro provides a For to ForEach refactoring that easily performs this conversion. Here's how the preview hint for this refactoring looks:

For to ForEach Preview Hint

Another declarative possibility is to call the List<T>.ForEach method instead using of a foreach loop. In that case, we would pass an anonymous delegate to the method as the body of the loop like so:

using System;
using System.Collections.Generic;

namespace TwelveDaysOfXmas
{
  class CompressToLambdaExpression
  {
    public static int SumList(List<int> list)
    {
      int sum = 0;
      list.ForEach(delegate(int number)
      {
        sum += number;
      });
      return sum;
    }
  }
}}

In a declarative fashion, the above code states, "loop through the entire list, and execute this function (delegate) for each item in the list." A powerful feature of the anonymous delegate is that it references a variable (sum) outside of the delegate body, producing a closure. (For more information on closures, check out this article.)

Of course, Refactor! Pro provides a refactoring that renders this transformation trivial: Introduce ForEach Action. The screenshot below shows the preview hint for this refactoring.

Introduce ForEach Action Preview Hint

Now, some of you might be saying, "Whoa! That anonymous delegate sure is an ugly little spud1." You're right, it is. Enter the lambda expression.

I don't want to present an entire history of lambda expressions here, but you should understand that they pre-date computers entirely. So, if you've been wondering where these crazy new things came from, know that they really aren't crazy "new" things. Lambda expressions have been around since the 1930s.

A C# lambda expression is really just an anonymous delegate on steroids. It retains all of the functionality of an anonymous delegate but adds conciseness, better type inference and even pseudo-meta-programming via expression trees.

Using a lambda expression is straight-forward, if a little funky:

using System;
using System.Collections.Generic;

namespace TwelveDaysOfXmas
{
  class CompressToLambdaExpression
  {
    public static int SumList(List<int> list)
    {
      int sum = 0;
      list.ForEach(number => sum += number);
      return sum;
    }
  }
}

If this is the first time that you've seen a lambda expression in the wild, compare it with the anonymous delegate that we used before. The parameters are declared to the left of the => operator, and the body is declared to the right. The compiler works out the types of the parameters so there's no need to specify them.

Of course, my X-mas present for you today is another refactoring: Compress to Lambda Expression. This refactoring (available now) converts anonymous delegates into lambda expressions, saving dozens of keystrokes and head scratches. Again, here is the preview hint to show what this refactoring does:

Compress to Lambda Expression Preview Hint

View Screencast of These Refactorings in Action!

As always, I'm demonstrating features of Refactor! Pro that can be used to leverage the new features in Visual Studio 2008 right now. In fact, all of the refactorings above have been shipping for several months. In other words, these aren't in some super-secret beta. They have been released.

As another refactoring goodie has been successfully unwrapped, it's time to take my leave of you. Until tomorrow, have a warm and happy X-mas!

1Ray Stanz, Ghostbusters.

12 Days of Refactor! | C# | Quality Code | Refactor! | Visual Studio
posted on Tuesday, December 25, 2007 9:31:26 AM (Pacific Standard Time, UTC-08:00)  #    Comments [2]

kick it on DotNetKicks.com
Related posts:
Empty Nothings
Naming Anonymous Types with Generate from Usage
Lesser-Known VB: Customizing the Completion List
YAPES: Problem Seven, Part 2
YAPES: Problem Seven, Part 1
YAPES: Problem Six
Wednesday, December 26, 2007 11:34:40 PM (Pacific Standard Time, UTC-08:00)
Can Refactor! Pro take is one step further, to use the Sum extension method from System.Linq? It still uses a lambda expression (albeit a simpler one), and collapses the function down to a single line. E.g.

public static int SumList(List<int> list)
{
return list.Sum(number => number);
}

When the list is numbers already, the lambda doesn't have much to do. In other cases, e.g. when summing objects that are not just numbers, it converts each object into the numeric value to sum.

Might be tricky for a refactoring tool to choose the right extension method...
John Rusk
Monday, December 31, 2007 12:10:33 PM (Pacific Standard Time, UTC-08:00)
Hi John,

Yes, you've realized just how contrived my code sample is. :-)

In reality, a lambda isn't needed at all. Just do this:

list.Sum();
Dustin Campbell
Comments are closed.

Page rendered at Wednesday, February 08, 2012 9:24:28 AM (Pacific Standard Time, UTC-08:00)