The worst database column name ever

If you are a professional programmer, you probably know the quote by Phil Karlton:

There are only two hard things in Computer Science: cache invalidation and naming things.

The importance of good variable names and class names in programming is well understood; since programming is only 20% writing code and 80% reading code, any variable name should be explaining and concise. Name it what it is.

There are plenty of examples of bad names, which are short and meaningless or long and overly complicated. A widespread bad habit in naming is using the abbreviation of the name that you really want to give something; while writing them you feel it’s obvious what the name means, but it reads horrible and you’re just being lazy. (I mainly see that from JavaScript devs these days… is it because they use lightweight text editors and have to type the full variable name all the time, while the backend guys type three letters and IntelliJ just puts the full name there?)

My horror was a huge legacy project where every database table had a four letter name, which was an acronym of the specialist term in German — so there where dozents of entities like FJLB and FJLT that you would have to understand and remember. The project was already running for 20 years and had 200 people on it. Just for fun, try to imagine how many man months were completely wasted just for people learning these names (and introducing bugs that could have been avoided)!

But when I talk about the single worst name for a database column (or property of an entity, same), it is not that exotic. I would bet everyone of you has already worked on a project where this name was used — and probably not only once, but many times.

It’s the name “type”.

Why is it so bad? Let me give you a little example:

You are working on a book store software, and the ‘book’ entity has the properties title, authors, publisher, year, isbn-number and so on. Now your colleague walks in and says: “We have to distinguish between two types of books from now on: e-books and paperbacks. So let’s add a property ‘type’”!

See where I’m going? Not yet? Here is an other one:

You are working on a book store software, and the ‘book’ entity has the properties title, authors, publisher, year, isbn-number and so on. Now your colleague walks in and says: “We have to distinguish between two types of books from now on: books for adults and books for children. So let’s add a property ‘type’”!

Got it?

The reason why ‘type’ appears in a whole lot of code bases is a common way of thinking: There is our current approach of modeling an entity, and then an additional requirement forces us to distinguish between two types of that entity.

The problem is: ‘Type’ is absolutely meaningless. Only in the context in adding one new dimension to the dimensions that the entity already has, it appears to be different ‘types’.

Take the example above: What is the type of a book, is it e-book/paperback or adult/children? Imagine the two stories being one, you have two colleagues and each of them asks you to add a dimension to books and call it ‘type’ — who is right?

Neither. If the e-book colleague comes first and you name his property ‘type’, what do you call the second one? Maybe ‘audience’? Great! And if the other one comes first, what do you call the e-book/paperback property? Edition? Or can you come up with a better name?

When you are tempted to call something ‘type’, keep in mind that this is your laziness speaking! Asking someone who knows the domain, but not your model, what ‘type’ a certain book is of: He would not know what you are taliking about, right?

So if you are in that situation, do yourself and everybody else a favor: Pretend the name ‘type’ is already taken (and all it’s synonyms like ‘category’ or ‘class’).

Name it what it is!