Will bad things happen to me if I name my arrays, collections, lists, enumerables, etc. just the plural of what they contain?

Question

I have always thought it was "best practice" to be explicit in naming my collection variables. So, if I had a collection of Car objects, I would typically name a Car[] carArray and a List<Car> carList.

And then 99% of the time, I end up just doing something like...

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

...and I'm thinking, I could have just called the array cars, and it wouldn't have made any difference.

And now that we have IEnumberable<T>, I'm actually faced with the question of whether I might considering writing something like carIEnumerable? or carEnumerable. So far, the answer has been "no".

My thinking here is that the type of collection often doesn't matter, and when it does, is still doesn't matter if the collection type is written into the variable name. I just had a case where I had to switch from an IEnumerable<Car> to a List<Car> because I needed "bracket access" to the items (e.g., carList[3]). In that case, the two collection types do not behave the same, but would naming the variable cars have been a problem here?

Not to add another layer of complexity to this question, what happens if I use var? E.g.,

var cars = GetCars();

I can certainly tell cars is some kind of collection. I can iterate it. If I'm using LINQ, I can use extension methods. More importantly, if I later change up the type of collection, there would be much less code to mess with. var would still be var and cars would still be cars. That seems very appealing to me, and I having trouble seeing much disadvantage.

So, just to make sure my question is clear: How do you name your collection variables and why? Is there a serious readability or clarity cost to just "pluralizing" the name of the item?

Thanks.

Answer 1

I never liked the "put the type of the variable in its name" approach - I really think it interferes with the smooth reading of the source. I believe code should be read like a story, and so it makes perfect sense to me that a group of cars (and I don't care if its implemented as an array, a linked list, a heap, set or whatever) is named "Cars":

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

fencer.cars = stolenCars;

Works for me.

Answer 2

Personally I avoid using the type of the collection in the variable name whenever possible. It may look nice but it's an un-enforcable constraint that other developers will mess up over time. If the type of the variable is really important for a particular operation I would instead consider rewriting the code to be ...

1. Less concerned about the specific collection implementation
2. Make the code shorter / more concise to the point the type of the variable is unambiguous

Or in other words, I don't like Hungarian notation.

Answer 3

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

Readability wins.

Hence I go with pluralizing.

Kindness,

Dan

Answer 4

The difference between "cars" and "carArray" is the self documenting nature of the code. No need to figure out what type of collection you are using if it's built into the name. In a trivial program, it doesn't really matter, but in something more significant the time savings are important.

Answer 5

I think using the plural makes perfect sense, and that's the method I generally use in my code. I've never found that having the data type as part of the variable name is all that helpful.

Answer 6

I generally start by pluralizing (e.g. cars). Often you will also have a local variable in the singular form (e.g. car), sometimes it can be awkward to read the code with two very similar variable names in which case I will find a new name for one of the variables.

I almost never would use carArray, more likely allCars, or selectedCars or something appropriate.

Answer 7

You certainly shouldn't add the type name as part of the variable name - pretty much for the reason you mentioned. Personally, if I had a collection of Car objects I'd just call the collection Cars - the plural conveys the fact there are more than one without revealing the type, which is unnecessary.

Answer 8

Putting the collection type in the variable name is a problem when maintenance leads you to change the type. Using pluralization, or something generic like 'carColl' is simpler. It gets the point across without being something that a future change would need to affect.

Answer 9

Prefer cars to carArray, but cars probably isn't what you want either. Which cars?

• allCars
• redCars
• brokenCars
• carsWith3Axels

In all but a few cases (there are always those pesky exceptions) variable names like cars are not descriptive enough.

Answer 10

The problem with this kind of naming is that it concentrates too much on the actual implementation rather than the purpose of the property. Instead of CarArray, you could use OwnedCars, or whatever tells the user why that enumeration is there.

I think naming a variable "car" if you are in a foreach-loop is just fine.

If you write var cars = GetCars(), the compiler looks at the type on the right side of the assignment, in this case possibly IEnumerable<Car>, and gives cars that type. You can even see it in subsequent uses of the variable if you hover over it with your mouse.

If you change the type of a collection and don't have to change your code because you are using var, think about the fact that those different types of collections probably have something in common that enables you to perform the same operations on them. Probably it's IEnumerable if you use them in foreach loops.

So you could just as well expose those collections as IEnumerable, so users of your class don't depend too much on a certain implementation.

Answer 11

I've been naming my variables things that include the variable type, as part of learning. It's helpful for me to see carArray somewhere in the code as a reminder that it's the array. But your question brings up a very valid point in that if you change that later, you then have to chase down all those references and that can be a big nightmare. I am seeing the wisdom of naming variables according to Matthew Vines' answer, "allCars," "brokenCars." I think I will do that more often from here on out, as my coding improves.

Answer 12

I'm thinking, I could have just called the array cars, and it wouldn't have made any difference.

Nope, doesn't make a difference to the compiler, but using descriptive names helps with readability, maintainability, and reuse.

In Visual Studio, I can quickly find the data type. Therefore, I use complete descriptive names. Plurals are fine. If the plural seems awkward then I append Listing or whatever is needed to indicate the variable contains a "collection".

For example, carArray means nothing to me. Is car an abbreviation? What if you change the implementation of carArray into a IList or IEnumerable of Car objects? Does that mean you change the name of the variable, or leave the name as it is? Too much to think about. Yet, I would understand Cars, CarListing, CarList, CarsByModel, and so on.