Against Names | Hacker News Reader

Against Names

steveklabnik.com

56 pointsthunderbong24 comments

In my experience, while naming things is certainly challenging, it’s a muscle you can flex. I find it much easier because I don’t go out of my way to avoid doing it. And I find colleagues who tend to struggle with naming are also those who tend to avoid the exercise.

Maybe not everyone gets the same benefit from the discipline as I do! It’s certainly possible. But I do have to wonder how much that’s the case.

I like the 2 examples. Tailwind has multiple traits that make it a winner, and I think that "never naming anything" is a secret super-power it has. You don't realize it, but it just makes coding easier over time. Compare to styled-components, which also has css-in-the-same-file-and-localized-context, the naming alone makes using it less productive.

For git, I'd never even considered it, but I often find myself renaming branches `thing-im-doing2` just because the first branch is broken, or having `abc-def` and `def-abc` branches accidentally...

The tooling needs to be wildly adopted though, and that's difficult. I gave up on graphite for exactly this reason.

I do the opposite and rename the current branch `thing-im-doing-borked` then fix it and reuse the old name with `git checkout -B thing-im-doing`.

I once had the questionable pleasure to write code in an environment where "at most one method call per statement" was strictly enforced. Had to constantly come up with names for intermediate values that would only get used once, in the very next statement.

It has kind of radicalized me against "pointless names". Names take up valuable space in the working memory of the reader. They need to carry their weight.

Not only that, but when you save something to a variable the reader needs to remember it in case you use that variable later again. For me personally that's exhausting.

I've seen streams-like code with a variable for almost every step, immediately used the line below. I can understand when the reason is to "explain" the meaning of the intermediate step...but even so a comment is far better on my opinion.

I always try to inline every 1-use variable/method, unless there is a good reason for not doing so.

I feel like Raymond Hettinger's guideline that line complexity should be scaled to the limitations of human working memory, so should be limited to 7(+/-2) tokens [0], is a good compromise. This leaves some margin for nesting, but keeps in mind the capacity of the human brain to understand what a line is doing. If you can explain what the line of code is doing in a single sentence, you can probably also find a way to either name the variable sensibly or factor the code so that your step is a (well-named) method instead.

[0] https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus...

It's much easier to work with source code where most things, including low-level details, have good names.

You only write code once, but if the software is long-lived, different people will read that code for years to come, doing support, maintenance, and adding features.

This is also one upside of functional programming over OOP that I think doesn't get mentioned often: No need for naming classes and stuff as inherent part of writing valid and structured code. It's part of the taxonomization issue.

By naming something, we make it a Thing. It forms a shape in our minds. However small, it has a history and a purpose. It has relationships to other Things. Its identity is now something we take custody of, by continuously interacting with it. This can help in the smaller context but does not scale.

One example is organization of e-mail. The traditional inbox approach makes you create folders. You have to give name and meaning to each of these. Organize them into trees of subfolders. Contrast this with the search-based approach popularized by Google and notmuch - tags/labels are optional but in general you have "an ocean of mail" which you search on an ad-hoc basis[0].

I think the OPs point can be taken further. That there's an inherent human instinct to want to name and create Things and that it's beneficial to be aware of and overcome this instinct.

I have a bunch of useful code and scripts spread across a couple of libraries. I could hypothetically break out anywhere from a handful to dozens of focused individual repos with a fancy Name. Make them into npm packages, give them each a logo, maybe even separate websites and chat rooms[1].

At the extreme, look at the pathological Clueless-driven big-tech with a gazillion Projects, Initiatives, Frameworks, Processes, Working Groups, Epics, Task Forces, Swim Lanes, continuously churning through birth and death. The meta-abstractions start to run the show.

[0]: I happen to prefer the mailbox approach myself! Of course the taxonization and structuring is not all bad - here the history and meaning is inherent and useful. My point is rather that it should be applied consciously. And in my mailbox, as opposed to in much of the software I write, the Things and their forms are entirely self-inflicted (hello NSA) and not something hoisted on the minds of others.

[1]: This is apparently fashionable recently among 10x Open Source GitHub Rock Stars. It's also particularly a disease in crypto with all these "Protocol"s each spawning their own fractal universe of Things.

> I have a bunch of useful code and scripts spread across a couple of libraries. I could hypothetically break out anywhere from a handful to dozens of focused individual repos with a fancy Name. Make them into npm packages

This is also an argument for micropackages, if done well. If you publish and import functions inpendently, there is no intermediary module and/or package. They are the same. This would need better platform integration to be something I'd argue for in practice, though.

I am definitly for names, and good names at that! Names are placeholders for a bunch of logic that you might not want to care about in the moment.

Without reading any code, you can tell what "inputToFocus", "postalCodeIsValid" and "daysToEarliestAppointment" mean. Then you know what this variable represents in the real world, and also what your code is operating on.

I also prefer CSS class names that describe what the object is (".alert-box.warning" or ".button.primary"), and not what it should look like. I don't like updating dozens of templates because I want to change how some things look across the website. I know that I won't forget to update one and create a hard-to-find bug.

The class attribute from HTML has about as much to do with CSS as the id attribute.

Those "CSS class names" are just HTML classes. They were invented for HTML, you write them in HTML, and they're part of the HTML spec.

It's become evident from comments on HN recently that people apparently think they're a CSS thing (because that's how they're taught CSS) but they're just an ordinary fixture of markup; they're for describing the class of something. Accordingly, stuff like class="alert-box warning" is the correct way to use classes (rather than e.g. class="3px-red-border" or whatever).

Do they have any other purpose besides CSS though? They were even hard to use as selectors in JS until querySelector appeared.

I'm not sure you're grokking what I'm saying. The answer to your question is "yes, of course". The class attribute has _nothing_ to do with CSS (or JS).

The CSS people didn't give us the class attribute (and the HTML people didn't put it in so that we could use CSS better). HTML had class attributes before CSS or JS ever existed.

I'm more on the extreme end of you can never name too much, as long as the names add more signal than noise, so I may be biased.

But I feel like the two examples given don't really support the case against.

In git, branches are close to meaningless. You can use git without branch names quite well, it's just not as nice of an experience as jj. The only thing you can not do in git without having a named branch (or rather a ref of some kind, does not have to be a branch) is moving commits between local and remote repository.

In git, branches are only meaningful – briefly – when communicating with other people, in which case naming them really matters! For your own temporary use, sure, don't name then. For me that's more of a flaw of git. In most git workflows you're meant to destroy history, so it doesn't matter that the branches are also destroyed, which again results in their names being meaningless. For things that are not throwaway I'll stand by putting as much effort into naming them as is needed.

Utility CSS classes are names. They're an API. Although I understand the reasoning, Tailwind is actually a perfect example of terrible naming. Everything has a single letter name or a name composed of initials. As a beginner you have absolutely no idea what you're reading, until you learn all the cryptic names. I'll restate that I understand why it is this way, but again for me it's a flaw of Tailwind and maybe utility classes in general.

Then there's the final example of lambda functions, where supposedly everyone accepts that naming isn't important. I think this one is the best example of why naming is important. If each step here had a proper name, you wouldn't have to write out what the function does, the code itself would explain it. If I don't trust it I can verify that the code the name is given to matches the name. Once I've verified it I can forget the code and substitute it with the idea of what it's supposed to do. Or if I don't want to verify it I can just trust the name and still understand what it's supposed to do.

Good naming helps readability tremendously for me. I don't have to spend any brain processing power on parsing that `.filter(|i| *i % 2 == 0)` means `filter even numbers`, I can just read it.

PS. Actually there are already two good names there: `into_iter()` and `sum()`. I don't need to know how they're implemented to understand what they're meant to do there. It's the lambda that's the problem and shows why naming is important.

This is why I love Ruby 2.7's numbered block parameters: https://rubyreferences.github.io/rubychanges/2.7.html#number...

I've always hated the pattern where you have to declare a throwaway param name within a block for cases where the `::Symbol#to_proc` syntax won't work, like when the method you're trying to call needs some argument. They usually end up as nonsense single-characters anyway so they may as well just be numbers I don't have to think about!

  irb(main):001> lol = [1337, 420, 69]
  => [1337, 420, 69]
  irb(main):002> lol.map(&:to_s)
  => ["1337", "420", "69"]
  irb(main):003> lol.map { |wow_this_sure_is_annoying| wow_this_sure_is_annoying.to_s(16) }
  => ["539", "1a4", "45"]
  irb(main):004> lol.map { _1.to_s(16) }
  => ["539", "1a4", "45"]

I find the post impossible to comprehend. I mean, I do not get the argumentation. Maybe because their examples don't use proper naming...?

The reason naming things is hard is because you don't know what you're doing and why. Once you've figured out the latter bits, the names just fall out simply and naturally. Naming things is among my favourite things as I'm getting better at knowing precisely what I'm doing and why.

This argument is ridiculous. Not having a name means you get even less information than even a mediocre name. I feel like we might be getting played here.

It's not a ridiculous argument! Not naming everything means that you can reserve naming things for when it actually makes a difference.

There are times when you don't need names, but most of the time you actually need names.

I don't understand this argument at all. It seems to reduce to "shorter, more human-readable hashes mean I can use hashes all the time instead of named branches." Which seems kind of beside the point. You need named branches for reference and for other humans to interact with.

Most times you don’t, though.

If I open a pull request on GitHub, the name of the branch is completely incidental. I already have textual descriptions for every commit. The pull request gets a title and a description. The branch name is there, but if it wasn’t (or if it was nonsense) don’t think anybody would notice. Once the branch is merged the branch name is lost to git. It might be recorded in the merge commit description but at that point it’s flavor text and not actually a pointer within git.

I have also fully converted to jj and yeah, it really does make you realize that branch names are often pointless for short-lived work in PR-based workflows.

It is lost to git if you delete the branch...

I think about naming of things all the time: how they make some things easier and other things absolutely awful. My two recent hang-ups: Agile with capital A. If we applied the principles of Agile without naming the process would software engineering be at a better place? I think there is a case to be made for not naming such things but just describe the principles of the process for a better, un-enshittified outcome.

The other is ROC (receiver operating characteristic) used in statistics and machine learning. The current usage is very divorced from its original meaning (related to radars as I understand) and it sounds very stupid when used in its current context. It is just a simple ratio of a few statistical measures. I think using such names actually makes things even less understandable.

On the other hand, definitions (ie, naming things) is very useful in math and other disciplines.

Reply on news.ycombinator.com