Naming convention for collection of objects

[agarwal.harsh2]

Hello
Not to sound nit-picky, but our team is debating on the right naming
convention for classes that have an aggregated collection (list, set,
map, array etc).

For example, take class Car. Now we need a class that is a collection
of cars.

Two schools of thoughts are:
1. Name the class CarCollection.
Pros. Very clear - it's a collection of cars.
Cons. Does Collection indicate that it will have an aggregated
"Collection" object (Java collection as compared to a Java Map)
2. Name the class Cars (notice the plural)
Pros. No confusion as to whether there is a Collection inside it,
or a Map.
Cons. Difficult to read maybe - Car and Cars look similar.

Any opinions?

 

[Daniel Pitts]

Hello
Not to sound nit-picky, but our team is debating on the right naming
convention for classes that have an aggregated collection (list, set,
map, array etc).

For example, take class Car. Now we need a class that is a collection
of cars.

Two schools of thoughts are:
1. Name the class CarCollection.
Pros. Very clear - it's a collection of cars.
Cons. Does Collection indicate that it will have an aggregated
"Collection" object (Java collection as compared to a Java Map)
2. Name the class Cars (notice the plural)
Pros. No confusion as to whether there is a Collection inside it,
or a Map.
Cons. Difficult to read maybe - Car and Cars look similar.

Any opinions?

My opinion:
Don't name it based on "what it has in it", but what it does:

"ParkingLot" has an aggregate of Car objects. It may be implemented
under the hood as having a Map<SpaceNumber, Car>, or as a Set<Car>, or
even as an Car[]. Maybe it even has a Set<ParkingSpace> where
ParkingSpace may contains a Car...

The point is, the "has-a" relationship is often an implementation detail
that needn't be exposed even through naming conventions.

 

[Arne Vajhøj]

Not to sound nit-picky, but our team is debating on the right naming
convention for classes that have an aggregated collection (list, set,
map, array etc).

For example, take class Car. Now we need a class that is a collection
of cars.

Two schools of thoughts are:
1. Name the class CarCollection.
Pros. Very clear - it's a collection of cars.
Cons. Does Collection indicate that it will have an aggregated
"Collection" object (Java collection as compared to a Java Map)
2. Name the class Cars (notice the plural)
Pros. No confusion as to whether there is a Collection inside it,
or a Map.
Cons. Difficult to read maybe - Car and Cars look similar.

Any opinions?

Not #1. People can read the type separately from the name.

So #2 but preferable with variant that adds more difference
between the two. Car and CustomerCars/CarInventory/whatever.

Note that it is often a bad idea to have a class that only
acts as a holder of a collection, because it really adds
little value.

Arne

 

[Mark Space]

Not #1. People can read the type separately from the name.

So #2 but preferable with variant that adds more difference
between the two. Car and CustomerCars/CarInventory/whatever.

Note that it is often a bad idea to have a class that only
acts as a holder of a collection, because it really adds
little value.

I like #1 better, just because "Cars" is much to similar to "Car".
However I agree that variables should not include their type in their
name. I think Hungarian notation has fallen completely out of favor now
with most folks.

So it might be better to find a more descriptive name. "Inventory",
"CarGroup", "ApplicationContext" (horrible but been done),
"SessonContext" (almost as bad), etc. "Collection" can be used in the
general sense of the English language, but it's also too close to the
Java class type.

 

[Arne Vajhøj]

However I agree that variables should not include their type in their
name. I think Hungarian notation has fallen completely out of favor now
with most folks.

Not with Windows C++ developers !

Arne

 

[Mark Space]

Not with Windows C++ developers !

Arne

Are you serious? Are they still doing that as a "best practice"? Or just
the folks who read Petzold and don't know any better....

 

[Arne Vajhøj]

Are you serious? Are they still doing that as a "best practice"? Or just
the folks who read Petzold and don't know any better....

I would say that it is best practice !

There are really no such thing as a best coding convention.

The far most important rule in coding convention is consistency.

All the MS API's use it.

MS made the choice many years ago.

Arne