1

I have an object:

const riders = {
    Dave: {
        gender: 'male',
        age: 13,
    },
    Nina: {
        gender: 'female',
        age: 16,
    },
    Mike: {
        gender: 'male',
        age: 12,
    }
};

Should I make the object name rider(s) plural or singular? I'm asking this, because I know arrays are always to be plural, but this is an object. I don't want anyone to assume it is an array simply because its name is plural. What're the best practices in this regard? I want it to be readable and understandable, in the best way possible. At the very least, it should be consistent.

I read that collections are to always be plural, but, according to this answer and the sources it provides, objects are not considered collections. Would the method in which I employ it in define it as a collection?

  • 1
    Your "object" is a collection of riders - it doesn't have any other functionnality. – Mat Jan 16 at 6:45
0

Avoid any use of plurals they are confusing.

Consider:

  • sheep - sheep
  • library - libraries
  • person - people
  • datum - data

I some cases, eg SQL tables using the singular is common, in your case of rider its hard to say as we can't see the context. Consider adding a word PassengerList vs Passengers etc

| improve this answer | |
  • This answer helped me the most, as it put into thought that a collection can have its own distinctive name. For example, I could've named it mapRiders. Adding a name helps, but also there is the option to give the object a more distinctive name as you've said, which was list. I'd imagine a group of fish could be named fishSchool, and sheep as sheepHerd. Adding a prefix or affix might help determine whether it is an array or an object. – yaharga Jan 16 at 15:43
  • I use datum / data all the time. And person is arguably a bad term anyway, something more specific like "user" or "employee" would be preferred. Can't say I've ever worked on herding software, but "flock" is an obvious plural of sheep. – user949300 Jan 16 at 15:56
  • the problem with employee, flock etc is that they have implications more than being a collection of that type. Company.Employees may include people no longer employed by the company. Farm.Flock is more than just a list of sheep. – Ewan Jan 16 at 16:01
4

At risk of being overly general....

Not all objects are collections, but all collections are objects.

  • Ok, someone will mention a language where the words are defined differently.

But we're talking about names that make sense to people. So, um, hell yeah, if people will see it as a collection of like things, give it a plural name. Or give it a descriptive collection name like KeySet or BookList.

The convention of naming collections with a singular name is idiomatic and popular for people who design SQL Schemas. In that environment code does not so often have to make the distinction between the set (collection) and the individual member item. You strive to always do set operations when possible.

If your language/community has a tradition that the cool kids use singular for sets, as SQL does, then that's a nice choice.

In an OO language you often have to make the distinction between Cars and Car for example. So it's far more common to see collections named as plural.

But the overriding answer for this is, hey, it's really a matter of taste. The biggest error is worrying too much about what we all think about your names. Make the call, live with it a while, see if you want to do it the same way next time.

Most experienced developers will ignore your specific taste most of the time and care more about whether your style is reasonably consistent so that a reader can learn your code without constantly wondering whether you mean the same thing each time.

You are overthinking this. Decide and move on.

| improve this answer | |
3

There are arguments for and agains both types of naming:

  • You could defend riders because there are several of them and for rider in riders is extremely expressive and accurate.
  • But for arrays and maps, i.e. indexable collections, riders[1] , riders[2] gives a false sense of plurals for individual elements.
  • using different conventions for different kind of collections, or not using them consistently seems extremely confusing.

Ultimately, and in absence of decisive advantage of any of the two scheme, the most important is to avoid confusions : stick to the usages of your language community or decide once for all in your team.


Edit: Common usages - some use singular, some plural:

  • In RDBMS context, singular table names are very popular (see for example this post). But plural gains traction.
  • In MongoDB, the common usage is plural for collections (see for example this post). The same for JSON according to Google's style guide.
  • In UML modeling, the singular is popular. Probably because at modelling stage, multiplicities are subject to rapid evolution (see also this post).
  • For OOP languages you definitively find advocates for both approaches (see the big number of votes for the two main responses in this question in which plural and singular differ only by 7% of the voters)
| improve this answer | |
  • 2
    Anybody who gets confused by riders[2] needs to be placed into remedial pair programming. :-) – user949300 Jan 16 at 17:08
  • @user949300 riders[2] could be an individual rider. But if riders was an array of collections, riders[2] could also be a collection. What I try to say is that you cannot infer from the plural if you’re dealing or not with a collection. The superiority of this notation is not demonstrated. In addition plurals for collection could be seen as a light variant of the hungarian naming convention with all the pros and cons. – Christophe Jan 16 at 17:38
  • 1
    if riders is an array of collections, it is misnamed. That would be ridersGroups or similar... – user949300 Jan 16 at 18:03
  • 1
    @user949300 that's a fair point ;-) – Christophe Jan 16 at 18:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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