Hacker News Reader

Hard disagree.

Please everyone name it what it is, and don’t try to be coy or clever. Call it the metrics database, the example.com web service, the marketing tool, the data acquisition service, etc.

I really hate that most private code bases are named “Steve” or similar, in a sea of micro services with Stacey and Stans and then there’s Steve 2.0 projects, and the only thing they bothered to document in the readme is the origin story and maybe a cute meme picture to go with it. And all of those people are gone and I’m a new employee and it’s not funny anymore.

Everybody please just be serious, name it what it is, and document private business code like a professional. You’re getting paid so please take your job seriously.

And then the metrics database also stores the tracking timeline for physical deliveries, because the business decided that it had to cut corners and ship a feature urgently and they had just fired the CTO for standing up for quality engineering at the expense of velocity.

Names like "Steve" and "Pluto" take too long to type. Since the meanings are arbitrary anyway, you should just use A, B, C, etc.

If you have a need for more than 26 names, you can start to also use letter pairs.

For increased efficiency, a nightly job can compute the use-count of each referenced object, and assign it a new name according to an alphabetic Huffman code. This will minimize the amount of typing that developers have to waste their time doing.

Many languages also do allow Unicode, including emojis, so this opens up additional options which may stand out better visually.

I'm joking obviously. I think you should make an effort to give descriptive names to things, and that, as code changes, you should judiciously refactor and rename. An important purpose of code is to be read and to be understood.

However, unnecessary and impenetrable jargon can be useful for protecting a niche in an organization, just as languages incomprehensible to outsiders (say, Gaelic) can be useful in nationalist projects. When the hammer of Management comes down to say Thou Shalt Write it in Java, it is like L'Academie Francaise stamping out some dialect in the Pyrenees, or extending its influence over Algeria. So that can be a reason for choosing special names known only within your team, or for writing it in Haskell or Rust.

I once inherited a codebase that did this, and it was a nightmare to learn. All the classes were named after types of alcohol for some reason. Naming things clearly is really hard, but this approach is just giving up completely.

I wouldn't want that for my math scripts, either.

It needs the right balance. 95%+ of classes absolutely should not do this, but it's great for the handful of times when a class is complex, nuanced, and used prolifically.

Assuming good documentation, it just means a few extra minutes learning what some terms mean, and that's worth it in the long run in my experience.

> the handful of times when a class is complex, nuanced, and used prolifically

Is there a way to describe an example of such a class? That sounds like it could have a proper descriptive name, it'd just be a bit harder to come up with.

  SEND
  
  HAVE ISOLATED ORGANISM WISH CODING


  MESSAGE FROM CENTRAL CODES FOLLOWS
  
  OPENING NEW CATEGORY
  
  CODE FOR YOUR ORGANISM WILL BE ANDROMEDA
  
  CODE WILL READ OUT ANDROMEDA STRAIN
  
  END MESSAGE

>"name it Steve" philosophy

I think of these kinds of names as being like primary key fields in a database: Their main purpose is to distinguish the identities of various things, so it's better not to incorporate any functional/behavioural description into them because that way there's never a need to change the name in the future if the behaviour changes.

The downside is that the names become arbitrary lumps of data that you have to become familiar with by rote use.

Primary keys in DBs should be natural keys in the first place. You use surrogate keys only to optimize things.

So the whole analogy now points in the exact opposite direction as stated.

What's an example of a natural key for a person, that never changes?

In my company we resorted to name many internal tools and libs after birds.

It becomes a problem though when you want to publish open source tools or libraries. These days it becomes very hard to find a name that isn't already attached to a Github repo. Finding a name that is googlable, unique, somewhat intuitive and descriptive is a problem that does not scale at all.

I'm not surprised the NSA ended up generating names for their tools. At least that's what they seem to do judging by names like Eternal Blue, Double Pulsar, Dander Spritz and the like. (https://en.wikipedia.org/wiki/The_Shadow_Brokers#Fifth_leak:...)

In WW2, British intelligence analysts inferred that a secret Nazi radar system used only a single beam based on its code name: Wotan (Odin), a god with one eye. For a long time, I have occasionally referenced this example, but today I learned that it was actually sheer luck. The prior radar system that used two beams was also codenamed Wotan.

https://en.wikipedia.org/wiki/Battle_of_the_Beams#Y-Ger%C3%A...

Wasn't Eternal Blue a reference to the Windows "blue screen" bug it was based on?

I would guess there are also technical references in the other names.

To my knowledge the NSA never commented on this, so where is this information supposed to come from?

Nope! Things are never important... behaviour is!

And please, after 20+ years of DDD at least, give Evans some credit: name your things after your business domain...!

Well at the end of the day you will have to name your container, or instance, or server, or git repo, or db table etc... Conceptually I agree with you, behavior matters. But as the article details, when we communicate with humans, all we have is names, so we have to use names to communicate behavior.

> And please, after 20+ years of DDD at least, give Evans some credit: name your things after your business domain...!

This doesn't hold up in all companies. My company has more than 100 services (yeah yeah microservices suck yada yada, I don't make the decisions) you can't just name 150 things after your business domain, ultimately you're required to follow some kind of convention like "x {verb}er" etc.

>My company has more than 100 services (yeah yeah microservices suck yada yada, I don't make the decisions) you can't just name 150 things after your business domain

We did just that because each of our microservices does one thing. So we have Authorization, Notifications, Tenant, Workflow and so on.

Please never do that.

Think of how you would explain things to some external or new person. Compare:

"You need to tune Steve so Lily doesn't get stuck".

to

"You need to tune the data collection service so the object storage service doesn't get stuck".

The first proposed variant is just ridiculous! Whereas the second variant gives you a glimpse of what's going on.

For the exact same reason you should not call your identifiers in code "liz" or "bobo".

Name your things what they are!

You think ‘Galois field’ is better than ‘finite field’?

Both are arguably better than 'potato field'

But GP is actually arguing to call all your things "potato".

Imho that's the worst you could possibly do! Indeed.

Yes absolutely! As per my original comment neutral names are better. "Finite" has a meaning.

Yes — a meaning that fits. Since a finite field is, by definition, finite.

Why would having an entirely neutral name be better? A finite field isn’t a field that is in some sense finite or related to or inspired by finiteness in some mysterious way, it is quite literally finite (in the sense that all mathematicians use the word).

The danger of using existing terms like ‘category’ for new concepts is that they encourage the importation of lots of likely irrelevant associations and intuition that is likely to confuse rather than aid one’s understanding.

I definitely think your argument goes too far if you think the phrase ‘finite field’ is potentially misleading. You might as well demand that the phrase ‘multiples of 5’ be replaced with ‘fluffies’ because it has less meaning.

This is HN Big Brain approach to the problem of naming things.

Agreed. And might as well use one-syllable words that are pleasant to read / write (e.g. bob, tom, box, rack, sun).

The next thing you know your using joe[1] to write joe[2] in joe[3].

At work we have an app called "directly", and an app called "indirectly". Ask me if I ever have to clarify by asking "you mean in an indirect way, in the app indirectly or in the app directly?" (the answer is ALL THE TIME)

  1: the editor
  2: a service you created
  3: Joe-E the language

Just use less common names like Brice or Werner or Rubin?

My favorite thing is when names that I often have to communicate verbally for written use have ambiguous alternative spellings.

> This is the power of mathematics really.

In mathematics, things are never named "Steve".

Kingdom of nouns?

> This is the power of mathematics really.

I don't think your comparison makes sense. The power of the "name it Steve" philosophy is the same rationale behind adopting codename for projects: it helps create a context to disambiguate discussions. As part of Steve, you work on the Steve web app and on the Steve service. The Steve service later can be refactored to peel out one of Steve's microservices listening to Steve's message broker.

Later if Steve needs to consume data from Pluto, you know that Steve's service will chat with Pluto's service, and perhaps have Steve's message broker listen to some channels in Pluto's message broker, etc etc. Zero ambiguity.

Moreover, monoliths have a propensity to outgrow responsibility-driven names. With a monolith you might start with a widget service, which then handles transactions, inventory, and order history. Once any of those responsibilities is peeled off to a microservice, do you still have a widget service along with a widget inventory service? Is it ok to keep calling widget service the widget service if it only handles widget order history?