Bad Habits to Kick : Inconsistent naming
See the full index.
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.
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?
The "eye 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?
See the full index.