6 ms·

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

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
This is one of the main reasons I push people to pull out the thesaurus. You had an idea. You tried to put it into words, and either in your excitement or at a moment of frustration your brain latched onto one and it stuck, even if it’s not quite right, or only an archaic definition means what you meant. Often enough the thesaurus has a word that is closer to your notion, or several options that go different ways and you have to decide which you meant. As you say, once the word is picked it starts to influence the thing. If you pick a better word you get a better influence.
- wlamartin 4y ago
  https://relatedwords.org/ https://relatedwords.org/ is also pretty neat for this. It's slightly less strict than a thesaurus so it can aid in exploring the semantic space a bit more.
hansvm 4y ago
I like to avoid naming things in my programs to avoid baking in those sorts of assumptions. In short functions that can be as simple as choosing a name like "_", "x", or "rtn" to indicate to future me that the thing being described isn't super well defined and is only useful insofar as it lets the containing scope do what it's supposed to. In slightly longer sections of code I'll often just reference registers or memory offsets directly. You need some kind of identifier to access whatever it is you're working with, but if the name isn't pinned down well by English you might as well just pick your favorite number for the task. Names are important in places, but only if they aid understanding of the code rather than (intentionally or not) subverting the reader from details that do actually matter.

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

This is one of the main reasons I push people to pull out the thesaurus. You had an idea. You tried to put it into words, and either in your excitement or at a moment of frustration your brain latched onto one and it stuck, even if it’s not quite right, or only an archaic definition means what you meant. Often enough the thesaurus has a word that is closer to your notion, or several options that go different ways and you have to decide which you meant. As you say, once the word is picked it starts to influence the thing. If you pick a better word you get a better influence.

wlamartin 4y ago
https://relatedwords.org/ https://relatedwords.org/ is also pretty neat for this. It's slightly less strict than a thesaurus so it can aid in exploring the semantic space a bit more.

hansvm 4y ago

I like to avoid naming things in my programs to avoid baking in those sorts of assumptions. In short functions that can be as simple as choosing a name like "_", "x", or "rtn" to indicate to future me that the thing being described isn't super well defined and is only useful insofar as it lets the containing scope do what it's supposed to. In slightly longer sections of code I'll often just reference registers or memory offsets directly. You need some kind of identifier to access whatever it is you're working with, but if the name isn't pinned down well by English you might as well just pick your favorite number for the task. Names are important in places, but only if they aid understanding of the code rather than (intentionally or not) subverting the reader from details that do actually matter.