The (Variable) Naming Is the Hardest Part – InApps 2022

When I got started coding, I knew it wouldn’t be a cakewalk. Programming any computer language, ever, requires learning syntax, data and control patterns — not to mention the (oft-unmentioned) necessity of rearranging your brain to think like a programmer. Some item on that heaping combo plate is inevitably going to present a challenge. But if we just keep working, all of the necessary skills and knowledge eventually coalesce: time plus practice equals ability.

There is one other hard truth about computer programming, however, that doesn’t ever go away. Nor does it get easier the more you do it — in fact, the more you experienced you get, the more often you likely find you actually have to do this particular weirdly difficult thing. And, no, I don’t mean talking to the marketing team.

I’m talking about naming variables. Classes, IDs, objects, functions, methods, props, whatever you got — nothing can KO that nice steady stream of code flowing from your fingers like a create-react-app Mozart faster than the need to actually Name All the Things. I know I’m not the only one who experiences this. Mention coming up with variable names at any kind of programming meetup and the collective groan will tell: We all hate it.

Or, as Phil Karlton — one of the architects of the original Netcsape Navigator browser  — said in 1996: “There are only two hard things in computer programming: cache invalidation and naming things.”

But why? Why is it so hard to name variables? Or, more to the point, why is it such a struggle to come up with good names?

Name your variables as if the person who will next read your code is a chainsaw-owning psychopath who knows where you live.

The very first number one reason might be because there is no collectively held best practice, no established “right way” that guides coders in coming up with the perfect conceptually brief, clear, and appropriate yourVarNameHere. Don’t get me wrong — there are tons of resources that explain the rules and syntax for creating variable names. But properly constructing a syntactically correct, case-sensitive sequence of Unicode letters and digits (plus maybe a few symbols) is not what I’m talking about, and you know it. I’m talking about coming up with the damn thing in the first place.

I mean, we all know that having clear, descriptive and concise variable references makes our working lives so, so, so much nicer. Not to mention the lives of anyone who has to come in and read our code later. And the best way to do that is simply to construct a name indicating what this particular block of code intends to do, and why, while distinguishing it from similar or related blocks. No problemo, right?

If only. Again: weirdly difficult to actually do. Why?

I’ve been musing on this for awhile, and have a few ideas. I believe that, though we all know coming up with logical and memorable variable names is important, it also doesn’t feel like part of ‘actual’ work. I mean, if our job is to solve problem X by writing or using or fixing code, we should be coding, not pausing to peruse thesaurus.com for synonyms for “$data.”

When I catch myself grumbling under my breath at the screen because my workflow has just screeched to a halt like the Roadrunner coming to a cartoon cliff edge, because it’s time to come up with yet another name for something — it feels bad. It’s frustrating; an interruption that throws off your coding mojo, which then wastes time picking up the thread again. For me, it feels like literal gears are grinding in my brain. Yet I don’t want it to be my poorly-named classes metastasizing all over a piece of object-oriented software’s class hierarchy that some poor maintainer is going to hate me for later. And that person could be future me, so best to do it right from the get-go.

So, yeah, there’s no easy way out. Name your variables as if the person who will next read your code is a chainsaw-owning psychopath who knows where you live. And this means taking the time to suffer through really thinking about what you’re doing in that particular situation in order to invent a good, meaningful name that is going to make sense to future you.

True story: I get bored at work, and sometimes entertain myself by getting creative with variable names. Last week, after the McDonald’s Rick and Morty Szechuan sauce fiasco, I caught myself naming an object constructor function something truly retarded along the lines of SzechuanFail. It had literally zero relationship to the code context, I was just trying to be funny. Fortunately, I caught myself in time and renamed it to some boring but appropriate thing that will make future me not want to punch current me in the face (which actually, come to think, would be a most Rick-and-Morty scenario).

But I digress. The original question before the panel was, why is naming variables such a weirdly painful task? I do think it comes down to the gears grinding thing — that writing code uses the linear, logical programming part of our brain. While inventing appropriately descriptive variable names means stepping over into a totally different, language-oriented region of the brain. Doing this is inevitably disruptive, likely unpleasant, maybe even a little painful. But it’s also necessary.

We can do it! Developers are comfortably creative when it comes to writing code. Inventing equally righteous var names is just creativity wearing a different shirt. In the end, we are writing our code as much for other human beings — to communicate how we were attempting to solve the problem at hand — as for the compiler. So name it like you mean it. And leave the Rick and Morty jokes to the experts.

Base for feature image: Gears, by flickr user Joe deSousa, licensed by Creative Commons. Wrench, sparks, text by Michelle Gienow.