This is always a problem for me. Say, in a game, there's a class representing an enemy spacecraft named EnemySpacecraft and there's a class representing some collection of those, say all that exist in the game. This class may be implemented as just an encapsulated array of enemy spacecrafts. Giving this class a name like EnemySpacecrafts is way too similar to the singular form. My other ideas are e.g. AllEnemySpacecrafts or EnemySpacecraftCollection, but I don't know how good I would say those are. What is a proper name to give here? Is there a convention I'm unaware of?

  • 4
    It might be helpful to explain why you need a new class for this collection, rather than using a built-in collection type. (Also the platform you're working on.)
    – jscs
    Jul 8, 2017 at 13:25
  • 4
    Adding an 's' to the end of a class name is a perfectly good way to indicate a collection of them. Jul 8, 2017 at 22:01

4 Answers 4


Welcome to the worse part of this job. Naming things.

Here some suggestions

1. Reusability

Let's say you want to reuse the concept of groups for different entities of the game.

You could use a basic name alongside generics

- Raid<>:
  - Raid<EnemySpacecraft>
- Party<>
  - Party<EnemySpacecraft>
- Fleet<>

They also remain loyal to the game's jargon (God, how I miss MMOs).

2. Concreteness

  • EnemySpacecraftRaid
  • EnemySpacecraftParty
  • EnemySpacecraftFleet

One benefit of omitting the suffix Collection is that you don't tie the name solely to the idea of having just a collection. A Raid<?> might involve behaviours and attributes like any other entity in the game, not only .iterator(), .get(int), add(), remove() and so on so forth.

What I like about this approach is it applies the ubiquitous language of the domain (games) to the code.

On the other hand, if you want everything to be subordinated to the technical language, then...

there's a class representing some collection of those, say all that exist in the game.

The ideal name would be EnemySpacecraftRepository. But I get the feeling that this name doesn't meet your expectations. Right?

  • strictly speaking I think the plural would fit the ubiquitous language better
    – Ced
    Jun 27, 2022 at 6:44

I think you need to clearly separate what the list is representing from what a particular instance is being used for. Using Java syntax, a collection of spacecraft could be as simple as

List<Spacecraft> activeEnemies = ...
List<Spacecraft> enemyAttackForce = ...
List<Spacecraft> surrenderedEnemies = ...
List<Spacecraft> destroyedEnemies = ...

If a list of enemy spacecraft has methods that make sense only for enemy craft, then by all means write a class that encapsulates that behaviour. But don't mix the concepts. EnemySpaceCrafts and EnemySpaceCraftCollection are OK names, if a little clumsy (I don't have a better suggestion). AllEnemySpaceCraft is not so good, as it suggests you should not reuse the class when you need another unrelated collection of enemy spacecraft.


Why is it way to similar to the singular form? I much prefer plural and singular forms to differentiate - I guess I have my mind trained to look for the 's', but I'm also a big fan of keeping junk out of names.

I wouldn't want to see 'Collection' post-fixed to a name... That's a big word. skimming through my code and my mind's going to want to think hey that's a big word, we should pay attention to it before I have a chance to think 'oh that's just a plural form represented with 9 more letters than necessary. It's clutter.


One is singular, the other is plural. I don't think it can get much more simple than that!

Keep in mind that code context also helps:

crafts.Each(x => x.Fire());

Adding anything more is just getting in the way. Less is more, as they say.

(disregard the fact that 'spacecraft' is actually a singular and plural word... perhaps a poor example for the topic, but you get the idea)


I love to think of an item as a collection of one. I support this notion by implementing methods that work on collections with supplemental methods to handle scalars; purely for syntactic sugar. The scalar method seldom does little more than to call its counterpart. The method that works on the collection does all the work to harness the power if code re-usability, yesss!

If I implement this.rows([] item) I will more likely also have this.row(int item). I have used this design pattern for almost two decades and no complaints yet. The reason is not brevity, coolness or magic but rather consistency. If you have the discipline to be consistent you cannot go wrong with any reasonable style that you choose.

I find simplicity to be of utmost elegance so i save all my energy for super elaborate documentation :-)

  • Could the downvotes explain themselves? In many cases this is a good idea. Note that it also allows for a collection of zero. Depending on your language, varargs can help with this.
    – user949300
    Jul 8, 2017 at 19:25
  • 2
    Maybe, because the answer doesn't respond the question. What is a proper name to give here? Is there a convention I'm unaware of?
    – Laiv
    Jul 8, 2017 at 21:32
  • I apologize for the lack of clarity, "no there is not". Document and be consistent.
    – chelista
    Jul 8, 2017 at 21:40
  • 1
    That's a better answer :-)
    – Laiv
    Jul 8, 2017 at 23:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.