Live data from Hacker News

Software component names should be whimsical and cryptic

medium.com

111–120 of 339 posts

Re: Software component names should be whimsical and cryptic

#111
post #108

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 varia…

> 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.

Re: Software component names should be whimsical and cryptic

#112
post #76

Earlier quoted context omitted.

Sed and awk kind of sound like high-level troll names.

Both of which cower in fear when vi strolls by.

All fear the mighty `w`, `X`, and, most terrifying of all due to the uncertainty of their proper pronunciation, `[`!

Re: Software component names should be whimsical and cryptic

#113
post #106

Inside this essay giving horrible advice, is more horrible advice: > 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 actuall…

Sure but what to do if all the good names for doing the thing the thing is doing are taken ?

When faced with the same problem, Elon went with X Æ A-12.

Personally I prefer UUIDs for global uniqueness.

Re: Software component names should be whimsical and cryptic

#114
I strongly agree with this. I’ve worked places that follow both naming styles and I’ve found it’s much easier to get up to speed if the services and repositories have names that don’t overload the language you use to talk about what you’re doing. E.g. if your service that sends out webhooks is called “webhooks”, then newcomers will always be confused about whether you’re talking about the concept or the implementation; if the service is called “voltron”, newcomers might not know what it does initially, but they can discover that pretty quickly.

Re: Software component names should be whimsical and cryptic

#115
post #33

Earlier quoted context omitted.

QuickBooks 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.

Yep, could also be those things. But accounts and bookkeepers all know what QuickBooks is and are quite happy to not have to explain to their clients why they need to spend $75 a month on "KowalaBabyPooPoos" or something equally ludicrous name. Which is the point which you probably didn't miss in the first place.

Apparently, there's an accounting software called Xero, they have the dotcom[1]. Pretty good name and domain IMO.

[1]: https://xero.com

Re: Software component names should be whimsical and cryptic

#116
There is a real world example of a complex, critical, domain that has followed this approach religiously for years: prescription drugs. Every prescription drug is given an essentially nonsense non-proprietary (generic) name, with only broad categories identified by a stem (drugs ending in "mab," e.g., are monoclonal antibodies, those ending in "vir," are anti-virals). Names that are suggestive of medical target or use, beyond what is implied in the stem, are not allowed. The system is international, with international bodies ultimately approving naming of drugs.

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".

Re: Software component names should be whimsical and cryptic

#118

There is a real world example of a complex, critical, domain that has followed this approach religiously for years: prescription drugs. Every prescription drug is given an essentially nonsense non-proprietary (generic) name, with only broad categories identified by a stem (drugs ending in "mab," e.g., are monoclonal antibodies, those ending in "vir," are anti-virals). Names that are suggestive of medical target or us…

I've been on medication for years, and I still can't pronounce let alone remember it's name. God help me if it becomes critical I tell someone what it is, because I'm screwed if so.

Re: Software component names should be whimsical and cryptic

#119
post #108

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 varia…

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

Re: Software component names should be whimsical and cryptic

#120

The throwaway comment about not using diagrams was truly baffling to me. 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.

> The throwaway comment about not using diagrams was truly baffling to me.

Very bizarre ... also, why not BOTH a diagram and discription.

Post reply on HN