Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software component names should be whimsical and cryptic

medium.com

Post reply on HN
Print view View original

141–150 of 339 posts

Re: Software component names should be whimsical and cryptic

#141

Post by jayd16 »

ttiurani wrote: post #59

> See, the scope and purpose of something changes faster than its name can. 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.…

Exactly. Don't just cram functionality into the closest thing at hand without any thought and you won't have to worry about scope creep ruining the name of that thing.

If you want to make new and different things, just do that.

Re: Software component names should be whimsical and cryptic

#142

Post by silent_cal »

Ensorceled wrote: post #99

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…

This is a great diagnosis. I hate to assume things, but sometimes I almost get the impression that some software developers are pulling an "I am very smart" move by making things more cryptic than they need to be.

Re: Software component names should be whimsical and cryptic

#143

Post by lifthrasiir »

yuan43 wrote: 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…

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

Re: Software component names should be whimsical and cryptic

#144

Post by onion2k »

“Descriptive” names don’t create transparency, they create the illusion of transparency.

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

Re: Software component names should be whimsical and cryptic

#145

Post by jgerrish »

yuan43 wrote: 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…

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.

Re: Software component names should be whimsical and cryptic

#146

Post by hulitu »

kogus wrote: post #123
yuan43 wrote: 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…

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

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

Re: Software component names should be whimsical and cryptic

#147

Post by jayd16 »

pavlov wrote: post #42
MrSqueezles wrote: post #24

Earlier quoted context omitted.

Yes. The advice is contextual. If you're making a public web framework, probably don't call it Web Framework. If you work at a company and you're writing the one and only hotel booking service, do call it Hotels instead of forcing your coworkers to memorize yet another cute name.

This only works once though. In ten years, none of the original developers of Hotels are with the company. The new generation of engineers is upset both with Hotels’ limitations and the fact that it’s not written in XYZ language which they really want to have on their résumés. So they embark on a total rewrite of Hotels, and to emphasize the awesomeness, most likely it will be called either Phoenix (because one out o…

How about just Hotels 2.X.X.X? Honestly, not much reason it can't be the exact same namespace depending on the language and whether the new and old would be imported by the same project.

Re: Software component names should be whimsical and cryptic

#148

Post by hulitu »

ttiurani wrote: post #59

> See, the scope and purpose of something changes faster than its name can. 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.…

like libcaca. Caca means sh*t in some languages.

Re: Software component names should be whimsical and cryptic

#149

Post by taeric »

onion2k wrote: post #144

“Descriptive” names don’t create transparency, they create the illusion of transparency. ...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…

While I agree the extreme is clearly bad, I would also challenge if any project ever succeeded on any virtues of it's name. Such that I would see this as a very low stakes decision.

Re: Software component names should be whimsical and cryptic

#150

Post by plaguepilled »

I agree with the author but for different reasons.

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?

Post reply on HN