views:

102

answers:

2

In Jeffrey Richter's "CLR via C#" (the .net 2.0 edtion page, 353) he says that as a self-discipline, he never makes anonymous functions longer than 3 lines of code in length. He cites mostly readability / understandability as his reasons. This suites me fine, because I already had a self-discipline of using no more than 5 lines for an anonymous method.

But how does that "coding standard" advice stack against lambda's? At face value, I'd treat them the same - keeping a lambda equally as short. But how do others feel about this? In particular, when lambda's are being used where (arguably) they shine brightest - when used in LINQ statements - is there genuine cause to abandon that self-discipline / coding standard?

+2  A: 

Bear in mind that things have changed a lot since 2.0. For example, consider .NET 4's Parallel Extensions, which use delegates heavily. You might have:

Parallel.For(0, 100, i => 
{
    // Potentially significant amounts of code
});

To me it doesn't matter whether this is a lambda expression or an anonymous method - it's not really being used in the same way that delegates typically were in .NET 2.0.

Within normal LINQ, I don't typically find myself using large lambda expressions - certainly not in terms of the number of statements. Sometimes a particular single expression will be quite long in terms of lines because it's projecting a number of properties; the alternative is having huge lines!

In fact, LINQ tends to favour single-expression lambda expressions (which don't even have braces). I'd be fairly surprised to see a good use of LINQ which had a lambda expression with 5 statements in.

Jon Skeet
So I think you are saying that 99% of the time, where "good" use of LINQ is concerned, you'd expect lambdas to be short (e.g. usually 3 lines or less). Conversely, what did you mean by "sometimes quite long?" Do you mean in the 1% case you'd find a lambda that was legitimately 20+ code lines long?
Brent Arias
Oh wait, I get it. You are "counting semicolons" as statements, and something akin to a fluent API usage as "lines." Gotcha. :)
Brent Arias
For the "Parallel.For", what does "significant amounts of code" mean? 120 statements? 10 statements? What is the value in having "potentially significant amounts of code" in that lambda? Why not follow the advice posted in this topic by Steven?
Brent Arias
@Mystagogue: It's a matter of personal taste. 10 statements would normally be fine IMO, but 120 ought to be refactored anyway... Note that lambdas can also capture local variables in the context, which may be awkward to do elsewhere.
Jon Skeet
+1  A: 

I don't know if having a guideline for short lambda's and delegates is really useful. However, have a guideline for having short functions. The methods I write are on average 6 or 7 lines long. Functions should hardly ever be 20 lines long. You should create the most readable code and if you follow Robert Martin's or Steve McConnell's advice, they tell you to keep functions short and also keep the inner part of loops as short of possible, favorably just a single method call.

So you shouldn't write a for loop as follows:

for (int i = 0; i < 100; i++)
{
    // Potentially significant amounts of code
}

but simply with a single method call inside the loop:

for (int i = 0; i < 100; i++)
{
    WellDescribedOperationOnElementI(i);
}

With this in mind, while I in general agree with Jon Skeet’s answer, I don't see any reason why you shouldn't want his example to be written as:

Parallel.For(0, 100, i =>
{
    WellDescribedPartOfHeavyCalculation(i);
});

or

Parallel.For(0, 100, i => WellDescribedPartOfHeavyCalculation(i));

or even:

Parallel.For(0, 100, WellDescribedPartOfHeavyCalculation);

Always go for the most readable code, and many times this means: short anonymous methods, and short lambda's, but most of all short -but well described- methods.

Steven
Your answer was ironic for me. Had I just guessed, I might imagine responders would say at best "lambdas should be same length or shorter than functions" not "lambdas short, and functions even shorter." What is it that makes functions harder to read than lambdas?
Brent Arias
Because lambdas are usually part of a method, it is practially impossible to make a method shorter than a lambda. Methods aren't harder to read than lambdas. No, I think that excessive use of lambdas could make your code less readable. With great power, yada yada.
Steven