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

Question

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

Ejemplos:

lo que estoy acostumbrado a la escritura:

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

lo que estoy viendo está escribiendo en su lugar:

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

Answer 1

Muchos desarrolladores de C# utilizan _ para indicar que el no se va a usar el parámetro y una letra u otro nombre corto cuando se usa el parámetro .

Otros recursos:

• Interesting discussion on using _ instead of ()

Answer 2

no existe un estilo 'establecido' al asignar nombres a las variables lambda. Sin embargo, un guión bajo normalmente significa algún tipo de variable de miembro de instancia, lo que significa que su estilo puede entrar en conflicto con otros estándares de nomenclatura en comparación con un nombre de variable normal.

Long Story Short - Haz lo que funcione para ti.

Answer 3

O podría utilizar un nombre con significado, p.

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

Answer 4

Es un nombre variable, así que me gustaría ir con la idea de que el nombre debería transmitir la información que necesita transmitir. ¿Qué información transporta _?

Para ese mismo fin, ¿qué información transporta 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 afirmación de que es un disco people. Se podría llevarlo aún más lejos:

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

ahora que transmite al lector lo que esa variable es en realidad. 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, más grandes, multilínea, el nombre se vuelve aún más importante.Cuanto más alejada está uno del contexto de lo que significa la variable, más debe el nombre de la variable llevar ese contexto consigo.

Answer 5

Hay una razón por la que puede darle un nombre - porque a veces se puede tener múltiples entradas y la necesidad de diferenciarlos:

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

Answer 6

¿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é le dice?

En mi opinión, elegir el nombre de un parámetro para un lambda debe 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 tiene que significar nada, realmente puede ser cualquier cosa, pero usar un guión bajo o una sola letra para todo lo que tengo en mente hace que el código sea mucho menos legible. (Muchas personas pregonan las ventajas de LINQ/Lambdas como legibilidad, que se vence si se confunden todas las variables).

Answer 7

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

Ex:

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