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.
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.There are a lot of Google and Microsoft programs who implemented his "advice" (i don't use Apple).
The author is very clear about this matter.
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.
Even though I played the game I was pretty lost in that codebase. People that didn't play had no idea what anything did.
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.
There's your problem. Create libraries that aim to do one thing and do it well. Once you release your project and have users that depend on your code, you owe it to them to maintain it in the original scope. If you have an urge to change your project's scope so much that the name should change, create a new library with a better name instead.
p.s. Obviously does not apply to brand names, which need to be distinctive.
p.p.s. Rich Hickey talks about this here: https://www.youtube.com/watch?v=oyLBGkS5ICk
That's nice and all, but once you combine that with giving them descriptive names, you're going to have a list of hard-to-distinguish projects like:
- css-min
- css-polyfill
- css-inline-min
- css-inline-polyfill
- css-script-min
- css-script-polyfill
- etc.
Good luck clarifying what you're talking about. And of course, people will start using acronyms for all of them, and now you're back at cryptical names, with the added benefit of all the names sounding and looking similar. Or, of course, have inaccurate or inconsistent names.
And then I didn't even get to the part where your categorisation turns out to not match the eventual scope, and they'll need to be split into css-server-min, css-client-min, etc.
https://qz.com/646467/how-one-programmer-broke-the-internet-...
What's hard to distinguish? These are projects that do something with CSS. If you don't need css, you skip them. If you need a polyfill, you only look at polyfill ones to see what you need.
Now, let's imagine your list is "creatively" named like
- shelob
- arcana
- custard
- escalope
- virtuocsso
- jester-css
- etc.
Ah yes, this is so much easier to distinguish, isn't it?
If it's painless to create new internal products within your company & there is operational support for it, you're more likely to spin up a sister "EmailNotificationService" alongside "SmsNotificationService".
If you have to jump through hoops to get sign-off and business cases etc and eitherways it's the same team responsible for both, people are more likely to say "let's just put the functionality in here"
This is a thing people like to repeat over and over again, but just really isn't actionable. The world is very high dimensional, it's always a judgement call what to cluster together and call "one thing". Especially in software where everything is made up and is constantly changing.
People often like to refer to things like unix tools etc as doing one thing and doing it well, but all those tools have grown a ton of command line args, and have backwards compatibility issues that prevent them from doing their job "well" in the modern era. So people write new tools or just hardcodes a ton of command line flags into aliases by default. Many default settings on unix tools are awful. Why does grep not use regex by default? Why doesn't echo support newline escapes by default? Which tools use color by default?
Reality is a mess, and it's an illusion that you can do "one thing"
It may well fit that use case to add one extra feature to the library rather than creating a new library.
I suspect that many of the examples provided (such as the Django project) evolved over time. It can also often be the case that once an implementation is done it becomes obvious that it actually does something very different to what you originally set out to do.
If you want to make new and different things, just do that.
If it's called Vue, I'm going to think it's big enough that someone thought it was worth it to spend an hour thinking of names. It was intended to get big. This isn't some minimal internal thing for one specific use case that probably isn't mine. I'll be more likely to check it out.
They also limit the scope of a project. If you have a "datasender" people will say "This shouldn't preprocess data! This shouldn't compress! This shouldn't intelligently decide when to drop frames! It should just send!"
Now you gotta have a separate frame droppy preprocess thing, and the part that does communication has to tell it what kind of loss you have, but even that is not just sending data, so more likely you won't get that feature at all, or you'll have to go beyond the name.
If you hate features I guess it's a good way to make them hard to implement.
Short names, like "Gru" were reserved for the most powerful trolls because there were only so many combinations of three letters. Long names on the other hand were a sign of weakness and cowardice - bringing ridicule to those who introduced themselves like that.
I'm assuming this is a tool for quickly laying out and publishing books. Or perhaps a tool for quickly searching for and downloading books to my iPad or ebook reader.
I think part of this is that in software ecosystems that have been around a long time, the most obvious descriptive name for a package tends to have been chosen by the package that got there first but is now has an API riddled with outdated anti-patterns and whose code hasn't been touched in a decade because eventually everything becomes a breaking change.
The newer package has to pick a weird-but-available name, but has the luxury of rebooting with a cleaner, simpler API and an implementation free of "bugs" that must be kept around in the name of backwards compatibility.
Once you experience enough of those, you subconsciously develop an association that "boring obvious name" equals "crappy API and weird behavior" while "weird random name" signals "nice modern API and coherent semantics". Of course, it's not always true, but humans are voracious pattern matchers and will create an association at the slightest hint of correlation.
I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will say that funny names are not actually fun.
I can only imagine working in the author's ideal company:
"Hey, does anyone know why Shmoop is down? I know I updated the BoomBoom and reconfigured Thanos, but now Klomgan is reporting a series of Lemonhead warnings. Should I talk to Meep team or the Chumbawumba admins?"
I worked in a company that would "break ground" a new microservice every other week with overlapping scope of other microservices. (poor planning in resource allocation), which lead to some services named after Greek mythology that loose describes what service does...sometimes... Then they started giving more descriptive names, services that just do X and named X, except later they started doing Y, and now it's confusing.
Then we had service XYZ (abbreviated from what it supposed to do), it took too long to build, so naturally management decided to make a Z service and remove functionality from XYZ.
I think the author comes from a similar place where scope for service is constantly changing, and silly names are the only source of dopamine.
Upon the recognition of this is the time you should have your resume updated and you start responding to some of those LinkedIn reps that have been emailing you.
https://www.youtube.com/watch?v=y8OnoxKotPQ
I'm completely with you that name choice is not necessarily where something needs to be fun, and most people don't realize that once you name something, it's probably around for 5-10 years whether you like it or not. Or if it succeeds or fails.
The what?
The what?
And the what?"
What method would you propose teams used to name a project, in which "fun" names are discouraged?
Maybe "whimsical" isn't an accurate moniker. Generic or Common is how I would label the naming strategy described by this article. "Whimsical" is just asking for trouble and opens you up to overtly stupid names like "Chumbawumba."
The article says "names should make you smile." And really, does anything make a person smile more than Chumbawumba? They get knocked down, and they get up again!
Imagine a “UserProfile” service. It’s accessed from everywhere to show the handle name, address, icon etc. of your user.
Your application grows and your users want way more customization, now they get personas and avatars and can show different profile to different people. Those are full of breaking changes that you want to isolate from the legacy “UserProfile”, how do you name your new service ?
Some of you are thinking, well, what if you need to interface with facebook dot com? Easy, I'd call it the SneedFeed. If you know you know.
Sound like it's better to make a new service. Isn't that the point of Single Responsibility concept?
Lucky you generally only care about release names within a single product because thinking which one is Jasper Lake and which one is Alder Lake is not something I want to do.
Even those product names are not excellent either: Intel introduced i9 which is essentially what i7 used to be and used to justify higher price - look i7 is the same price, but it's the brand new i9, that is totally wouldn't be called i7 5 years ago, that cost more.
Probably hard to get street cred for a cutting-edge processing monster named FluffyKitten.
If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing a design up-front, or drawing diagrams of how your system works, then this indicates one of two things about your background.
1. You're a relatively junior engineer who has gotten used to thinking about productivity as slamming code that tweaks existing systems into new incremental features
2. You work on some fucking web service.
Either way, your advice does not apply to the software engineering profession as a whole. Believe it or not, lots and lots of people write software, and not all of it is a web service or some tool / framework to help run your web service. There are many things out there are that can be envisioned, designed in detail, and implemented. And, crucially, in those cases, _it is wise to do so_.
I know I'm being overly dramatic, but it consistently enrages me reading blog posts that, through ignorance or deliberate omission, speak as if the world of software is just writing web services.
Also, please don't fulminate in HN comments.
The author did hit on the truth, no matter how he arrived there. Descriptive names are prone to collision, misdirection, and are much too long unless you use acronyms (in which case you may as well come up with a whimsical, pronounceable, unique name and just backronym it). This isn't a new idea. Lots of greybeards know this and name stuff accordingly.
Often times when people get creative with names, the meaning dies with them. When they leave the company so too does the reasoning behind the name.
The author conflates service bloat with bad names. Fix the bloat and the name will make sense. If you have an app called “Authorizer” and it does email, you failed. If you have a service called “InfraValidator” all it should be doing is validation. If it’s not (such as tensor flow’s infra validator) then the service/app/codebase is misleading and needs to be renamed after what it does.
I also hate to see overly descriptive names. Package/crate/bundle/module should help classify the name of the class/object/func_collection.
Names like “EnvironmentPostProcessor” (Spring Boot) is succinct enough to know exactly what it does. It processes environment vars after a stage.
The author actually does discuss the nuance. They argue exactly your point saying that their “considered harmful” advice only applies in situations where the scope of the component is ambiguous/fluid/unknown/otherwise prone to change over time/etc. In cases where you have a mature fixed design, choose an appropriately descriptive name.
I’m glad you have only ever worked on projects that were perfectly designed up front. Sounds like the dream. For the rest of us, we engineer in reality. And I find the author’s point apropos.
Or, it could be that you're actually innovating and requirements are changing faster than you write code.
A late change in requirements is a competitive advantage.
There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing.
In spite of that, when did "making a database product" count as not "hard?" Building a database isn't "real software engineering™?" Since when was building "authorization microservices" easy? In the simplest case, sure. But authorization in general is a huge problem space and I don't understand calling that "bs." Active Directory would like a word...
So true. Web services are just a distraction from real software, which is writing compilers.
> Even worse are those ubiquitous diagrams everybody uses to communicate about software, where there’s a box labeled OrdersService with an arrow connecting it to a box labeled OrderStatusService. I don’t understand why anybody draws those.
People like this are why there are documents with a thousand bullet points and no diagrams to help anyone actually visualize how this all fits together.
It's like a children's song ...
The foot bone connected to the leg bone, The leg bone connected to the knee bone, The knee bone connected to the thigh bone, The thigh bone connected to the back bone, The back bone connected to the neck bone, The neck bone connected to the head bone
And by the end of it you still don't know what you are dealing with.
Already have Service and need Service? How bout NewService and Service instead. Or ${NEW_TRAIT}Service and Service. (can replace Service with any domain)
You could also just not duplicate and keep a single Service. Like other mentioned this is likely a design problem at any point names clash.
Personally I prefer UUIDs for global uniqueness.
I once created a PHP framework called RocketSled because it was “the fastest thing on rails” and that gave rise to somewhat whimsical but also descriptive names on the same theme:
RocketPack: package manager
DataBank: caching auto loader
Murphy: automated testing
Each of those modules is named quite specifically but that’s because they do one thing.
I created an ORM tool called PluSQL, because it’s not an ActiveRecord style ORM but adds a bit on top of straight SQL statements. General enough that if I want to enhance the functionality beyond ORM I can, but also pretty easy to remember what it does from the name.
The one library I created that may suffer from the problem described is Trellinator, which I recently began updating to work with the WeKan API, so maybe that should have been Kabanator … there’s still time.
But I don’t think calling them all after my favourite Futurama characters would have been a better choice.
"Following the end of hostilities, in 1947 Murphy attended the United States Air Force Institute of Technology, becoming R&D Officer at the Wright Air Development Center of Wright-Patterson Air Force Base. It was while here that he became involved in the high-speed rocket sled experiments (USAF project MX981, 1949) which led to the coining of Murphy's law."
I was very pleasantly surprised by this coincindence when I was looking for a name for my testing package to go with my RocketSled framework. I named the framework RocketSled before I wrote the testing package, with no idea about the history of the term Murphy's Law.
Interesting side note: murphytest lives on to this day as an NPM package, I still use the same approach to testing stuff now (ie. not worrying about any of the tenets of "Unit Testing", a practise which I called "Convergence Testing" at the time, but which probably already has a name, like Integration Testing maybe).
A tool for sending mails via Mailgun? “Railgun” then, for example.
I disagree with that. Cryptic names can become jargon, and jargon is useful in expert teams. At my last job we had a service whose role was to convert operations from system A to system B so at first we named it systemAOperationsToSystemBOperations. The name was clear but it was a pain in the ass to talk about it. We renamed it adios as a shorter name (irks like a fake acronym of the initial name) and it became way easier to talk and reason about our system. We lose a few minutes once in a while to remind juniors what adios does but we gain an efficient name to discuss the service day to day.
Oh, and as for "If it's not that big rename it" - this article is specifically about things that are hard to rename (e.g. public facing APIs or libraries):
> Now, if a name is going to be easily changeable forever, please do make it descriptive.
It is difficult enough being onboarded to a new company without having to learn two dozen names for random services and libraries. I feel sorry for each batch of Interns that start at companies that do this. Not only were the Interns learning how to build software but they also had to learn random names that they would not be able to use in their next placement.
What is easier to understand at first glance?
Picard stopped responding to Luke. Bilbo is also down!
or
PaymentService stopped responding to UserService. Database-XYZ is down!
It might not be exciting but the cognitive load is much lower.
This PaymentService grew into fraud detection. So the new hire will be even more confused. Asking "What does Picard do?" is natural, where a new hire might have trouble asking "What does the PaymentService do?"
You have bigger problems if your `PaymentService` morphs into the functionality of being a storage or user service.
And if you having a payment system that starts doing something payments systems traditionally don't do - like, I dunno, predict weather? - then you have a design problem and should refactor your system so your payment system doesn't do that anymore.
PPS stopped responding to UDMS. CMS is also down! No, not the CMS, the CMS is fine… CMS-the-service is down!
The result - well, it works in some respects, but it would take a real optimist to say that brings any clarity or long term order to the process by which medical professionals learn or refer to the drugs they prescribe and administer, or that it plays much role in getting the right prescription into the right medicine cabinet and ultimately, patient. The names are confusing as hell, often unpronouncable (despite the orthographic and oral qualities of the names being considerations in name assignment) to anyone who doesn't know them well, professionally. And the common drugs - well, let's just say, you're far more likely to tell someone you're on Lipitor (a brand name, for marketing) than "atorvastatin".
The part missing here is that there's a doctor in the middle that knows about the "atorvastatin" part, and that's usually who prescribes you the Lipitor.
Another part is that the name should be a) unique, so you could make it a trademark, b) distinct, so the patient won't tell their other doctor they take a wrong drug (less important now with electronic databases but still important) and c) shouldn't mean anything to the patient, because they aren't the one deciding whether to take it or not - but they will be the ones taking it.
That's usually not the case with software packages. Of course, sometimes it is the case that the manager decides to buy software because it sounds good without technically understanding what it actually does - but it's not a common case, especially for more technologically complex software. So the naming considerations here are very different.
a) The official (that is, generic) drug name is guaranteed to be unique, but they cannot be trademarked. That's one part of why drugs are typically marketed under names other than the official name ("Lipitor" is a market name, "atorvastatin" is the actual drug name).
b) Most patients don't know the names of the drugs they are taking, and what they do know are as often as not, not the official name, but a marketing name. Ask any doctor why they ask patients to bring their prescriptions with them to office visits (hint: because in m any cases, it's the only way to get an accurate picture of what a patient is actually taking.)
c) I don't follow this at all. It's a bad think that I know that the three drugs I take are a diuretic, a beta blocker, and an angiotensin receptor blocker?
I think it's interesting to compare drug naming with other medical interventions. We don't call a Laparoscopic Cholecystectomy a "gandalf" or "vartafoprodson." We use medically meaningful names. Why is "losartan" better than "angiotension receptor blocker 95-1" (first ARB approved in 1995)?
> it would take a real optimist to say that brings any clarity or long term order to the process by which medical professionals learn or refer to the drugs they prescribe and administer
In this case I don't think you can have the cake and eat it too, unless you can somehow prove that the chosen descriptive name will forever remain meaningful and descriptive.
"Problem" solved!
Afraid of losing stars/dlds on the repo/etc? Make it clear in the Readme where the new project is. Have warnings et al for NPM projects.
Ask npm/GitHub to allow name changes with redirects.
This proposed "solution" is just bad for many reasons:
You need to delve into the Readme to find out what it does. Imagine you're seeing a package.json and for each line you have to Google what's the project about
SEO is best if name matches.
These are enough *good* reasons why this advice is a bad idea
Whoever named the ML thing "transformer" deserves a special place in hell. So many intriguing headlines, so few things worth reading. (I'm an EE, so I'm very interested in the other transformers. For some reason, the headlines for these things scan like they could apply to either. Alas, they don't.)
Your complaint is similar to cryptography conference attendants hating the word ,,crypto'' to change from cryptography to cryptocurrency, but that's just the natural evolution of language with technology (not mentioning that the original meaning of the Greek word is hidden/secret).
...some of the time. The rest of the time they're actually very useful. Giving up any attempt at having a descriptive name just in case you get it wrong is throwing the baby out with the bath water.
What's probably happened with a lot of poorly named projects is that when the scope changed to make the name redundant there was no attempt to change it. People get attached to their project names. It's possible that changing the name would require some effort, and maybe some cost (losing Github stars maybe?). That makes people stick with bad names. None of these things apply in a company. Just change the project name to reflect what it does now.
Try to come up with descriptive names for projects like Git, Node.js, Docker, well, Linux. Well, BSD is formally a descriptive name, but it elucidates little.
Of course there are some examples of somehow descriptive names which seem natural because of the sweeping success of the product: Photoshop, React. But they are few and far between.
In short, project names are closer to branding than to engineering.
Inside a codebase names should be descriptive, and appropriate effort should be allocated to name key things in an elucidating manner; nothing to debate here. But it's a very different context.
There's probably some cultural context I'm missing here, but I asked around in the office and got a different answer each time as to why it would be named like that.
That was 9 years ago and I still don't know BTW.
I mean if you go with cryptic then at least call it something short and obviously cryptic. "Chrome" good, "VersatileGopher" bad.
PS Yes I know that Chrome actually has an explanation, but it does not sound like it means something that you could guess if you thought hard enough. I'm also not criticizing Ubuntu release names because the context is obviously different.
A dashed arrow pointing in one direction is async data flow in that direction, A solid arrow is synchronous, and a swimlane / activity diagram shouldn't have two-way arrows in it (what would that mean?).
How is that more likely to be read wrong than source code? Doesn't match my experience at all.
Very bizarre ... also, why not BOTH a diagram and discription.
There's ~50, and nearly all of them are incomprehensible. It definitely makes things much less accessible to a newcomer / outsider.
(Trilinos is a set of scientific / engineering libraries for HPC)
This way no one is misled by the name. Also, there is much less chance that an offensive name gets picked (either intentional or unintentionally).
There is also much less risk of collisions. In addition, you don’t waste any time trying to come up with a name.
"I try to step back and remember my first shallow reaction. The day I realized it can be smart to be shallow was, for me, a deep experience."
I am not going to tell you who this is, but the point stands.
The name should be easy to pronounce, it should zing, and your first reaction should be positive. Why do you have it? Doesn't matter. It's either there or it's not.
A good name is at least half of a product's success.
It would get tiring to have to keep explaining to new team members that our prime number generator is named "optimus" even if it was initially clever.
I don't look forward to convincing my boss we need to pull in "libAnimeBabe" as a dependency even if it's the best parser for a file format we need to import.
Nobody wants to find out a year after all of our marketing material is put together that our software name means "asshole" in another language.
Don't make me have to pronounce an unpronounceable Gaelic word every time I do a presentation on our software stack because you're Irish and just had to name your component that way.
There are lots of ways "whimsical" can backfire unintentionally. Save your creativity for the actual software solution.
I also kind of disagree that an "unpronounceable Gaelic word" is a poor choice. Seems like cultural discrimination. People all over the world write software, not just people who can pronounce English words.
Try working in an environment where team leads are allowed to make up whatever names they want, create as many projects/services as they want, and organize everything based on whim. You get this: https://www.youtube.com/watch?v=y8OnoxKotPQ
For me that is not a parody, it's lived experience.
> I’m probably being overdramatic there, but I hope my point is clear. “Descriptive” names don’t create transparency, they create the illusion of transparency. If you see that something has the name OrderStatusService, you will instinctively assume you know what it is and does, and you will probably be wrong.
When what a thing does changes then the name should also change. I almost want to counter this Medium post by arguing that READMEs should be works of fiction because the project they describe might change over time.
Software should be fun! I love it when packages have goofy names. If I can shitpost with the language I'm going to get just a little more invested in it.
And to be honest, even the 'serious' names fail at connoting respectability to begin with. Your grandpa would get annoyed just hearing the word 'containerisation' - and not just because he thinks computers are for nerds. The word sounds silly. People are saying this silly word at conferences and the word is still silly. So why not lean into the goof?
When I think of programming things I use the most, most of them have whimsical names that mean nothing.
I mean, say, “grep” means… something with regular expressions I guess? But nobody cares. It’s just “grep”.
There are only 2 difficult things in computer science:
1. Naming things
2. Cache Invalidation
3. Off by one errorsAnd it's not like "oops some gadget polishing code fell into my widget lookup service": don't put inappropriate crap into your solution. Little discipline goes a long way.
One useful practice I've acquired over the years is to make the names unique. It makes it easier to search for them later.
Generally, I would lean towards descriptive names. If the name no longer fits the thing, that's a great warning about scope issues. If it sounds "weird" for other named things to be dependent on or be required by the named thing -- that's often a hint about a context issue.
I mean, there's a reason the old joke goes:
"There are only two hard problems in computer science; naming things, cache invalidation, and off-by-one errors."
That seems like a bad example. I've often googled "cronjob foo" for how to schedule something in foo. Seems like "cronjob" is a general term for scheduling now.
The fact that Arvo (the kernel) doesn't even have a distinction between RAM and disk, or between PCI input and network input, is a much bigger deal than remembering that "Arvo is the kernel".
OP is right that naming can give a false sense of familiarity, so inverting that for things like this makes sense. Create a false sense of un-familiarity, to keep the users paying attention while they learn what they are using. That's been my experience so far, a heightened sense of awareness while reading through the cryptic documentation.
Business owners and product managers tolerate the whimsy when systems work, but then suddenly when you can't make a feature commitment to a customer on whose relationship your business growth depends - because of the tech debt you accumulated by not priortizing UnicornPoo in your engineering roadmap, you realize your engineering team has essentially betrayed your organization so that they could be lazy and focus on science projects, and the code names were to obfuscate their commitments, and as an expression of spite and contempt for the people they took money from. Whimsy is cute initially, but it quickly becomes uncanny, and even repulsive to see adults acting careless. Cuteness is how children bargain with nature, and in a corporate environment that is about the livelihoods of adults, it is a liability.
That way, they're both whimsical but easy to remember, and if they drift a bit, it's fine.
"Always give cute names", "Always give descriptive names", "FP is always good, OOP is always bad", "Always test first", "Always test later" etc.
Golden laws don't exist: Pick the best solution for your current situation and accept that your current situation will change. (Which is, again, a trade-off between now and the future!)
If it's a product, by all means think about brand including a creative name. Might be vaguely related to the service, like YouTube, or completely wild, like Starbucks.
If it's mostly a tool, being descriptive is just good SEO. You are not ever becoming a "household name" with a recognizable name when you are just supplementing a library supplementing a framework (or similar), and there is no reason to strive for that. "Django REST framework" shows up naturally when I google "django rest" and that just benefits both sides.
If you are in between the two, opt for the middle: TweetDeck, MailChimp.
That's my two cents anyways..
I feel almost like there's an analogy between choosing names for packages/projects and bird calls. Birds need to make their calls stand out in a given ecosystem. If you have a dozen projects like, say, "object-mapper," "object-db-mapper," "object-mapping", "object-mapper-thingy", "object-mapping-service", "db-object-mapper", it's hard to remember wtf was the one you need. If in such an ecosystem your project was named "Orangutan," it might stand out and be noticed. OTOH, if all projects in a given ecosystem have weird names like "murano", "swift", "glance", "hotdog", "gorilla", "zaqar", "cthulhu", "funky-chicken", "Sauron" or whatever, it may be hard to remember what they all do/mean -- yes, I'm giving you the side eye, openstack. In such a space, "cloud-disk" or something might win, IMHO.
Slightly tangentially related is the use of odd words in log messages to aid searchability. I've been grateful for misspellings in the past, so I could easily grep for some critical log message containing `transation_id` or whatnot. (Good struct logging makes this less necessary, thankfully.)
The name itself comes from Dune, where the Bene Gesseret Missionaria Protectiva is itself whimsical (on some level) and cryptic. https://dune.fandom.com/wiki/Missionaria_Protectiva
Naming things is also very important. Having some common language or way to refer to the various abstractions in the business is essential for basic teamwork. Even if the name is a cringetastic take on a comic book character. As long as everyone agrees on the string literal, you will be able to make forward progress.
If you aren't absolutely certain what something should be called (i.e. maybe you are prototyping a crazy new idea), just invent some crap to keep moving along. I've got a shitload of odds and ends in static classes simply named things like "Utility" and "Hack". When you aren't so invested in what something is called, I have found you are much more willing to get "creative" with it. Naming things can also start to imply some sort of structure, so keeping it flat like this helps reduce the cognitive load.
On the other hand, maybe you should consider more precise, deliberate naming if the business at hand is relatively stable and complex. Banking is a great example of a domain where very precise type names can make a huge difference in productivity. There is a gigantic difference between a "beneficial" owner and a "beneficiary". Applying reductive/creative naming schemes to this domain would likely cause more harm than good.
You can always rename stuff in the future. Even database schemas can be migrated over time without impacting live customers. You can even rename an entire company (i.e. Facebook => Meta).
I work on the same, but never learnt to use non-descriptive names.
Choosing whimsical names is a pretty good way to satisfy my two most important requirements. They are often unique and don't mislead people.
Of course my ideal name would also give some hint about what it does (I think Google's BigTable may be one of the best named products) but I think this is far less important than the other two requirements.
I think most of that applies here. The whimsy & fun is cute at first, but it's rarely long term magic. For new teams & outsiders, it's a pain. I've had to work eith a sync engine where there's 20 subsystems seemingly each named by randomly picking a name from Encyclopedia of Mythology. There's probably something cute & creative & whimsical to the authors, but as someone trying to use the thing, it's merciless & oppressive, a huge turn off.
[1] https://tdarb.org/blog/death-of-personality.html https://news.ycombinator.com/item?id=32777411 (79pts, 3d agi, 63 comments)
I'm working with some legacy code that followed this pattern for internal services. It's a nightmare. WTF is Bilbo, oh it handles 2fa? And what's Pippin again? And there's a dozen other examples, of course most of them are from LOTR. I literally have to maintain a mental mapping because there's no rhyme or reason to the choices.
That's actively anti-developer, anti empathy and I hate it. It's not cute, fun, helpful, professional. I can't think of a single redeeming quality. Maybe it's ok for a prototype you intend to throw away because it's so ridiculous you don't want to use that name with your boss, so it encourages non attachment.
If you really can't pin down a name that describes the thing you're making, maybe you don't know what you're making?
Also, we can rename and/or retractor things. And we should if their responsibilities change!
Edit: added distinction about internal vs external.
The author here is equivocating opaque code names with multi-use repos. They're saying "see!? some repos on github do things in addition to their literal name."
That has nothing to do with the fact that obscure code names are a stupid anti-pattern.
All the variables were global since there were not functions to pass things into and we had a problem similar to what the OP posted about using variable names that someone else might be using somewhere else. One thing we needed was `machine_type`. There were some references to `MachineType` and `machine_type` and `machineType` so, a colleague decided to use the name `MaChInEtYpE` to make it unique. For all I know there are still people who trip over themselves on the keyboard typing this while maintaining it.
I'd argue that actually descriptive names aren't the worst thing ever, I wouldn't mind seeing a project/source code repo named "Client Bill PDF Generator" as long as the name on the tin actually matches what's inside of it. Of course, that implies that in the case of scope creep you should be able to change it as necessary.
What this avoids is the problem of not needing a glossary to figure out what "Shelob" is supposed to be in a list of 50 different services, though I guess if you wanted to go for something fun, might as well throw them together: "Shelob: Client Bill PDF Generator".
It's kind of how I approach naming my homelab servers/saving SSH sessions, a randomly chosen hostname comes first, but what it actually does is appended to the connection name/monitoring dashboard name - mostly because what I use the servers for might change so often, that this is one of the use cases where "fun" names make sense.
Actually, Dylan Beattie once described why "fun" names might make sense, in a conference talk called "Life, Liberty and the Pursuit of APIness : The Secret to Happy Code", though it also touched upon other aspects of development.
Here's the video timestamp for the problem situation: https://youtu.be/BIkXid_pBiY?t=769
Here's the video timestamp for the proposed solution: https://youtu.be/BIkXid_pBiY?t=946
The argument went along the lines of "by giving it a name, you cut out a lot of the noise". Curious, I can kind of understand that point of view, even though I'm not inclined to fully agree with it.
Judging descriptive names by their worst examples is not exactly a charitable interpretation.
In a team ecosystem where you probably need to optimize for readability and ease of use, try to be simple and accurate and get used to refactoring. Making up random shit is the worst advice I can think of.
For example, I tend to use a “layered” approach to servers. In one of my projects, the DB layer is the lowest, and is unnamed (it would start with “A,” if I had named it), so I named the DB connector “BADGER”[0]. The layer above that, is called "CHAMELEON/COBRA" (They are basically at the same logical layer).
[0] https://littlegreenviper.com/miscellany/forensic-design-docu...
I think if you expect you'll only need a small group of people to know the name (the "Shelob" example at a startup), or you expect a large group but only are adding one name to learn ("Vue"), it's fine.
The cute naming gets hard on larger projects. If you have to write a status or design document covering many teams, all with multiple cute names, that document will be impenetrable. It will be as hard as learning a new language - which in a sense it is, because your team will have created a new language that outsiders will need to understand in order to work with your team.
This is something I am very grateful for when I return to a project after some time away and the code is documenting itself.
But I'm also a fan of disposable code. If I'm actively working on something I probably rewrite more or less the whole project every 18 months bit by bit.
The original escape turned out to have character issues or so, so they made a new one: mysql_real_escape_string
We were hoping they would find another issue and release a mysql_real_real_escape_string
If your software is a "final product" which by definition can grow in requirements then it's best to use a creative name. So if you build a programming language, a build tool, a dependency analyzer, or any kind of software that has the shape of a tool; which the user can wield in a variety of ways. I'm glad we didn't call a hammer a NailPounder since it can do so much more.
For example, game engine. Some library or framework, that helps you to build games. Nice.
But what they do for you in detail isn't known, and can take months to understand.
Unity does much more than Phaser. Angular is a total different beast than React.
And this goes down to class names. MVC was the hype back in the days, but nobody knows what it actually meant in detail. Some people sat down and wrote some definition of the term, but no implementer adhered 100% to them.
My team work on a project with many "funny" names, including but not limited to, liboyster, libowl, several characters from Fort Boyard (https://en.m.wikipedia.org/wiki/Fort_Boyard_(game_show), patric the starfish....
It was awful to work with, please don't go that.
If you were to compare the total time wasted by each category, I’m sure nondescriptive would come out as the most wasteful by far.
1. Names must be descriptive.
2. Names must be unambiguous.
3. Names should be no longer than they need to be to achieve #1 and #2.
If your names are becoming less descriptive over time it's because you're not writing well. It's not easy to write well, but that's the job.
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Addison-Wesley Microsoft Technology Series) 3rd Edition
I agree that bad and/or misleading names are, well, bad. However, I don't agree that we should just give up and name everything {SomeCrypticNameIThinkIsCool}.
Invest time in naming things well the first time.
Invest time in renaming things to be more accurate when it is feasible.
if it's projects, ideally the long-term architecture is well enough understood to give the thing a whimsical yet meaningful name (ideally not cryptic). building a page caching service? call it gutenberg or something to start. when it inevitably grows past scope, it's ok. no one will care if gutenberg also handles analytics callbacks or whatever.
classes really shouldn't change in scope, ideally, so it's probably better to be a bit more specific to their purpose.
overall this is a good hot take, if a bit broadly put.
> If names are too clever, they will be memorable only to people who share the author’s sense of humor, and only as long as these people remember the joke. Will they know what the function named HolyHandGrenade is supposed to do? Sure, it’s cute, but maybe in this case DeleteItems might be a better name. Choose clarity over entertainment value. Cuteness in code often appears in the form of colloquialisms or slang. For example, don’t use the name whack() to mean kill(). Don’t tell little culture-dependent jokes like eatMyShorts() to mean abort().
> Say what you mean. Mean what you say.”
~~ Clean code, Uncle Bob
Now get off my lawn!
Let's face it, no software company where any of us work has ever been satisfied with "well, we have enough features already, no need to build more." The incentives _always_ push for-profit software towards "build a shiny new feature", because you can't upsell existing customers the same features they already pay for, but you _can_ upsell them _new_ features.
So companies monotonically grow their featureset.
Companies also do _not_ monotonically grow their employee base, and _certainly_ not at the same rate as they grow their featureset.
So, for example, the "email send team" of today will probably become "the email sending and rendering and link-tracking and some-of-the-reporting-but-not-all-of-it and some-of-the-public-API-but-not-all-of-it" team before long. And they'll probably also gain additional features along the way, some of which are likely to be even _less_ related to things like SMTP and MTAs (which they'll still regularly have to deal with).
In the meantime, those "some-but-not-all" categories will be shared with other teams, usually in a way that's not neatly describable in 1-2 words.
So do you keep constantly changing your "descriptive" team names and fleshing them out into entire often-mutating paragraphs so that they're _actually_ descriptive? Because you're _certainly_ not going to wait to build a feature until there's a new team for it. And what happens when you decide that some of those features should change hands to a different team? Time to go update all your CODEOWNERS files and ACLs and directories and everything so you can change the team's name again?
Or do you accept that memorable-and-unique-but-not-descriptive team names like "Apollo" or "Wombat" are a better use of your time, and find other ways (like relating per-feature PagerDuty "services" to team-level escalation policies) to map "feature X is currently owned by team Y"?
Because honestly? 70% of the time that you would want a "descriptive name" for a team, it's because you're trying to reach/page the right team to fix a problem.
Set up feature/service definitions in your tools of choice (PagerDuty, Jira), and make sure those are many-to-one with the team definitions, and then ensure that those definitions can be easily modified/reparented later.
To put it in programmer-friendly terms, don't use magic strings, factor out real identifier constants, and reference that constant instead of duplicating it.
P.S. to those of you who might say "you can just pick a generally-descriptive-enough name without it listing every feature", I once worked on a team named "<Product> Email Team," and we _frequently_ got questions/tickets/bug-reports about email-related or email-adjacent features that were actually owned by other teams (either on a different product, or as more of a "downstream" thing). We also sometimes _didn't_ get questions passed our way that were related to the non-email features we'd accumulated over time (see also: featureset growth speed vs. "headcount" growth speed). We were eventually renamed "<Product> Email And Content Services Team", ironically because our existing "descriptive" name was deemed "insufficiently descriptive". Rather than fixing the problem, the new name in fact only exacerbates the problem, since no two people can clearly agree on what "Content Services" are.
