5 ms·

Naming Things Is Hard

47 points by Liriel 4y ago

chmaynard 4y ago
Or as paraphrased by Jeff Atwood: There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
- nine_k 4y ago
  "There are two hard problems in computer science: that we have only one joke, and that the joke is not very funny" (q)
  - whartung 4y ago
    "Now, you have two problems."
- drawkbox 4y ago
  Naming is so key to getting the right vibe for a feature/product/codebase. This is a perfect encapsulation of the feeling when naming a variable: https://twitter.com/jenmsft/status/1381006038590099456?lang=en https://twitter.com/jenmsft/status/1381006038590099456?lang=...
  - btschaegg 4y ago
    The irony here: In my experience, if that's the face you make while naming a variable, you're probably good. What always gets me is code written by someone who just goes "well, there's already `process`, so let's call this method `process2`".
    - karmakurtisaani 4y ago
      Yeah that's infuriating. Clearly the proper naming is newProcess.
      - RedShift1 4y ago
        That's old new. New new is ReduxProcess.
shay_ker 4y ago
This is more than just naming things. It’s also that Ruby allows you to monkeypatch _any_ method, even if it’s a Kernel method or already defined by a library or framework (like Rails). It’s extremely powerful, which is great! But I want a linter that tells me, “Hey - you’re monkeypatching that. I’m going to fail this build unless you explicitly indicate you know what you’re doing”. I don’t know of a convincing linter that has a complete solution to this. Feel free to chime in if you know of one! I’m guessing this is possible in Rubinius, but not sure about the standard Ruby VM.
- drewcoo 4y ago
  This is way off-topic, but . . . You can create a Rubocop check that will complain abuot method_added and method_undefined. And to show that you know that you're calling them even though they're forbidden, just make a comment to tell Ruboocop to ignore. And make sure commits are code-reviewed, of course. What more could you want?
AlbertCory 4y ago
How many people know (as I didn't) that this Phil Karlton is the son of a Phil Karlton (RIP) who worked at Xerox back in the day? Phil was killed in an auto accident in Italy, as I recall. I thought he was one of the authors of this: https://www.cs.unm.edu/~cris/481/redell-pilot.pdf https://www.cs.unm.edu/~cris/481/redell-pilot.pdf but apparently not.
sublinear 4y ago
This may be true in specific cases such as dealing with legacy APIs that cannot be namespaced, or what's being shown in the article. Otherwise I've far too often heard this excuse to justify poorly written code in dire need of a refactor.
ineptech 4y ago
This doesn't really touch on what I think of when I think of "naming things is hard", which is not really technical or language-specific so much as semantic. When you name an abstraction (object, enum value, function name, etc) you are baking in assumptions about that abstraction that may not make sense a few years down the line. When the user connects to the websocket server, is that a Connection or a Socket or a SocketConnection or what? If they disconnect and reconnect, is that a Connection with two Sessions, or a Session with two Connections, or something else? Can a Connection be disconnected? Etc. Maybe those aren't great examples, but the point is, I think the problem of finding names that accurately convey the right mental picture of what the underlying abstraction is intended to do is much, much harder than just trying to avoid conflicts with names of builtins. Particularly when the app changes over time and those abstractions evolve to be used in subtly different ways the programmer didn't foresee.
- jackblemming 4y ago
  >Connection or a Socket or a SocketConnection or what? I’d say provide as much context as you feel appropriate and iterate if it’s too much or too little. That’s the problem, many developers are terrified of renaming things as they learn more. Renaming is only an issue if you have many external consumers depending on you. >Particularly when the app changes over time and those abstractions evolve to be used in subtly different ways the programmer didn't foresee. Perfect abstractions never go stale, they just become obsolete. TCP/UDP are timeless. Quicksort and hash tables are timeless. They are never renamed or changed. You may swap them out as necessary, but they’re complete. The issue arises when people put too many responsibilities or contexts onto an existing thing. This manifests itself as objects with hundreds of properties or functions with dozens of Boolean flags to toggle on or off contexts. It’s a sad thing indeed.
  - leni536 4y ago
    Funny you mention quicksort, as qsort in libc is not guaranteed to be implemented by quicksort. So that's an other poor naming.
- hinkley 4y ago
davidmurdoch 4y ago
Had to deal with level db dependencies in JS today... they had a VERY hard time naming packages: level, leveldb, leveldown, levelup, sublevel, subleveldown, abstract level, abstract leveldown, encoding down, classic level, level codec, memdown, memory level, ...
- smitty1e 4y ago
  Today's hairball was an approved AMI for the project whose environment is so old that a newly-installed node.js binary barfed on /lib64/libc.so.6 symbols. Couldn't even compile node.js from source, because said tool chain was three GCC point versions too old. [sigh goes here]
- evansmidwa 4y ago
  lots of creativity there
- barbarbar 4y ago
  That takes naming to a whole new level...
smitty1e 4y ago
> Ruby on Rails follows the paradigm of Convention Over Configuration, that means that, if we name things in specific ways, and put things in specific places, the framework will do its “magic” and we’ll have all the good benefits. > This is really powerful, it enables us to write less code and get a lot of functionality for free. It’s one of the reasons why Rails makes building new apps so easy. > But again, there’s a catch here and we have to be careful, conventions are great but we can get unexpected behaviors if we don’t know them. Indeed, at this point the framework is tantamount to a language unto itself. See also PHP vs. WordPress. Further still, we get into IDEs that take over the situation, e.g. Eclipse vs. IntelliJ. Not only do we have to fret the Java distribution, but have to deal with the tooling for editing/building the code. Nor does the problem seem to improve over time, except through one's retirement.
deleted 4y ago
[deleted]
yCombLinks 4y ago
I've found the hard part is coming up with a good abstraction or domain model, once you have that the names are obvious. Conflicts with keywords seems minor in comparison
asah 4y ago
Crazy idea: could there be a neural net to help naming ? Ideally, it looks at your code and your makeshift name, and suggests other names to consider.
tempxyz 4y ago
First heard it from a CS professor that it was the hardest problem in computer science.

47 points by Liriel 4y ago

Or as paraphrased by Jeff Atwood: There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

nine_k 4y ago
"There are two hard problems in computer science: that we have only one joke, and that the joke is not very funny" (q)
- whartung 4y ago
  "Now, you have two problems."
drawkbox 4y ago
Naming is so key to getting the right vibe for a feature/product/codebase. This is a perfect encapsulation of the feeling when naming a variable: https://twitter.com/jenmsft/status/1381006038590099456?lang=en https://twitter.com/jenmsft/status/1381006038590099456?lang=...
- btschaegg 4y ago
  The irony here: In my experience, if that's the face you make while naming a variable, you're probably good. What always gets me is code written by someone who just goes "well, there's already `process`, so let's call this method `process2`".
  - karmakurtisaani 4y ago
    Yeah that's infuriating. Clearly the proper naming is newProcess.
    - RedShift1 4y ago
      That's old new. New new is ReduxProcess.

shay_ker 4y ago

This is more than just naming things. It’s also that Ruby allows you to monkeypatch _any_ method, even if it’s a Kernel method or already defined by a library or framework (like Rails). It’s extremely powerful, which is great! But I want a linter that tells me, “Hey - you’re monkeypatching that. I’m going to fail this build unless you explicitly indicate you know what you’re doing”. I don’t know of a convincing linter that has a complete solution to this. Feel free to chime in if you know of one! I’m guessing this is possible in Rubinius, but not sure about the standard Ruby VM.

drewcoo 4y ago
This is way off-topic, but . . . You can create a Rubocop check that will complain abuot method_added and method_undefined. And to show that you know that you're calling them even though they're forbidden, just make a comment to tell Ruboocop to ignore. And make sure commits are code-reviewed, of course. What more could you want?

AlbertCory 4y ago

How many people know (as I didn't) that this Phil Karlton is the son of a Phil Karlton (RIP) who worked at Xerox back in the day? Phil was killed in an auto accident in Italy, as I recall. I thought he was one of the authors of this: https://www.cs.unm.edu/~cris/481/redell-pilot.pdf https://www.cs.unm.edu/~cris/481/redell-pilot.pdf but apparently not.

sublinear 4y ago

This may be true in specific cases such as dealing with legacy APIs that cannot be namespaced, or what's being shown in the article. Otherwise I've far too often heard this excuse to justify poorly written code in dire need of a refactor.

ineptech 4y ago

This doesn't really touch on what I think of when I think of "naming things is hard", which is not really technical or language-specific so much as semantic. When you name an abstraction (object, enum value, function name, etc) you are baking in assumptions about that abstraction that may not make sense a few years down the line. When the user connects to the websocket server, is that a Connection or a Socket or a SocketConnection or what? If they disconnect and reconnect, is that a Connection with two Sessions, or a Session with two Connections, or something else? Can a Connection be disconnected? Etc. Maybe those aren't great examples, but the point is, I think the problem of finding names that accurately convey the right mental picture of what the underlying abstraction is intended to do is much, much harder than just trying to avoid conflicts with names of builtins. Particularly when the app changes over time and those abstractions evolve to be used in subtly different ways the programmer didn't foresee.

jackblemming 4y ago
>Connection or a Socket or a SocketConnection or what? I’d say provide as much context as you feel appropriate and iterate if it’s too much or too little. That’s the problem, many developers are terrified of renaming things as they learn more. Renaming is only an issue if you have many external consumers depending on you. >Particularly when the app changes over time and those abstractions evolve to be used in subtly different ways the programmer didn't foresee. Perfect abstractions never go stale, they just become obsolete. TCP/UDP are timeless. Quicksort and hash tables are timeless. They are never renamed or changed. You may swap them out as necessary, but they’re complete. The issue arises when people put too many responsibilities or contexts onto an existing thing. This manifests itself as objects with hundreds of properties or functions with dozens of Boolean flags to toggle on or off contexts. It’s a sad thing indeed.
- leni536 4y ago
  Funny you mention quicksort, as qsort in libc is not guaranteed to be implemented by quicksort. So that's an other poor naming.
hinkley 4y ago

davidmurdoch 4y ago

Had to deal with level db dependencies in JS today... they had a VERY hard time naming packages: level, leveldb, leveldown, levelup, sublevel, subleveldown, abstract level, abstract leveldown, encoding down, classic level, level codec, memdown, memory level, ...

smitty1e 4y ago
Today's hairball was an approved AMI for the project whose environment is so old that a newly-installed node.js binary barfed on /lib64/libc.so.6 symbols. Couldn't even compile node.js from source, because said tool chain was three GCC point versions too old. [sigh goes here]
evansmidwa 4y ago
lots of creativity there
barbarbar 4y ago
That takes naming to a whole new level...

smitty1e 4y ago

> Ruby on Rails follows the paradigm of Convention Over Configuration, that means that, if we name things in specific ways, and put things in specific places, the framework will do its “magic” and we’ll have all the good benefits. > This is really powerful, it enables us to write less code and get a lot of functionality for free. It’s one of the reasons why Rails makes building new apps so easy. > But again, there’s a catch here and we have to be careful, conventions are great but we can get unexpected behaviors if we don’t know them. Indeed, at this point the framework is tantamount to a language unto itself. See also PHP vs. WordPress. Further still, we get into IDEs that take over the situation, e.g. Eclipse vs. IntelliJ. Not only do we have to fret the Java distribution, but have to deal with the tooling for editing/building the code. Nor does the problem seem to improve over time, except through one's retirement.

deleted 4y ago

[deleted]

yCombLinks 4y ago

I've found the hard part is coming up with a good abstraction or domain model, once you have that the names are obvious. Conflicts with keywords seems minor in comparison

asah 4y ago

Crazy idea: could there be a neural net to help naming ? Ideally, it looks at your code and your makeshift name, and suggests other names to consider.

tempxyz 4y ago

First heard it from a CS professor that it was the hardest problem in computer science.