Horrible Naming Conventions

Naming conventions, in general, are a good thing.  If they are simple, quick to learn, and understandable without having to look them up, then they serve a purpose. Usually, this helps new hires become productive more quickly.  Most naming conventions, though, actually increase barriers to productivity.

Data Architects (DAs) and Database Administrators (DBAs) tend to go especially crazy with naming conventions for some reason.  This madness has to stop.  Note: This does not apply to all DBAs.  In particular, the type of DBA known as a Developer-DBA does not usually go this crazy.  It is only the DAs and Administrative-DBAs that take it to extremes.  Also, I have been a DBA and am currently working with DBAs, so I am not blindly accusing anyone of anything. Also, this is a generalization, and as such does not apply to everyone.  I am sure there are numerous DBAs out there with relatively sane naming conventions, and I applaud them.

For example, on a previous project I worked on, I needed a table to store binary attachments that were uploaded by the user.  One of the fields I needed held the number of bytes.  This is the field name I get: R_ATTACH_FILE_CONTENT_SIZE_QTY.  What the heck is this?  Let's deconstruct it step-by-step. 

The table name was R_ATTACH_FILE, so I already knew that it was an attached file (assuming I could figure out what R_ was), so why repeat all of that at the beginning of the field name?  The response I get many times, and I am sure you have heard it too, is "I want to be able to tell by looking at the column name what table it belongs to."  The main reason why this argument is invalid is you never reference a column without the table name.  The table name might be implied, as in the SQL statement SELECT R_ATTACH_FILE_CONTENT_SIZE_QTY FROM R_ATTACH_FILE, but it is still there.  What DAs and DBAs do not seem to understand is that when developers reference this field, it is often in the form R_ATTACH_FILE.R_ATTACH_FILE_CONTENT_SIZE_QTY.  Now doesn't that sound stupid?  I think we can all agree that it makes much more sense to say R_ATTACH_FILE.CONTENT_SIZE.

And at the end, there is an indicator to tell you what the field is for.  In this case, QTY is short for quantity, which represents "a measure of a strictly numeric quality of an item."  Duh.  It looks suspiciously like MetaData to me.  SQL Server has almost unlimited support for MetaData through extended properties.  Don't force me to deal with extra complexity because you do not want to setup a proper MetaData repository.  It might seem like an extra 18 characters (4 for the _QTY and 14 for the repeated table name) hinders productivity that much, but consider that it is applied to every field in every table.  For any decent-sized application, the effects are amazing.

The first example was not too bad since you could still figure out what the field did after stripping away the useless characters.  How about these examples of worse field names:

• ISR_REQ_DET_DESC_TXT
• REQUEST_DA_REQ_IND

Call to Action!

In SQL Server Yukon, the CLR will be bundled with the database server for the first time ever.  NOW IS THE TIME TO CHANGE THINGS!  A great first start is the .NET Framework Naming Guidelines.  Try your utmost!  Your organization will thank you for it in the end.