My take on identifier semantics (Id vs No vs Code vs Key)

When I design my own software, I have a naming convention that I use. It’s not rocket science, but it’s allowed me to know exactly what something is as soon as I see the name.

Unfortunately, while other developers use the same names, they often use them in ways you don’t expect. I kind of wish everybody would use this simple convention.

So here it is:

Id – In my little world, any variable or database column including the term ‘Id’ is an integer identifier for something. Usually non-negative and non-zero. I suppose it could be negative, although I would never do it, but it should never be zero since in many languages uninitialized variables default to 0. As is conventional, this is always my primary or foreign key.

No or Number – I use the term ‘No’ or ‘Number’ for alphanumeric identifiers usually. Why am I calling a string ‘Number’? Because that’s how we communicate; Customer Number, Item Number, Vendor Number, etc… Identifiers with the word ‘Number’ in them are almost always strings, even our phone number or Social Security Number, which are made up of only digits, are usually stored as character strings by experienced developers.

Cd or Code – I use this for specific length identifiers which don’t change often. For example: State Codes (‘NY’, ‘WA’), order types, credit card types, etc…. I create enums for these values and evaluate them in the display instead of the database; I’ve just found that infrequent code changes make fewer joins on every query seem like a good trade off. Codes are also almost always displayed as drop down lists on the screen and their abbreviation makes direct database easier as well (as opposed to having a provinces table, and a province id of 3).

Key –I don’t use this term very much, but I would use it for something like an application key rather than an identifier and it would be an alpha-numeric string.

This is pretty basic, but consistency counts. Running into variables named UserId instead of UserName, and then XxxUserId for the user id adds nothing but confusion. Even after seeing it for months, it will still throw you off, and when you create a new method requiring a user id as a parameter, do you call it userId? Or xxxUserId? And when it’s named with a prefix like this, it’s not even like it comes up in autosuggest to constantly remind you of the difference. Yes, you *could* rename the variables all throughout your code, but then you’ve still got it in the database which has a lot more dependencies, many of which are undocumented. … but I digress …

I should also point out, there are times when I don’t follow these conventions, for example, I don’t call user names ‘User Number’, nor do I call ‘UPC’ (Universal Product Code) a ‘Universal Product Number’ as my definitions might suggest. But for the most part, every app I’ve designed in the past 10 years has this convention.

One more thing, if I’m generating these strings, I never use vowels, since it’s only a matter of time before something offensive is generated. You can check for the obvious swear words, but you won’t catch them all … but without vowels, nothing will get through, ever. Even something which appears as though it might be offensive, without vowels, it will be chalked up as an overly active imagination.