It’s said there are only 2 hard things in race conditions, computer science: cache invalidation, naming things, and off-by-one errors. While I have yet to encounter NullPointerException in my programming excursions, the latter still confuzzles my 2.0 brain cells every now and then, and I very much hope I never have to deal with the living nightmare of debugging a multithreaded system, above all it’s that one – naming things – that I feel most painfully.
The exact content of the names themselves is a (long) topic for another time. Here I want to talk about casing – that is, how the parts of a name (words, generally) are delimited and capitalised. At its heart, casing provides clarity – both towards the content and intent of the name. When an identifier gets long and consists of more than one word, we need a way to separate them – visually – so that it’s easier to quickly parse what they’re saying. That’s the fundamental goal, remember: clarity.
With that said, different languages and different developers all have different preferences and conventions over how identifiers should be stylised to achieve this. As someone who’s coded in a few languages that all have quite different casing conventions, and has tried to create their own language which inevitably involved considerations related to this, I thought I’d run through the different styles and elucidate my opinions on them.
Y’know what’s even better than kebab-case?
dot.notation. As in,python.s.order. Unfortunately, this isn’t always applicable, and can also quickly get out of hand with too much nesting.