Reminds me of the classic "how to write unmaintainable code": https://cs.fit.edu/~kgallagher/Schtick/How%20To%20Write%20Un...

Especially this bit:

    Bedazzling Names
    Choose variable names with irrelevant emotional connotation. e.g.:

    marypoppins = (superman + starship) / god; 

    This confuses the reader because they have difficulty disassociating the
    emotional connotations of the words from the logic they're trying to think about.

I did this in an infosec class in undergrad 15 years ago, inspired by exactly this essay. The first part of the project was to write a program that password protected a file, and the second part was to try and break each other's programs, with full source code access. I think it helped discourage people from trying to deal with mine as opposed to other people's. (Also, several people correctly guessed that it was mine despite the code being nominally anonymous...)

This thing is gold. But i think that he misunderstood his audience or the audience did not read till this "This essay is a joke! I apologise if anyone took this literally. "

There are a lot of Google and Microsoft programs who implemented his "advice" (i don't use Apple).

Thank you for sharing that link. I had been looking for that document on and off for at least a decade. Great stuff.

> Now, if a name is going to be easily changeable forever, please do make it descriptive. I’d much rather maintain code where the variables look like numCols and numRows than i and j. (Just, for the love of God, if you change the meaning, also change the name). But if a name is going to serve as, in any sense, an identifier, something that will point at a big complicated thing from many places far away, make it an opaque identifier.

The author is very clear about this matter.

> Whimsical project names fall within a well-understood and used convention.

Boy, I wish!

I 100% second TFA when I tell you: There are a lot of really really boring people out there that just don't get it. They think "Product Data Exporter" is the perfect project name.

If you call your data exporter "Asparagus" I will throw a thesaurus at you every day until you come up with a better name for it that has some kind of mnemonic link to what it does. "Data Exporter" is okay, but "Catapult" or "Superhighway" or another whimsical name would be okay too, so long as it loosely matches the problem domain in a memorable way.

“Yeet”

I personally would prefer my exporter to focus on precision, not distance.

So clearly, it wouldn't be "Asparagus", it would be "Beef" (as in Kobe).

I remember how confused I was when I found out a program exists called "FileMaker". Curious how that name was chosen.

Your comment really gave me pause. I've used FileMaker for many years but never gave the name that much thought.

I can't say how the name was chosen. But, I believe I understand the justification for it. It is pretty straightforward once the metaphor is clear. The files it is making are the type of files that go into filing cabinets, not the files on a computer. Early versions of the software had a logo/picture of a building that was a giant filing cabinet and the app logo has usually been a filing folder.

The name makes sense in that isn't about making files on a computer but to help small business convert physical files found in filing cabinets into digital ones in wysiwyg database.

I remember finding "Photoshop" nonsensical at first because I associated a shop with a place to go buy things and it only made sense once I made the association that cars and such are taken to the shop for repairs.

I'm still split on which category Adobe (Macromedia) Dreamweaver falls into.

Better be consistently boring than ever misleading

But as products evolve, their boring names become misleading. At least with non-boring names you can re-define what they represent in your company.

Do products/components really evolve so much that the name frequently become outdated?

Half the article is like, "There was a component called YamlParser, which is now a browser-based stable-diffusion renderer!"

I've worked on tools that were slightly misnamed after 6 months, and completely misnamed after 2 years. At that point they were also usually just nearly useless due to feature bloat and/or lack of scalability, so deprecated or replaced with something better.

They didn't change names, but their successors would get a new one.

Yep, enough that they need a caveat every time someone new is told of the product. It happens, and it's gotten worse due to Agile.

Look at IBM "Watson". It had evolved from an AI jeopardy and Q&A engine into basically whatever salespeople make up.

Isn't it even harder to re-define names in a company? There might be 3 people involved in re-definition, but it affects 15 people.

How are we going to notify those 15? Do we even know who those 15 are? Are we going to create a weekly redefinition newsletter?

I think in most cases new meaning deserves a new name. Everything else is just hacks.

How hard is it to change a name is a actually a really good metric for a company. If a simple rename takes several days, multiple approvals, rounds of QA, and a scheduled release next quarter, then you probably need those hacks.

I think that's very extreme. Products grow at a gradual pace. I don't think there are defining moments when a product no longer supports something, or is no longer used in a way that it was intended to.

I would argue it's easier to maintain peoples understanding of a product since that will also be done gradually. It's not easy to update naming inside of a code base without potentially breaking software significantly or causing unknown bugs elsewhere. I think most software would fail the renaming test. It's also generally not worth the money and time needed to make that change.

Terrific answer!

No idea which way you're arguing though! ;)

Better to be googlable than boring.

I was once tasked with extracting valuable IP from a legacy codebase where the developers had named all types after animals. So there was a SealService, a WalrusFactory, etc. etc. It was horrible and infuriating. They thought they were being cute, instead they just made everyone who ever looked at their code hate them with a passion.

Back in the day,one of my coworkers actually did this once. He built up a giant metaphor for the project in terms of EverQuest.

Even though I played the game I was pretty lost in that codebase. People that didn't play had no idea what anything did.

My 8 year old son names all variables after his friends.

Just in spite of this comment I'm going to name all my futures:

bitch_please

I invite spirited debate on this change request.

Is it an attempt to police the behavior of the async runtime? As a non-mainstream user of a minority language with pluggable runtimes, do I have the right to reappropriate this word?

Perhaps we can develop a language standard for async priority variable prefixes and suffixes. Removing it from the domain of library convention to language feature.

We currently utilize function parameters as the only input to functions, leaving a powerful source of information untapped on the left-hand-side. Will this change speed up development, or more likely, introduce errors? Will advances in language development environments reduce that concern?

How about: bitch_please, bitch_now, bitch_after_next_slice

Note how the meaning of the variable changes with bitch_now? It feels more uncomfortable doesn't it? Less of a joke. Ignoring the runtime's own priorities and values changes this. But why is it less funny? What does that reveal about priorities and still-existing prejudices in LANG? Does that mean that the original use is also less funny in certain contexts, such as public spaces?

Alright, change withdrawn, I was wrong.

* This isn't an original joke, but it is further refined. * I could have been a good academic or scientist.

I think a whimsical type name can have a sort of purpose. Sometimes a name goes from being descriptive to being prescriptive. It feels like a straightjacket, preventing you from adding code that would otherwise naturally fit there. In that case I think a whimsical name can be a good idea. Then later when the dust has settled, when you reach the top of the mountain and get a clear view of things, then you can revisit the name.

I'm not sure I agree with the first one either... I kinda can guess what BigQuery does - probably something with querying a lot of data, so if that's what I need to do, I'm going to check it out, but if not, I'd ignore it. But what does Splunk do? Who knows. Which of the projects with names Beam, Mahout, Samza and Flink I'd need to read about if I need to store and query a lot of data? And after I read about them, would I remember year later which of them does what?

What about a whimsical emoji as a variable name? lol.

I reserve emoji for cases where the language's compiler fails to do type inference and forces me to create a temp variable.

Probably not by itself but it isn't that fundamentally different from some language conventions allowing/preferring glyphs over words for certain meanings eg `string->int` rather than `stringToInt` or whatever.

i was wrong, this doesn't work in perl

It should work in Ruby tho, as everything above ASCII is valid identifier onset.