tutorial expressions expresiones c# coding-style lambda

expresiones - lambda expressions c#



Estilo C#: Lambdas,_=> o x=>? (7)

He usado expresiones lambda en otros idiomas antes de usarlas en C #, por lo que me acostumbré a usar _ para lambdas simples en la forma de Func<T, TResult>, especialmente para las lambdas simples donde el cuerpo es solo una expresión representando el valor de retorno (predicados, etc.). Sin embargo, en C # a menudo veo que se usan letras simples en lugar de _ para estos mismos tipos de expresiones lambda, como x,y,z,i,j,k . El enfoque de letras me parece extraño ya que esas letras ya tienen otro significado típico en el uso común, para las variables de bucle. _ menudo es más fácil de leer en mi opinión. ¿El estilo de una sola letra es realmente el estilo establecido para las lambdas en C #?

Ejemplos:

Lo que estoy acostumbrado a escribir:

var ages = people.Select(_ => _.Age);

Lo que estoy viendo se escribe en su lugar:

var ages = people.Select(x => x.Age); // choice of ''x'' is not consistent


¿Cómo es una función lambda tan diferente de cualquier otro método. Si alguien fuera a publicar código con un método como:

public static int getAge(Person _) { return _.Age; }

o

public static int getAge(Person x) { return x.Age; }

¿Qué dirías?

En mi opinión, elegir el nombre de un parámetro para un lambda debería ser tan significativo como el parámetro de cualquier otro método. Podría hacer excepciones ocasionales para una función de identidad x => x porque en ese caso la variable no necesita significar nada, realmente puede ser cualquier cosa, pero usar un guión bajo o una sola letra para todo lo que tengo en mente solo hace que el código mucho menos legible. (Mucha gente dice que las ventajas de LINQ / Lambdas son legibles, lo que se anula si confunde todas las variables).


En C #, _ se usa para las variables de clase (atributo) y _ no se usa para las variables locales. Por lo tanto, es bueno usar un nombre significativo para las variables locales y las variables de clase.

Ex:

var personList = (from person in people where person.Age > 18 select person).ToList();


Es un nombre variable, por lo que me gustaría pensar que el nombre debe transmitir la información que debe transmitir. ¿Qué información transmite _ ?

Para ese mismo fin, ¿qué información transmite x ?

Podría escribir tu ejemplo como este:

var ages = people.Select(p => p.Age);

La idea es que siento que la p al menos sugiere en el contexto de toda la declaración que es un registro de people . Podrías llevarlo aún más lejos:

var ages = people.Select(person => person.Age);

Ahora eso le transmite al lector lo que realmente es esa variable. Por supuesto, para una declaración tan pequeña, se puede argumentar que es excesivo. No lo creo, pero es una cuestión de preferencia. (Y no solo su preferencia, sino la preferencia de cualquiera que tenga que admitir este código).

Para expresiones lambda complejas de líneas múltiples y significativamente más grandes, el nombre se vuelve aún más importante. Cuanto más lejos está uno del contexto de lo que significa la variable, más necesita el nombre de la variable para llevar ese contexto con ella.


Hay una razón por la que puedes darle un nombre, porque a veces puedes tener múltiples entradas y necesitas diferenciarlas:

Func<int,int,int> product = (num1, num2) => (num1 * num2); // takes in two ints, and returns one int int x = product(2, 3);



No hay un estilo ''establecido'' para nombrar las variables lambda. Sin embargo, un guión bajo generalmente significa algún tipo de variable miembro de instancia, lo que significa que su estilo puede entrar en conflicto con otros estándares de nombres en comparación con un nombre de variable normal.

Long Story Short - Haz lo que te funcione.


O podrías usar un nombre significativo, por ejemplo

var ages = people.Select(person => person.Age);