Dieser Punkt ist ein Plädoyer für den Einsatz von LINQ, speziell auch LINQ to Objects.

Ich weiß nicht wirklich warum das so ist, aber mir kommen immer wieder Entwickler unter, die LINQ bislang links liegen lassen. Teilweise, weil sie den Mehrwert nicht sehen; manchmal – bei Produkten, die schon länger in der Wartung sind – kommt auch das Argument, dass mit LINQ eine neue Komplexität in den Code Einzug halten würde, der nicht jeder Entwickler gewachsen wäre. Sic!

Ich kann dabei Patricks Aussage nur zustimmen:

[…] there are cases where a single LINQ statement can easily replace dozens of statements in an iterative loop (or nested loops) in your code.  And less code general means less opportunities for bugs to be introduced.

Auf der anderen Seite fehlt in Patricks Liste das andere Extrem, das ich mittlerweile immer öfter sehe, und daher als Unterpunkt ergänzen würde:

Common Mistake #4a: LINQ Spaghetti Code.

Ich habe schon Monster-Ausdrücke in LINQ gesehen, bei denen Abfragen geschachtelt, Daten im Select gemappt wurden und Verarbeitungen in Lambda-Ausdrücken versenkt wurden. Lesbarkeit good-bye!

Und scheinbar bin ich da nicht der Einzige, sonst würde der Einsatz von LINQ in den Kommentaren nicht derart heftig und kontrovers diskutiert werden:

LINQ statements should only be used for simple processing. Complex LINQ statement is write-only code: hard to read and understand, very hard to debug, and thus expensive to maintain. (Soonts)

I love LINQ to interact with SQL in C#, but When it comes to arrays or lists, It’s very rare it is more readable or more maintainable than a classic for loop. (Garrett)

Allerdings ist das kein Grund, LINQ in Bausch und Boden zu verdammen, wie es manche Kommentatoren tun:

In our engineering section use of LINQ is rejected in code reviews, its viewed as unnecessary and just complicates code. (brianm101)

My take from this list is wow, serious language design issues! […] LINQ is its own special little area of hell IMNSHO. […] That’s just asking for problems. (Techy)

LINQ hat seine Fallen und wie jedes andere Sprachmittel auch, kann man es richtig und falsch einsetzen. Wer es nutzt, wie im von Garrett bereitgestellten Beispiel dargestellt (leider nicht mehr verfügbar, aber hier ist eine schöne Alternative), der macht sicher etwas falsch! Seine Schlussfolgerung

The above code is what LINQ always ends up looking like, at best.

ist allerdings Quatsch. Genauso könnte man argumentieren, dass Methoden mit Klammerbergen aus geschachtelten Schleifen, if-Abfragen etc. die Strukturierte Programmierung generell in Frage stellen.

Wer mehr Informationen zu LINQ sucht findet dazu auf MSDN diverse Beispiele. Zum Ausprobieren ist LINQPad sehr beliebt.