Just name your things as things. Name it Pluto, Calvin, Steve, Jon, Ted, Ann, Mobius, Orpheus, Martha, Alex... I don't care. Maybe even Tomato, Artichoke, Celery, Broccoli, Pumpkin, Rooibus etc... It just needs to be as neutral as possible.

This is the power of mathematics really. When I say "monoid" do you have any idea what it might be? No, well that's great, because here is a very formal definition of this thing called "monoid". Old school names like "group", "category" etc are worse. Names like "Kolmogorov complexity", "P-Complete", "Galois Field", "Ultrafilter" are much better.

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.

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.

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.

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

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.

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

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

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

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

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

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

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

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!

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

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.

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

In mathematics, things are never named "Steve".

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?

The problem wasn't lack of naming, it was incomplete defining of the thing. If it had a definition that everyone agreed upon, the name is arbitrary like naming of celestial bodies.

The other dimension implied here is the timing of when variety is introduced. If all the options were known when the system was originally designed, the issue may have been more clear. So then the other problem is that, when the need to distinguish between cases first came up, the solution was designed for only 2 cases. And if there were only ever those two cases, the solution presented would probably be the most efficient.

The solution to this incremental scope problem is a lot less clear to me and something I struggle with personally in scientific computing projects. When variety #2 pops up, how does one decide whether to restructure everything in case of a variety #3, or take the quicker (potentially more efficient) path and avoid unnecessary complexity? Assuming I've done as much as I can to anticipate and constrain my needed functionality. It somehow feels like I end up losing either way.

Short-answer rule-of-three (but really it depends).

I get what you mean, but this is more about implementation choices than identification of variety. Varieties can be grouped different ways that makes sense for implementation challenges or development timelines and later refactored to be more effective. The identification of the varieties themselves is distinct from the choice of grouping/implementation. Things that have little effect on behaviors (eg. color only affects one aspect of rendering) can be a property of a thing. More complex/varied characteristics may be better served by separating into distinct things.

Sometimes a 'bag of properties' can serve for all things (similar to JS Object). That's how I believe reddit's data model evolved at one time. I think HN isn't much different as it seems that id's of posts, comments, etc share numbering.

I ran into this same scenario talking about names for different states of inventory. Every person/company I talked to had different names or meanings of special 'reserved'/set-aside states. I kept telling everyone to define what they mean by that name, list the expected behaviors of it. Then it doesn't matter what anyone calls anything, I can match them up by properties/behaviors or find out they're distinct things.

Things became clear you can't trust names when I saw the formula: on-hand = available + unavailable + committed. Shouldn't available + unavailable form some complete total?

And there's your problem.

You could have separate entities for horses, donkeys, mules, zebras and functions that work on them. Maybe less code reuse but state is kept separately, code is very easy to understand, modify and implement. And also is faster to implement.

If you have too many ifs in some functions you have to ask yourself if you architected the code well.

    function neigh() { ... }

    class horse {
        method neigh() { ... }

    struct Horse {...}

    enum Quadruped {
        Horse(Horse),
        ...
    };

But the `if` blocks given as examples in that post make it clear that there is business logic that cares about something that is higher than just those booleans – logic that is based on some other identity or flag.

An `is_donkey` or `is_mule` flag isn't necessarily any better – if you're determining e.g. whether or not the animal can be used in dressage competitions, a `can_compete_in_dressage` boolean would be better than looking for `is_horse`, or God forbid `!is_short && sound === 'neigh' && !is_stubborn`

Know both approaches and use the one that results in a simpler system.

Write! That! Code! Twice! Then once you have more experience in the domain, you can refactor out the parts that are actually semantically identical. Code reuse should be proven, not a given.

Or, maybe this idiom (it's C++ but should apply to other languages with inheritance and virtual method equivalents, e.g. Java, C#). Why not something like this?

https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-Virtua...

Ah I was wondering where this was headed. It’s a bit disappointing to be honest. Such a build up for such an obvious conclusion.

Otherwise it feels like the real world. Start with ifs and refactor when you have too many of them…

.. there are fertile mules. Rare, but they exist.

While I agree with much of the sentiment about clear naming, I think that many languages with OO capabilities fail to provide easy to use role based composition at their peril. It is a big challenge to do wrestle real code and we need all the tools we can get.

Here's how it could look with roles at a coarse grain level:

---

role Breedable { ... }

role Feedable { method eat-carrot { ... } }

role Trainable { ... }

class Horse does Breedable does Feedable does Trainable { has $.sound = 'neigh'; ... }

class Donkey does Breedable does Feedable does Trainable { has $.sound = 'heehaw'; ... }

my $h = Horse.new(); $h.eat-carrot();

---

The benefit of roles is that they let you apply your human language skills (English, French, etc) to combine words as in natural languages - so roles are akin to Adjectives and classes to Nouns, and method names to Verbs.

With roles, you can avoid the temptation to hardwire inheritance:

---

class Donkey is Horse { ... }

---

And it leaves open the option for layers of specialization of roles like this:

---

role DonkeyTrainable does Trainable { ... }

class Donkey does Breedable does Feedable does DonkeyTrainable { ... }

---

And you can use inheritance and role composition side by side:

---

class Beast Breedable does Feedable does Trainable { ... }

class Horse is Beast { ... }

class Donkey is Beast { ... }

---

Here's what it says in the docs: _Roles are a collection of attributes and methods; however, unlike classes, roles are meant for describing only parts of an object's behavior; this is why, in general, roles are intended to be mixed in classes and objects. In general, classes are meant for managing objects and roles are meant for managing behavior and code reuse within objects._

btw these examples are in raku ... https://docs.raku.org/language/objects#Roles

https://docs.raku.org/language/typesystem#Auto-punning

Name different "things" differently!