What this blog need is a bi-quarterly-ish language themed blog post series, said none of our (two) readers ever. So without further ado we proudly present our bi-quarterly-ish language themed blog post series!!!1!!1! In this premier installment we will look at one of the most difficult things a developer has to do (this one is just right up there with solving NP-hard problems). The problem of naming things.

This is quite the formidable topic to cover in just one blog post. Therefore this post will focus on just a small subset that exists in the domain. That small subset is what you should absolutely not do when giving name to new things. A few tips on how to handle if what should not exist, exists will also be given.

If it's of any comfort, after doing extensive research it turns out that not only developers struggle with naming things. People who are paid to name things struggle with this cough Norsk Språkråd cough.

Parents, specially in the United States of America and of European Royal Families, also struggles with this. Because naming things is hard.

And giving good names is even harder.

But it's not this hard.

The no-go-list
A word of caution, this should be used as a rule of thumb. The list of exceptions is of the same length as one for French grammar rules.

• Don't postfix with numbers. Believe in source control!
  
• Don't use too long names (tests are exempted). Long names add memory load on us, humans.
  
• Don't use too short names. Short names makes code more difficult too understand. For loops are exempted and we do love our x', y's and z's.. If you use abbreviations make sure you make a comment about what the full name is.
• Don't be unclear. Do what you say you'll do and not a bunch of other things or something completely different.
  
• Don't be inconsistent. I.E. stick to the same action name through out your code base. (fetch, get, load). If you mess around with prepare, load and get intertwined your code base will be a mess to interpret
  
• Don't prefix everything with the feature name or entity name, also known as "Smurf Naming Convention".
• 
• Don't switch two words around.
• Don't skip proof reading.

Worst of all is the fact that bad naming practices is highly contagious! ☣️ Because what does a developer do when faced with a problem he is not quite sure how to solve? He will look at what others around him have done, and follow their lead, even if it doesn't make any sense.

To quote the character "El Raheem" from the cult-movie “Short Eyes”:

Your presence here effects the mind of my people like a fever.

So this happened at a project I worked on:

Guess what happened a couple of years after the developer that created this mess had left and a new one had arrived (no overlap!)?

This begs the question; “What can you do?”
In my experience there is only one thing that works:

Wow, thats quite medieval, you might say. OK, fair point. In the modern world we do solve our differences a bit, well, different.

Anything is allowed! Social sanctions, public shaming. Just make sure your team understands that language is important.

If no proper purge is executed you risk that what was just an inter-team quirk will quickly expand and other people will suffer because of your poor choices.

Imagine integrating against a 3. party to get a product, your told to check out the their swagger-documentation and this it what you get: What to choose and why?

Developers do (not always) work in isolation. They sometimes work with business people. If you don't have a properly constructed nuke and launch option from outer space this can spread into the real business side of things:

Until the next time I'll leave you with this quotable quote:

Words are all we have, really. We have thoughts but thoughts are fluid. Then we assign a word to a thought and we're stuck with that word for that thought, so be careful with words. I like to think that the same words that hurt can heal. It’s a matter of how you pick them.

― George Carlin