What's in a name?

AaronBertrand — Sun, 22 Aug 2010 19:12:00 GMT

In a lot of my projects, the issue of naming/coding conventions comes up. I am a big fan of PascalCase/plural for tables and views (e.g. dbo.CustomerAddresses, dbo.OrderDetails), PascalCase for column names (e.g. FirstName, HomePhone); and for stored procedures, I am partial to the Entity_Action naming convention (e.g. dbo.Customer_Create, dbo.Customer_Update). I know some like to separate out their words with underscores, but with the exception of stored procedures, I find this tedious.

One of the stickier points in several cases has been how to case short suffixes, such as the ID in CustomerID. Let's go back to what the ID is; an identifier. I often liken it to an identification card, which usually contains either a visible or a bar-coded identifier of some sort (SSN, driver's license #, etc). While sometimes this card is called an I.D. and sometimes an ID, I have yet to see it called an Id or an id.

For short suffixes that are actually acronyms, I prefer all upper-case. Most developers I've come across seem to like to lower-case the remainder of the acronym. And in some cases they have to; e.g. in JavaScript you refer to element.innerHtml; if you try element.innerHTML you get an error message. I can still tell what Html and Xml are when they aren't in upper-case, but it can be cumbersome to read that way, particularly with the Id / ID suffix. Because often "CustomerId" can look like "Customerld" - the difference is only slightly more clear in a fixed width, code-ish font:

CustomerId vs. Customerld

Among other things, using an upper-case ID ensures that everyone knows we aren't talking about the customer's "pleasure principle" (according to Freud). And isn't this easier to read?

CustomerID

The "I dee" part rings out much better for me when the acronym is upper case. And when I find queries written by others where they have used their convention, I always re-write to conform to my convention. And while it is as weak an argument as writing standards-compliant code for fear that you will ever port to a different RDBMS, I find it hard to justify leaving code as is when it will fail if we ever have to use a case sensitive collation.

Even when I will always name the database entities in this way, if you want to call it CustomerId in the application code, feel free. Just be consistent. And don't expect me to leave it that way if you hand control of the code over to me.

What are your thoughts? Are you a proponent of CustomerId? In the application code only, or in both the app and the database? If so, why?

Search results matching tags 'Database Design' and 'code'

What's in a name?