Software component names should be whimsical and cryptic • Hacker News Board

Re: Software component names should be whimsical and cryptic

#171

Post by bombcar » Tue, Sep 13, 2022, 3:14 PM UTC

Tade0 wrote: post #11

eternityforest wrote: post #4

Aesthetically, at this point descriptive names almost look unprofessional, or at least quickly made. If you call your thing "ui-state-syncer" I'm going to suspect it's not really a big budget mainstream thing. 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 specifi…

Seems that names for projects follow the same rule as troll names in the japanese light novel Overlord. 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.

If you are going up against Gothmark, Destroyer of Worlds you might have a chance. But if everyone calls the big bad Dennis you’re pretty much doomed.

Re: Software component names should be whimsical and cryptic

#172

Post by glacials » Tue, Sep 13, 2022, 3:17 PM UTC

The author subjected themselves to confirmation bias by specifically searching for “despite the name”. Perhaps for every service that outgrew its descriptive name, there were 99 that helped people understand them more easily.

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.

Re: Software component names should be whimsical and cryptic

#173

Post by charles_f » Tue, Sep 13, 2022, 3:18 PM UTC

> “Don’t Be Cute

> 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

Re: Software component names should be whimsical and cryptic

#174

Post by travisgriggs » Tue, Sep 13, 2022, 3:22 PM UTC

I don’t care if you name them descriptively or weirdly, just please name them distinctly so when I have to do searches for them I come up with the right thing. The worst is Apple’s “Pages” and “Numbers”. Try doing a search for how to do something in either of these products. These are far from the only examples.

Re: Software component names should be whimsical and cryptic

#175

Post by calvinmorrison » Tue, Sep 13, 2022, 3:23 PM UTC

danielvaughn wrote: post #119

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…

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

i was wrong, this doesn't work in perl

Re: Software component names should be whimsical and cryptic

#176

Post by robsws » Tue, Sep 13, 2022, 3:25 PM UTC

I can just about tolerate this for brand names, as there's an additional set of requirements there, but for everything else, it's just gatekeeping and unnecessary obfuscation. If the purpose of something changes, fork it off into something new or just rename it if possible. Apache TinkerPop Gremlin might be fun for the creators, but not for anyone trying to understand what it does.

Re: Software component names should be whimsical and cryptic

#177

Post by politician » Tue, Sep 13, 2022, 3:26 PM UTC

danielvaughn wrote: post #119

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…

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.

Re: Software component names should be whimsical and cryptic

#178

Post by gabereiser » Tue, Sep 13, 2022, 3:31 PM UTC

whatshisface wrote: post #169

gabereiser wrote: post #166

Earlier quoted context omitted.

I came here to write something similar. The article lists a few repos as examples of bad naming when the reality is, it’s examples of miss-naming. For a long long time I’ve convinced people to use literal names for things and not get creative. A BillingStatusService , as the author has cited, isn’t an example of a bad name. It’s an example of bad engineering that it does more than BillingStatus . Often times when peo…

In many environments you don't control the evolution of software. Unless the big boss does all the naming, then the people doing the naming can't stop other people from making AuthTokenValidator send change password emails and them eventually send marketing emails. ("Hey, this service already controls the noreply address...")

If you developed your services right. You’d have a notification service that does SMS,email,smokesignals…

It’s up to principal/staff engineers to make sure that the components of the system stay lean to its purpose. They should be able to say “oh, we need to send an email when this happens? Here’s an email service we can use” that doesn’t introduce feature creep into AuthTokenValidator.

I get what you’re saying but these little shortcuts (adding email sending in AuthTokenValidator) cause enormous tech debt later on when you scale.

Re: Software component names should be whimsical and cryptic

#179

Post by sidlls » Tue, Sep 13, 2022, 3:32 PM UTC

hbrn wrote: post #163

sebastos wrote: post #157

Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. 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…

> you are doing a bad job of producing an up-front system design 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.

It’s not “innovative” to double-down on mistakes.

Re: Software component names should be whimsical and cryptic

#180

Post by rcoveson » Tue, Sep 13, 2022, 3:33 PM UTC

sebastos wrote: post #157

Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. 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…

I can be dismissive of webdevs myself but this comment is too bitter for my taste. It sounds like you learned the salary of your greenhorn webdev nephew recently.

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.