Separate Your Singular From Your Plurals

This is a real pet peeve of mine, and I know some of you consider what I'm about to rant about to be some form of “best practices” or that “it just makes sense”, but I don't like it and I wish you'd stop.  Here's the issue:  Singular vs. Plural names of objects and variables.  Everyone will probably agree that have a naming convention for your database objects is important.  And most developers agree that having meaningful variable names is important too.  Now, do everyone a favor and stop mixing singulars and plurals together!

For database objects, just decide whether they are going to be singular or plural and stick with it.  It is really annoying to have to remember that the table names are Employer and Customers.  Or was that Employers and Customer?  And Microsoft is guilty of this too!  Have you looked at the Northwind and Pubs databases?  Northwind:  shippers and suppliers but region; Pubs:  authors, discounts, jobs, and publishers, but employee, roysched, and titleauthor.  My position is that not every tablename will make sense as a plural, but everything can make sense as singular, so I only use singular names.

I know some of you will argue that a table is a collection of records and so the table would be properly known as Employees and one record is an Employee, but I just don't buy it.  It's easier to adapt to knowing that everything will be singular.  If you want plurals, then talk about the Employee records that are found in the Employee table.  Or, heck, talk about Employees all you want, but everyone knows that when they have to code, the real object name is Employee.

And programmers are just as bad with their variable names.  It drives me crazy to see something like For Each Employee in Employees... or some such nonsense.  First, it makes it hard to read all the other lines where you have to distinquish between whether the single or plural is being acted upon.  And if you're editing, it's really easy to overlook whether the “s” was there or not or should have been.  Second it makes all communication difficult.  It is too easy to say or type the singular when you meant the plural or vice-versa.  Try using something like EmployeeList for the plural, or ThisEmployee for the singular.  Just don't make them identical except for one letter!

I actually ran into this problem today talking about two different tables in the same database.  They were named almost identically, except to really irritate us, not only was there a mix of singular and plural, but somebody used an abbreviation for one of them.  So, for example, assume that the table names were Letter and Ltrs.  They are related but contain very different information.  Now, imagine having a long-distance phone conversation with someone explaing that they need to make a change to the “letters” table.  Which one am I talking about?  Did I mistakenly add an “s” when I am talking about the Letter table?  Or am I trying to pronounce Ltrs without saying L-T-R-S?

Save yourself the headache and money.  Remember I bill by the hour, and if it takes an extra 10 minutes per day for us to go through the “Do you mean the X or Y table?” or “Oh! I thought you meant X not Y.” then that's nearly an extra hour per week that you are paying me just to clarify our communication because somebody used a bad naming convention.  Over the course of a year-long contract, that's 6 full days' worth of work that you paid for.

posted @ Friday, August 13, 2004 11:03 PM


Comments on this entry:

# re: Separate Your Singular From Your Plurals

Left by Richard Tallent at 8/14/2004 8:37 AM

I use singular names as well. No need to convert "y"'s to "ies", and the major table names match the major classes in my application, making O/R mapping ever so slightly easier.

But if someone wants to get technical about it, singular is the better option anyway. A "table" or "relation" is a singlular thing. A bag does not become "a bags" when you put things in it. You are naming the table, not the tuples.

# re: Separate Your Singular From Your Plurals

Left by Magnus at 8/16/2004 1:58 AM
Agree, good examples. Also singular is better when you define your relations and thus should be used. I like the bag example.

# re: Separate Your Singular From Your Plurals

Left by mk_garg20 at 8/16/2004 4:13 PM
I also agree with you guys.
I will take care next time i am doing something like that.

# re: Separate Your Singular From Your Plurals

Left by Lee Dise at 8/18/2004 12:07 PM
Personally, we think you guys is missing the points. Who care whether a tables are named consistently, so long as the essential messages is getting through about what entity are represented by each tables?

Singular are good, but also is plurals. Consistent inconsistency can keeps a programmers on his toe.

# re: Separate Your Singular From Your Plurals

Left by Tara at 8/19/2004 4:41 PM

Too funny! At first, I thought it was someone replying with bad grammar skills. But then I saw it was you, and I know how well you write, so then I chuckled at it.

# re: Separate Your Singular From Your Plurals

Left by Dean at 6/24/2005 10:22 AM
Thanks for writing your missive. I am creating new data model and tables and was trying to decide if table/field names should be plural, singular, or a both. Your rant makes sense and Singular It Is!

# re: Separate Your Singular From Your Plurals

Left by Marc at 11/8/2005 9:29 AM
Plural and singular names are powerful tools for clear and maintainable code when used correctly. We use plural names for tables and singular names for entities (a.k.a. classes.) We retrieveing an entire rowset, the variable name matches the plural while a row from that rowset uses a singular name. Also, why insult the maintainence coder's intelligence with redundant type names such as list, rowset, record, or table? Just look to the fall of Hungarian notation. It was and still is a waste of typing.

# Naming Conventions

Left by Strate SQL at 5/4/2006 11:35 AM
Recently I read Ajarn's blog on Separate Your Singular From Your Plurals,
where he discusses naming...
Comments have been closed on this topic.