Wann man Lambda-Ausdrücke nicht verwenden sollte

Question

Viele Fragen werden auf Stack Overflow beantwortet, wobei die Mitglieder angeben, wie sie diese realen/zeitlichen Probleme mithilfe von Lambda-Ausdrücke .

Verwenden wir sie zu häufig, und berücksichtigen wir die Auswirkungen der Verwendung von Lambda-Ausdrücken auf die Leistung?

Ich fand ein paar Artikel, die die Leistung Auswirkungen von Lambda vs anonyme Delegierte vs erforscht for / foreach Schleifen mit unterschiedlichen Ergebnissen

1. Anonyme Delegierte vs. Lambda-Ausdrücke vs. Funktionsaufrufe Leistung
2. Leistung von foreach vs. List.ForEach
3. .NET/C# Schleifenleistungstest (FOR, FOREACH, LINQ, & Lambda) .
4. DataTable.Select ist schneller als LINQ

Was sollten die Bewertungskriterien bei der Auswahl der geeigneten Lösung sein? Abgesehen von dem offensichtlichen Grund, dass der Code bei Verwendung von Lambdas prägnanter und lesbarer ist.

Answer 1

Faustformel:

1. Schreiben Sie Ihren Code so, dass er natürlich und lesbar ist.
2. Vermeiden Sie Code-Duplikate (Lambda-Ausdrücke erfordern möglicherweise ein wenig mehr Sorgfalt).
3. Optimieren Sie nur dann, wenn es ein Problem gibt, und auch nur dann, wenn Sie Daten haben, die belegen, dass das Problem tatsächlich besteht.

Answer 2

Jedes Mal, wenn das Lambda seine Argumente direkt an eine andere Funktion weitergibt. Erstellen Sie kein Lambda für die Anwendung einer Funktion.

Beispiel:

var coll = new ObservableCollection<int>();
myInts.ForEach(x => coll.Add(x))

Ist netter als:

var coll = new ObservableCollection<int>();
myInts.ForEach(coll.Add)

Die wichtigste Ausnahme ist, wenn die Typinferenz von C# aus welchem Grund auch immer fehlschlägt (und das ist sehr oft der Fall).

Answer 3

Wenn Sie eine Rekursion benötigen, sollten Sie keine Lambdas verwenden, sonst sind Sie am Ende sehr abgelenkt. !

Answer 4

Lambda-Ausdrücke sind cool. Über älter delegate Syntax Sie haben einige Vorteile, z. B. können sie entweder in anonyme Funktions- oder Ausdrucksbäume umgewandelt werden, die Parametertypen werden aus der Deklaration abgeleitet, sie sind sauberer und prägnanter, usw. Ich sehe keinen wirklichen Nutzen darin, keinen Lambda-Ausdruck zu verwenden, wenn man eine anonyme Funktion braucht. Ein nicht so großer Vorteil des früheren Stils ist, dass man die Parameterdeklaration ganz weglassen kann, wenn sie nicht verwendet werden. Zum Beispiel

Action<int> a = delegate { }; //takes one argument, but no argument specified

Dies ist nützlich, wenn Sie einen leeren Delegaten deklarieren müssen, der nichts tut, aber nicht zu den stark Grund genug, keine Lambdas zu verwenden.

Mit Lambdas können Sie schnell anonyme Methoden schreiben. Das macht Lambdas überall dort bedeutungslos, wo anonyme Methoden bedeutungslos werden, d.h. wo benannte Methoden mehr Sinn machen. Über benannte Methoden Anonyme Methoden können nachteilig sein (das hat nichts mit Lambda-Ausdrücken an sich zu tun, aber da Lambdas heutzutage weitgehend anonyme Methoden darstellen, ist das relevant):

1. weil sie dazu neigen, Logik zu duplizieren (was oft der Fall ist, Wiederverwendung ist schwierig)

2. wenn es nicht notwendig ist, an einen zu schreiben, wie:

   //this is unnecessary 
   Func<string, int> f = x => int.Parse(x);
   
   //this is enough
   Func<string, int> f = int.Parse;

3. da das Schreiben eines anonymen Iteratorblocks unmöglich ist.

   Func<IEnumerable<int>> f = () => { yield return 0; }; //impossible

4. da rekursive Lambdas eine weitere Zeile mit Eigenheiten erfordern, wie

   Func<int, int> f = null;
   f = x => (x <= 1) ? 1 : x * f(x - 1);

5. Nun, da die Reflexion etwas unordentlicher ist, aber das ist doch egal, oder?

Abgesehen von Punkt 3 sind die übrigen Punkte nicht stark Gründe nicht zu verwenden Lambdas.

Siehe auch dies Gewinde darüber, was nachteilig ist an Func/Action Delegaten, da sie oft zusammen mit Lambda-Ausdrücken verwendet werden.