Do Lambda expressions smell?
-
I saw some nasty code recently. A function took a parameter of a type that was something like Func. You get no clues about the parameters. When (if ever) should we use Lambdas? They seem like a shortcut which will save some time during the initial development, but lose more time later. I think the old fashioned way will almost always be more readable. One place where lambdas tend to be useful is when using LINQ (to SQL or Entity Framework). Is it really that good though? SQL is designed for the job, and performs MUCH better, so why use LINQ to SQL? If we have automated tests then we can fully test that the code is correctly wired up to the SQL.
-
I saw some nasty code recently. A function took a parameter of a type that was something like Func. You get no clues about the parameters. When (if ever) should we use Lambdas? They seem like a shortcut which will save some time during the initial development, but lose more time later. I think the old fashioned way will almost always be more readable. One place where lambdas tend to be useful is when using LINQ (to SQL or Entity Framework). Is it really that good though? SQL is designed for the job, and performs MUCH better, so why use LINQ to SQL? If we have automated tests then we can fully test that the code is correctly wired up to the SQL.
They're useful shortcuts. Func is just a shortcut for when you don't want to define a delegate yourself. These are all pretty much equivalent:
Func<string, bool>
Predicate<string>
delegate bool MyStringTest(string s)Lambda expressions themselves, I find extremely useful... I love being able to type:
People.Where(a=>a.FirstName.StartsWith("B"));
This use of lambdas has nothing to do with SQL, aside from a syntax resemblance between the long-form LINQ queries and SQL queries (I prefer the shorthand notation). Remember that LINQ extensions aren't only made for database access... They're great for working with collections.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
I saw some nasty code recently. A function took a parameter of a type that was something like Func. You get no clues about the parameters. When (if ever) should we use Lambdas? They seem like a shortcut which will save some time during the initial development, but lose more time later. I think the old fashioned way will almost always be more readable. One place where lambdas tend to be useful is when using LINQ (to SQL or Entity Framework). Is it really that good though? SQL is designed for the job, and performs MUCH better, so why use LINQ to SQL? If we have automated tests then we can fully test that the code is correctly wired up to the SQL.
A lambda expression makes a good short-cut for many well known items, every wanted a one off-anon event, lambda, want to sort a list and not implement IComparable, lambda. However, I often refactor many of my lambda expressions into real code.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
I saw some nasty code recently. A function took a parameter of a type that was something like Func. You get no clues about the parameters. When (if ever) should we use Lambdas? They seem like a shortcut which will save some time during the initial development, but lose more time later. I think the old fashioned way will almost always be more readable. One place where lambdas tend to be useful is when using LINQ (to SQL or Entity Framework). Is it really that good though? SQL is designed for the job, and performs MUCH better, so why use LINQ to SQL? If we have automated tests then we can fully test that the code is correctly wired up to the SQL.
Member 4487083 wrote:
the old fashioned way will almost always be more readable
I'm with you, mainly because I'm old-school :cool:. But I suppose it's similar to using a Regular Expression rather than writing a custom parser. Or even like including SQL in your code rather than calling an API of some sort.
-
Member 4487083 wrote:
the old fashioned way will almost always be more readable
I'm with you, mainly because I'm old-school :cool:. But I suppose it's similar to using a Regular Expression rather than writing a custom parser. Or even like including SQL in your code rather than calling an API of some sort.
PIEBALDconsult wrote:
But I suppose it's similar to using a Regular Expression rather than writing a custom parser. Or even like including SQL in your code rather than calling an API of some sort.
Pretty good analogy actually. Mainly because people misuse those all the time too. And as for "custom parser" there are probably quite a few cases where people attempt to use a regex when they problem can be solved with nothing more than a simple index or split.
-
I saw some nasty code recently. A function took a parameter of a type that was something like Func. You get no clues about the parameters. When (if ever) should we use Lambdas? They seem like a shortcut which will save some time during the initial development, but lose more time later. I think the old fashioned way will almost always be more readable. One place where lambdas tend to be useful is when using LINQ (to SQL or Entity Framework). Is it really that good though? SQL is designed for the job, and performs MUCH better, so why use LINQ to SQL? If we have automated tests then we can fully test that the code is correctly wired up to the SQL.
-
A lambda expression makes a good short-cut for many well known items, every wanted a one off-anon event, lambda, want to sort a list and not implement IComparable, lambda. However, I often refactor many of my lambda expressions into real code.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
They're useful shortcuts. Func is just a shortcut for when you don't want to define a delegate yourself. These are all pretty much equivalent:
Func<string, bool>
Predicate<string>
delegate bool MyStringTest(string s)Lambda expressions themselves, I find extremely useful... I love being able to type:
People.Where(a=>a.FirstName.StartsWith("B"));
This use of lambdas has nothing to do with SQL, aside from a syntax resemblance between the long-form LINQ queries and SQL queries (I prefer the shorthand notation). Remember that LINQ extensions aren't only made for database access... They're great for working with collections.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Exactly, it was made for querying an array of objects. If you are working with db connection you would more use T-SQL. With using lamdba's, yeah, they are handy but if the code is long, or if the method is virtual/abstract I would prefer not to and more than not, I mainly only use them in the LINQ querying on array types unless it is complex where I would return Predicate/Func/Action from a methods also where I could add some more parameters to help my need in filtering.
-
I saw some nasty code recently. A function took a parameter of a type that was something like Func. You get no clues about the parameters. When (if ever) should we use Lambdas? They seem like a shortcut which will save some time during the initial development, but lose more time later. I think the old fashioned way will almost always be more readable. One place where lambdas tend to be useful is when using LINQ (to SQL or Entity Framework). Is it really that good though? SQL is designed for the job, and performs MUCH better, so why use LINQ to SQL? If we have automated tests then we can fully test that the code is correctly wired up to the SQL.
Func is a generic type, you'd usually have information about the parameters. Lambdas are really nice for simple functions (in the mathematical or FP sense), where the boilerplate text for defining a method would be a significant portion of the code, and where the calculation type is simple enough that everything can be inferred (by the reader; the computer has no problem anyway!). I've also seen them used for event handlers, where the parameter types are well known. LINQ to SQL, if used correctly, creates queries very similar to what you'd make yourself, and manages the result in a much more friendly fashion. It doesn't have that much to do with lambdas though apart from the query related functions that take a lambda parameter.