The author seems to be talking about names for two totally different things, lumping them under the term "component."
Whimsical project name? No problem.
Whimsical type name within a project? Really bad idea.
Whimsical variable name? Don't even think about it.
The concept the author is missing is "convention." Whimsical project names fall within a well-understood and used convention. The convention for type and variable names, however, is set by the standard library and these are almost always descriptive. Their purpose is, in the best case, to reinforce a ubiquitous language drawn from the domain.
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).
> 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.
> 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.
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'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.
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.
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.
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?
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.
Whimsical project name? No problem.
Whimsical type name within a project? Really bad idea.
Whimsical variable name? Don't even think about it.
The concept the author is missing is "convention." Whimsical project names fall within a well-understood and used convention. The convention for type and variable names, however, is set by the standard library and these are almost always descriptive. Their purpose is, in the best case, to reinforce a ubiquitous language drawn from the domain.