Nombres variables Lambda - ¿para nombre corto o no para nombre corto?

Question

Normalmente, cuando uso lambdas, utilizo "a, b, c, d ..." como nombres de variables ya que los tipos se infieren fácilmente, y los nombres cortos me resultan más fáciles de leer. Aquí está un ejemplo:

var someEnumerable = GetSomeEnumerable(); 
var somethingElseList = someEnumerable.Select(a => a.SomeProperty) 
             .OrderBy(a => a.SomePropertyField); 
var someDictionary = somethingElseList.ToDictionary(a => new SomeClass(a.Prop1), 
                a => a); 

Algunos cuestionan esta denominación, y preferiría ver a largo tecleado nombres, como esto:

var someEnumerable = GetSomeEnumerable(); 
var somethingElseList = someEnumerable.Select(importantObj => importantObj.SomeProperty) 
             .OrderBy(objsInfo => objsInfo.SomePropertyField); 
var someDictionary = somethingElseList.ToDictionary(theInfoId => new SomeClass(theInfoId.Prop1), 
                theInfoId2 => theInfoId2); 

Dado que el alcance es tan estrecho (entre los parens), a menos te vuelves estúpido y los anida, me resulta más fácil leer nombres cortos.

Sin quedar atrapado en los ejemplos tontos de nomenclatura que utilicé anteriormente, ¿cuál es el consenso general sobre los nombres de las variables Lambda? Para nombre corto, o no para nombre corto?

Answer 1

La forma en que generalmente lo hago depende de la colección que está enumerando. Si el nombre de la colección implica qué tipo será el parámetro lambda, entonces solo voy con una sola letra; sin embargo, si la colección no es tan descriptiva, entonces usaré una palabra.

IE:

myCollection.Where(person =>....); //non descriptive collection name 

myPeopleCollection.Where(p=>...); // descriptive collection name 

Answer 2

Intento utilizar nombres de una sola palabra pero significativos. Así que me gustaría ten para usar "persona" en lugar de "p", pero no iría por "recién agregadaPersona".

Esto ocurre con las expresiones de consulta, así - bien puedo violar esta en los ejemplos de usar y tirar rápido, pero por lo general no les gusta:

from p in source 
where p.Age > 10 
select p.Name; 

¡Prefiero ver

from person in source 
where person.Age > 10 
select person.Name; 

Answer 3

Me gusta el nombre corto. Lo hago todo el tiempo. Uso principalmente i, y, x en lambdas, pero uso a, b, c, d en sql.

Answer 4

Se puede pedir mucho a una pregunta de 'consenso' sobre 'nombres'. :)

Estoy de acuerdo en que "la importancia de un buen nombre" es proporcional al alcance del nombre. respuesta de preferir

from person in source ... 

de Jon Skeet es convincente, pero si el nombre se utiliza mucho y sobre todo si la entrada está mejor nombre, creo que prefiero

from p in persons ... 

Answer 5

diría que estoy de acuerdo con BFree. Eso, para mí, dependerá del contexto, pero siempre trato de hacerlo tan 'conciso' como sea posible. Note que digo conciso, y no escueto o corto.

Aquí hay dos ejemplos en el dialecto de LISP Clojure:

user=> (def names ["ryan" "bob" "tom" "tim"]) 
#'user/names 

user=> (filter (fn [name] (.startsWith name "t")) names) 
("tom" "tim") 

Para aquellos que no saben Lisp/Clojure, mi lambda es el argumento de la 'filtro' función. Es decir, "(fn [nombre] ....)". Elegí usar 'nombre' aquí porque es corto pero describe exactamente con qué estoy trabajando. Sin embargo, creo que una 'a', 'i', 'x', etc. sería igual de fácil de leer.

user=> (def odds (iterate (fn [n] (+ n 2)) 1)) 
#'user/odds 

user=> (take 5 odds) 
(1 3 5 7 9) 

Aquí, uso 'n' para representar 'número'. Creo que 'number' estaría bien también, pero es un poco demasiado detallado para mi gusto.

Ciertamente NO usaría los nombres 'nameOfPerson' o 'previousOddNumber'. Es demasiada MANERA demasiada información. También trato de mantener los tipos fuera de mi nombre la mayor parte del tiempo, p. 'nameString'. Encuentro cosas así, la mayoría de las veces, para ser información superflua.

Personalmente, creo que los nombres adicionales prolijos como ese tienden a surgir de la idea de que ayuda a documentar el código. Es especialmente frecuente en idiomas como Java/C#, parece. Creo que esto podría argumentarse en ambos sentidos, dependiendo del estilo del programador. Sin embargo, cuanto más detallado sea el nombre, más apretado (leer frágil) se puede convertir el código. Si mi nombre es muy específico, y es una función que cambia a menudo, entonces es probable que el nombre tenga que cambiar mucho también. Eventualmente, el DEV puede ser flojo y terminará con un nombre que en realidad no describe para qué se usa la variable. Esto no es un problema, si y solo si el programador no supone que el nombre es correcto. Por supuesto, esto probablemente se resuelva rápidamente durante la compilación (porque el programador intentará dividir dos cadenas o algo similar), pero puede causar pérdida de tiempo y confusión en proyectos más grandes.

También abogaría por la concisión debido a la pantalla de bienes raíces. Todavía trato de envolver mis filas en 80 columnas de ancho, y eso es difícil cuando 'myVaraibleNameIsAsLongAsAParagraph'.

En última instancia, creo que siempre va a llegar a un compromiso. Así que no les gusta 'a', pero tal vez puedan estar de acuerdo en que debes esforzarte por nombres de una sola palabra como 'persona' o 'número', y evitar ese horrible caso de camello.

Lo siento por el libro.

Answer 6

Voy con una, dos o tres letras, que forman una representación abreviada del objeto en cuestión.

Persons.Where(p => ...) 
AnalysisCode.Where(ac => ...) 

Answer 7

Como regla general, creo que mientras más explícito sea con los nombres de variable/objeto/método, mejor. Dado que a menudo pasamos la mayor parte del tiempo leyendo el código de otras personas, mientras más fácil nos resulte entender, más rápido podemos enfocarnos en la sintaxis y en la lógica. En estos días con IntelliSense y similares, no es realmente una carga errar del lado de la claridad siempre que sea posible.

Answer 8

Estoy de acuerdo con @Johnny Wey; nombre sus variables, por la misma razón que las nombra en cualquier otro código. No entiendo esta predación fuera de la claridad solo por la naturaleza "en línea" del código. La legibilidad es la clave, a simple vista/sin tener que "pasar el mouse" sobre las cosas; de lo contrario, podría decirse que ninguna variable necesita ser nombrada apropiadamente. Tal vez un pequeño margen de maniobra si se utiliza con algo "Enuerable", pero aún así es agradable ver (de nuevo a simple vista) qué diablos está haciendo el código. Si la inferencia de tipo variable se basa en algún tipo genérico pasado a la clase o algo así, vamos, nómbrelo. Haga que todo el código se lea como una oración; se supone que las computadoras se están adaptando a nosotros ("humanizando"), y no al revés, donde comenzamos a actuar como computadoras y nos hacemos crípticos solo porque podemos/nos sentimos más inteligentes/más geeks de la tecnología cuando lo hacemos (la tentación está ahí, yo ¡kno!). Es fácil escribir un nombre claro y todavía tiene todas las opciones de terminación de frase/Intellisense que hace en los métodos nombrados. Además, flotar en el caso de lambdas no siempre te da información sobre la var (frustrante durante la depuración), por lo que es agradable ver nombres "claros/representativos", especialmente para nuevos desarrolladores que no han pasado por toda la gimnasia mental a ser capaz de inferir los tipos al atravesar el contexto de la declaración (que también puede ser críptico).

Answer 9

El acortamiento es mejor si el propósito de la variable es claro.Lambdas exige un estilo funcional de escritura, por lo que se ve mucho encadenamiento en una sola línea. Es más limpio para ver cuando los mantienes cortos.

Otro caso es cuando a veces se necesita declarar una variable ficticia que no tiene relevancia/significado en ese ámbito. En tales casos, uso _, lo cual es claro para mí. Esto es muy útil sobre todo durante la sobrecarga de métodos, por ejemplo,

public Foo Do() 
{ 
    return Do(_ => true); 
} 

public Foo Do(Func<T, bool> pattern) 
{ 
    return SomethingElse(pattern); 
} 

Answer 10

Con base en las respuestas anteriores, creo que existe un consenso general de que, si no se puede decir que desde el contexto de lo que se trata de, mediante un estudio descriptivo nombre es mejor Por ejemplo:

entities.Where(person => person.Age >= 21); 

En los casos en que el contexto es obvio, sin embargo, un nombre de una sola letra en realidad puede ayudar a facilitar la lectura, ya que hace que sea más fácil centrarse en la información crítica. Por ejemplo:

people.Where(p => p.Age >= 21); o people.Where(x => x.Age >= 21);

La pregunta es, ¿cuál es mejor, o px?

• A favor de p, es un patrón familiar en las consultas SQL y proporciona un pequeño recordatorio adicional que usted está hablando de un Person.
• A favor de x, si cambia el nombre a Person a Customer, no tiene que preocuparse por la reparación de todos sus parámetros lambda. Si hubiera usado p, en realidad sería un poco confuso si su código se convirtió en customers.Where(p => p.Age >= 21), mientras que x es básicamente agnóstico.

Recientemente comencé a usar x, y hasta ahora, no he notado ninguna desventaja significativa, pero por favor comente si no está de acuerdo.

Answer 11

Nuestro equipo no permite las variables de una sola letra, no el evento en lamdas.

Lo que encontramos es que, al igual que en TSQL, cuanto más tiempo vive el código, más confuso se vuelve. Por lo que de lambda

Nos gustaría hacer algo como esto:

people.Where(personFound => personFound.FirstName.Contains("blah!")); 

De esa manera la próxima dev no tendrá que mirar a

people.Where(p => p.FirstName.Contains("blah")); 

Parece fácil de leer, pero siempre lo hace en un primer momento

¿Qué hay de una unión

citizenShip.Join(people, c => c.personid, p => p.persoinid, (p, c) => new { p.FirstName, c.IsCitizen}) 
.Where(pc => pc.FirstName.Contains("blah"); 

lo mismo con los nombres de variables

citizenShip.Join(people, 
       citizenToJoin => citizenToJoin.personid, 
       personToJoin => personToJoin.persoinid, 
       (joinedPerson, joinedCitiznship) => 
        new { joinedPerson.FirstName, joinedCitiznship.IsCitizen}) 
.Where(personAndCitizenshipFound=> personAndCitizenshipFound.FirstName.Contains("blah"); 

Oh, pero esto es confuso y feo. Solo use letras diferentes para que sea menos confuso

citizenShip.Join(people, 
       c => c.personid, 
       p => p.persoinid, 
       (jp, pc) => 
        new { jp.FirstName, jc.IsCitizen}) 
.Where(pc => pc.FirstName.Contains("blah"); 

Aún es confuso, pero ahora es peor.Así rompemos la lambda de modo que refactorizar para facilitar la lectura

var peopleWithCitizenship = citizenShip.Join(people, 
              citizenToJoin => citizenToJoin.personid, 
              personToJoin => personToJoin.persoinid, 
              (joinedPerson, joinedCitiznship) => new { joinedPerson.FirstName, joinedCitiznship.IsCitizen}); 

var peopleWithCitizenshipFilteredByName = peopleWithCitizenship.Where(personAndCitizenshipFound=> personAndCitizenshipFound.FirstName.Contains("blah")); 

Esto no es un ejemplo perfecto, sino hacer que el código legible con muy poco conocimiento de información privilegiada. Encontramos que esto expone el código complejo (lambda) que debe dividirse en fragmentos más pequeños.