[HN Gopher] Against Names
___________________________________________________________________
Against Names
Author : thunderbong
Score : 37 points
Date : 2024-08-14 17:28 UTC (5 hours ago)
(HTM) web link (steveklabnik.com)
(TXT) w3m dump (steveklabnik.com)
| eyelidlessness wrote:
| 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.
| KerrAvon wrote:
| 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.
| stouset wrote:
| 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.
| Const-me wrote:
| 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.
| nichochar wrote:
| 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.
| nuancebydefault wrote:
| I find the post impossible to comprehend. I mean, I do not get
| the argumentation. Maybe because their examples don't use proper
| naming...?
| klauserc wrote:
| 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.
| TrianguloY wrote:
| 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.
| InitialLastName wrote:
| 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,_P
| lus...
| MzHN wrote:
| 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.
| wakawaka28 wrote:
| 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.
| thramp wrote:
| It's not a ridiculous argument! Not naming everything means
| that you can reserve naming things for when it _actually makes
| a difference_.
| karmakaze wrote:
| 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.
| 3np wrote:
| 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.
| 3np wrote:
| > 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.
| beryilma wrote:
| 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.
| nicbou wrote:
| 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.
| Lammy wrote:
| 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"]
___________________________________________________________________
(page generated 2024-08-14 23:01 UTC)