¿Me pasarán cosas malas si nombro mis matrices, colecciones, listas, enumerables, etc. solo el plural de lo que contienen?

Question

Siempre he pensado que era una "mejor práctica" ser explícito al nombrar las variables de mi colección. Por lo tanto, si tuviera una colección de objetos Car, normalmente nombraría un Car[]carArray y un List<Car>carList.

Y entonces el 99% del tiempo, terminan simplemente haciendo algo como ...

foreach (Car car in carArray) 
{ 
    ... 
} 

... y estoy pensando, Me podría haber llamado la matriz cars, y wouldn No ha hecho ninguna diferencia.

Y ahora que tenemos IEnumberable<T>, de hecho me pregunto si podría considerar escribir algo como carIEnumerable? o carEnumerable. Hasta ahora, la respuesta ha sido "no".

Mi pensamiento aquí es que el tipo de colección a menudo no importa, y cuando lo hace, sigue sin importar si el tipo de colección está escrito en el nombre de la variable. Acabo de tener un caso en el que tuve que cambiar de IEnumerable<Car> a List<Car> porque necesitaba "acceso de corchete" a los artículos (por ejemplo, carList[3]). En ese caso, los dos tipos de colección no se comportan igual, pero ¿nombrar la variable cars ha sido un problema aquí?

Para no agregar otra capa de complejidad a esta pregunta, ¿qué ocurre si uso var? Por ejemplo,

var cars = GetCars(); 

ciertamente puedo decirle cars es una especie de colección. Puedo iterarlo. Si estoy usando LINQ, puedo usar métodos de extensión. Más importante aún, si más tarde cambio el tipo de colección, habría mucho menos código con el que meterme. var seguiría siendo var y cars seguiría siendo cars. Eso me parece muy atractivo, y tengo problemas para ver muchas desventajas.

Entonces, solo para asegurarme de que mi pregunta es clara: ¿cómo se nombran las variables de recolección y por qué? ¿Existe una legibilidad seria o un costo de claridad para simplemente "pluralizar" el nombre del artículo?

Answer 1

El problema con este tipo de nomenclatura es que se concentra demasiado en la implementación real en lugar del propósito de la propiedad. En lugar de CarArray, puede usar OwnedCars, o lo que le diga al usuario por qué esa enumeración está allí.

Creo que nombrar la variable de bucle "coche" en un pequeño foreach -loop está bien.

Si se escribe var cars = GetCars(), el compilador observa el tipo en el lado derecho de la asignación, en este caso posiblemente IEnumerable<Car>, y da cars ese tipo. Incluso puedes verlo en usos posteriores de la variable si pasas el mouse sobre ella con el mouse.

Si cambia el tipo de una colección y no tiene que cambiar su código porque está usando var, piense en el hecho de que esos diferentes tipos de colecciones probablemente tengan algo en común que le permita realizar las mismas operaciones en ellos. Probablemente sea IEnumerable si los usa en foreach bucles.

Así que podría exponer esas colecciones como IEnumerable, por lo que los usuarios de su clase no dependen demasiado de una determinada implementación.

Answer 2

Nunca me gustó el enfoque de "poner el tipo de variable en su nombre" - Realmente creo que interfiere con la lectura fluida de la fuente. Creo que el código debe leerse como una historia, por lo que tiene perfecto sentido para mí que un grupo de automóviles (y no me importa si se implementa como una matriz, una lista vinculada, un montón, conjunto o lo que sea) se llame "Cars":

foreach (Car currentCar : ParkingLog.getCars()) { 
    stolenCars.add(currentCar);  
} 

fencer.cars = stolenCars; 

Funciona para mí.

Answer 3

Personalmente evito usar el tipo de la colección en el nombre de la variable siempre que sea posible. Puede verse bien, pero es una restricción imposible de aplicar que otros desarrolladores harán con el tiempo. Si el tipo de variable es realmente importante para una operación en particular, consideraría reescribir el código para que sea ...

1. Menos preocupado por la implementación de la colección específica
2. Haga que el código más corto/más concisa al punto del tipo de la variable no es ambigua

O en otras palabras, que no me gusta de Hungría notación.

Answer 4

var car = cars.Where(c => c.Name == "Robin Reliant"); 

La legibilidad gana.

Por lo tanto, voy con la pluralización.

Bondad,

Dan

Answer 5

La diferencia entre "coches" y "carArray" es la naturaleza propia documentación del código. No es necesario averiguar qué tipo de colección está utilizando si está integrada en el nombre. En un programa trivial, realmente no importa, pero en algo más significativo, el ahorro de tiempo es importante.

Answer 6

Creo que usar el plural tiene perfecto sentido, y ese es el método que generalmente uso en mi código. Nunca he encontrado que tener el tipo de datos como parte del nombre de la variable sea de gran ayuda.

Answer 7

Por lo general, empiezo por pluralizar (por ejemplo, automóviles). A menudo, también tendrá una variable local en forma singular (por ejemplo, automóvil), a veces puede ser incómodo leer el código con dos nombres de variable muy similares, en cuyo caso encontraré un nuevo nombre para una de las variables.

Casi nunca usaría carArray, más probablemente todos los autos, o SelectedCars o algo apropiado.

Answer 8

Ciertamente no debería agregar el nombre del tipo como parte del nombre de la variable, más o menos por la razón que mencionó. Personalmente, si tuviera una colección de objetos Car, me limitaría a llamar a la colección Cars: el plural transmite el hecho de que hay más de uno sin revelar el tipo, lo cual es innecesario.

Answer 9

Poner el tipo de colección en el nombre de la variable es un problema cuando el mantenimiento lo lleva a cambiar el tipo. Usar la pluralización, o algo genérico como 'carColl' es más simple. Explica el punto sin ser algo que un cambio futuro debería afectar.

Answer 10

Prefiere los coches a carArray, pero los coches probablemente tampoco sean lo que quieres. ¿Qué carros?

• allCars
• redCars
• brokenCars
• carsWith3Axels

, salvo en unos pocos casos (siempre hay excepciones esos molestos) los nombres de variables, como los coches no son lo suficientemente descriptivo.

Answer 11

He estado nombrando mis variables cosas que incluyen el tipo de variable, como parte del aprendizaje. Es útil para mí ver carArray en algún lugar del código como un recordatorio de que es la matriz. Pero tu pregunta plantea un punto muy válido en el sentido de que si cambias eso más tarde, entonces debes buscar todas esas referencias y eso puede ser una gran pesadilla. Estoy viendo la sabiduría de nombrar variables de acuerdo con la respuesta de Matthew Vines, "allCars", "brokenCars". Creo que lo haré con más frecuencia a partir de ahora, a medida que mejore mi codificación.

Answer 12

pienso, podría tener sólo llamados los coches de matriz, y no habría hecho ninguna diferencia.

No, no hace una diferencia en el compilador, pero el uso de nombres descriptivos ayuda con la legibilidad, el mantenimiento y la reutilización.

En Visual Studio, puedo encontrar rápidamente el tipo de datos. Por lo tanto, uso nombres descriptivos completos. Los plurales están bien. Si el plural parece incómodo, añado el Listado o lo que sea necesario para indicar que la variable contiene una "colección". Por ejemplo, carArray significa nada para mí. ¿Es car una abreviatura? ¿Qué sucede si cambia la implementación de carArray en un objeto IList o IEnumerable of Car? ¿Eso significa que cambias el nombre de la variable o dejas el nombre como está? Demasiado para pensar. Sin embargo, entendería Cars, CarListing, CarList, CarsByModel, etc.