[henrikschroder]

> To be honest, the primary use case for lambda expressions in .net is LINQ

Uhm, yes, if you're incapable of using delegates and writing functions that take delegates as parameters, then you'll only use lambda expressions where other people have written such functions, for example in LINQ or the generic collections in the framework.

But if you can use delegates, and if you can use lambda expressions, they're a wonderful tool to make your code more readable, and that in turn reduces bugs.

[gouranga]

If you're considering Action<T> and the numerous Func<T> implementations, then I disagree mostly.

They decrease efferent coupling but do not decrease bugs.

There is no direct correlation between readability and bugs from my experience. Some of the least buggy code I've seen is messy and likewise the most buggy can be the most readable. There is not enough correlation to draw that conclusion.

The metric that is important is the skill of the programmer who fulfilled the specification and their ability to understand the task fully and their ability to translate that understanding to the language at hand and know where and when things will go snap.

Things that DO increase bugs:

1. Crap programmers.

2. Coupling - log increase in side effects of a change.

3. Bad test coverage.

4. Poor design up front.

5. The killer: bad specifications (not even a code issue!).

Using more advanced language features does not necessarily improve things.

[flatline3]

I have one for your list:

0. APIs that don't leverage the compiler to enforce correctness and catch bugs at compile time.

Designing APIs in such a way often requires FP language features. You can often model equivalent APIs without FP features, but they'll be so verbose as to be unusable.