Understanding Lambdas in C#
I’m a big fan of the Microsoft documentation pages and here’s your reference for todays topic. But documentation is often scary to beginners and so I want to offer some initial comments here that hopefully make learning lambdas easier for you. I remember seeing them when I was new and being intimidated by them. But I assure you they are a lot less scary than they look.
Think of lambdas as just a fancy mathematical name to describe an anonymous function. If you feel just as puzzled by the term “anonymous function”, don’t be. All I mean is that it is a function that doesn’t have a name. How do you call a function that doesn’t have a name you ask? Well, you drop it (including its implementation) right in place where it is needed. These lambdas/anonymous function can be thought of as “throw away” behavior, something we only need to use once. If you need some behavior to be used a bunch around your program, invoked from multiple places, then take the time to make a named function like you usually do. That’s how I decide which form to give my behaviors (methods) anyway. You wouldn’t want to copy the same lambda across many parts of your code. This would violate the DRY principle and not be fun to maintain if you had to eventually change the behavior. You would then have to find all occurrences and modify each of them in the same way.
Language designers didn’t make these funny looking bits of code to confuse people. They are actually handy when you get comfortable with them. Imagine yourself as someone who writes functions all day and every time you need to use the verbose syntax you’re accustomed to. You would get annoyed by that after a while, it would seem overly formal. Lambdas to the rescue! Use a more concise syntax to perform the same logic.
Let’s take a look at a lambda expression and an equivalent function:
Notice how I have two lines starting with “var doubles = …”. You only need one of them, which is why I commented the other out. I wanted to illustrate how you could use the LINQ method Select with a named function (DoubleMe) or how you could just drop the implementation right in place. You get the same result, as shown in the SandBox.exe window at the bottom of the image. But can you see how the two methods are equivalent? The lambda doesn’t bother with the access modifier (“private”), the “static” keyword, the return type, or the name. You can see how much less typing this is, even for the simplest of examples.
You can see what they have in common- a single parameter and the method logic. You are probably wondering how the compiler makes this lambda magic happen. We didn’t even specify the type of the parameter! But think about it. The type of the parameter can be inferred from the “vals” array- it contains integers. Refer to the Select method documentation if you want further explanation:
You can see how I highlighted the TSource generic type. Notice how the parameter of the Func (function) matches the type of the IEnumerable collection (the array in our example).
And the other part of the lambda, the function body/logic, can be used to infer the return type too. If the parameter n is an integer and you are multiplying it by 2 (another integer), then the result is clearly an integer.
I hope this article helped you see the equivalence between the lambda and the named function. Obviously they get more complicated than this simple example, but you need to be able to see simple first. Crawl, then walk, then run. And in my opinion some people abuse it by making lambdas that are just too long and messy. When I’m in that situation, I’ll just make a named function and use that.
As usual, hit me up with questions, comments, and feedback.