[1] There are only two hard things in computer science: Cache Invalidation and Naming things.

Phil Karlton

Of course, naming things is difficult because cache invalidation is difficult... to change a name you must invalidate everywhere that the name is used (pronounced: cached), and invalidating cached values is difficult (see [1])

I name a lot of things, for posterity and reference I offer my naming conventions below.

The curious case of snake kebabs

The most readable label format is:

I call it 'prose case' or 'label case' ... well it's not really a case per se. Anyway all lesser formats must be chosen because of local restrictions, like not containing spaces.

The most readable identifier format is lower kebab case:

I thank CSS for making use of this, but then it started putting underscores in the operators. WTF bros?

The next most readable identifier format is lower snake case:

But I reserve a special place in hell for whoever thought it was a good idea to standardize putting two underscores next to each other in any context. That is unacceptable.

An acceptable identifier format implying some semantic differentiation from the previous options is upper camel case:

A hideous identifier format made common for reasons I'll never understand is lower camel case:

Of course in any codebase convention beats taste, so when you're writing javascript and its ilk just do it and stop complaining.

An acceptable identifier format implying some exceptional semantic difference is upper snake case:

Avoid other identifier formats

Yes. I'm looking at you powershell.

But what about paths?

well usually a path is a sequence of identifiers separated by something, and by convention there are only really two separators you should consider:

Bizarrely the most common resource location standard in the world mixes them both... at least they are usually mixed in a 'distinct' way

because any other kind of mixing would be a travesty

well now that I look at it... at least it's not as bad as putting spaces in there. Yes, sometimes spaces are allowed in paths, but really you should avoid this in almost every situation.

and I guess an honorable mention...

Naming Things (reprise)

Ok, we haven't named anything yet though, so let's get into it

Naming things in the cloud

you will always need to refer to your cloud things from outside the cloud, so the first part of your cloud thing name should be which cloud provider

• az for Azure
• aws for Amazon
• gcs for Google
• and so on...

Geography matters unfortunately, except when it doesn't... if your thing is tied to a specific geography put that in the name: az-we aws-useast and so on

From here on you'll want to have a think:

• Why does it exist? app-name service-name etc.
• What kind of thing is it? rsg vm db etc.
• What it does? srv app cache store etc.
• Who is it for? dev test qa prod if you know of any others tell me 🤗

In general I will chose two to three of these. Context driven. So here's what it looks like:

But why are there numbers on the end? because...

The most important thing is to put a number on it

Yes. Always put a number on it. Every time. Always. Never don't do it.

The only time I have not regretted putting a number on a thing I named was my children, and even then I sometimes refer to them as first and second.

You will almost invariably rebuild the thing at some point, and you will want the old one next to the new one, and the only way this happens painlessly and without bizarre thoughts is if there are numbers in there.

I set myself a minimum of two digits. My instinct tells me that if I started automating IaaS deployments I would put three, but I've never done that so I don't know.