I promise this is a short post. I have recently fallen in love with LINQ, but more recently I have grown to appreciate Lambda expressions. I don’t know if this is because I find them simple to read, or because I once took a class as an undergraduate student where we built a modern language compiler using just Lambda expressions. One of the things I notice often is the lack of Lambda expressions in C# 3.0 code that I read at different employers.
Maybe it’s because I previously spent most of my career as a state IT professional where .NET 2.0 is considered a fairly young, high-risk technology. Salivate on that for a moment…
Now that you’re back and covered in drool, I just want to point out 2 scenarios where I think a Lambda expression actually makes code more readable to someone not familiar with modern OO languages. One of my personal favorites are event handlers. You’ve always seen them like this:
_object.actionCompleted += new actionCompletedEventHandler(object_actionCompleted);
_object.actionAsync();
static void object_actionCompleted(object sender, actionCompletedEventArgs e)
{
(sender as ActionObject).Property = (e.Result as PropertyType);
}
This is the standard .NET way of doing even handling. For us longtime C# developers, this seems very elementary. Sometimes when I have to introduce a JAVA guy to C# or some other OO language, I end up having to explain the idea behind event handlers and also go into a long winded discussion about asynchronous programming. I find it a lot easier to just drag lambda expressions into the conversation and introduce event handling to them like this:
_object.actionCompleted += (sender, eventArgs) =>
{
_object.Property = (eventArgs.Result as PropertyType);
};
_object.actionAsync();
I know there are some people out there that disagree with me but amuse me by at least considering this. When you write this as a lambda expression, you tell the none OO programmer that this method is asynchronous, it will run whenever the object’s actionCompleted event is fired. Obviously in the context of this example, the event will fire when the actionAsync() method is finished running. It’s much simpler to explain that the code in the brackets would run at that point then it is to say that another method would be called. It makes it also easier to read when you don’t have to implicitly or explicitly cast the sender object in the event handler method.
Let’s look at a LINQ method. First I’ll give you the collection as context for this situation:
var animals = new Dictionary<int, string>
{
{76518, "Frog"}, {9865, "Eagle"},
{4809, "Gazelle"}, {21849, "Panda"},
{56547, "Elephant"}, {10365, "Ape"}
};
Pretty zoological, huh? Well, this collection could easily be sorted and organized using LINQ statements. Here are some examples:
var LongNames = from a in animals
where a.Value.Length > 5
orderby a.Key
select a;
var KeyCodes = from a in
from a in animals
select String.Format("{0}-{1}", a.Key, a.Value)
orderby a.Length
select a;
This is a nice query in LINQ format and if your developer has any DBA experience this should be sufficient. But I find it easier to read when you give it some Lambda spice:
var LongNames = animals
.Where(a => a.Value.Length > 5)
.OrderBy(a => a.Key);
var KeyCodes = animals
.Select(a => String.Format("{0}-{1}", a.Key, a.Value))
.OrderBy(a => a.Length);
Yes, I did run Enumerable.SequenceEqual() to make sure they come up with absolutely equal collections. I am of the opinion that the Lambda expressions make this a lot easier to read. However, I know there are many out there who disagree. Please respond in the comments, let’s start a discussion. I am very curious as to whether people think Lambda expressions make C# easier or harder to read.