4 ms·

What's wrong with the long names. Or more importantl, at what point a name is too long?

klibertp 3y ago
When more than half of the words could be removed without losing much meaning, that's too long. And believe me, people actually write those. It's horrible. It's like those science guys who name every single variable x, but in reverse.
- godelski 3y ago
  I always think variables should be the minimal meaningfully unique identifier. We don't want to obscurificate code but we also want it to be readable. It's why we have style guides in the first place.
smt88 3y ago
Nothing is wrong with long names. Long names are good and serve as self-documentation. Some people are mad about that typing extra characters because they don't use their IDE properly to avoid it.
- vikingerik 3y ago
  The problem isn't about typing it, it's about readability, when the length starts to interfere with reading comprehension for maintainability. With more than three or four words, the brain can't easily tokenize it into a single unit or distinguish between similar phrases, and it starts to take a lot of extra mental processing time to scan and parse it all.
  - klibertp 3y ago
    You can cheat with underscores, though. Said another way, you can trick your brain into tokenizing the looooong input by using, as a convention, some kinds of separators. In Elisp, you'll see names-that::have-_a_field_name+in-it. (Because of lack of namespacing and loose syntax rules for identifiers). Even if you do, though, a bad long name is still bad (one with 50% words to be removed without losing the meaning). Because you loose time on sifting through irrelevant or redundant information. At some point, you'll remember and learn to recognize the whole symbol, or a distinct part of it. Until that happens, though, you need to actually read, not just look, to know what's going on. It's slow, like a cache miss, and can be slowed down further by both not enough information, and too much information.
    - godelski 3y ago
      You can, but why? There's a reason a lot of people prefer two column formats when writing as opposed to single. It is easier to grab a chunk. Your brain is now able to pick up the full width of a page without moving your eyes. Two column lets you change movements to a vertical scan rather than rasterization (left to right, move a line down, repeat). It literally requires more muscles and frankly, many people will accidentally move vertically when trying to move horizontally. I'm sure I'm not the only one who reads a line and then when moving down to the next line accidentally starts on the wrong new line. Horizontal spacing, be in variable names, code line length, etc is about the receptive field of your vision, which is circular in nature. Recognize how humans see and exploit that nature to maximize readability. This reduces mistakes and errors both when writing and reading.
      - klibertp 3y ago
        In Elisp, there's no other way, because you cannot create private symbols, everything is public and global. What's even worse is that in the case of name clash, the named entity (variable, function, macro) gets silently replaced with the new definition. So, without a convention of, roughly: package-name--private-function package-name-public-function package-name-class-name-_field_name You're playing with fire. But that's an extreme edge case. For other cases, I agree completely. Indeed, the only meaningful consideration when talking about readability is the mechanics of eye movement. You can get used to reading almost anything, but you can't change how your eye works. Line length limits are important also because of this, not only because of better diffs. I also dislike spamming newlines everywhere, as if the line length limit was 20 chars. The newline suggests, to me at least, that something was done and we're moving on. It's a weak signal, but convenient. Now, when you split every single object.call1().call2().callN() into multiple lines, it's actually harder to see the whole thing (you can't see much more than a few lines at the same time) and it makes that signal disappear in the noise. In any case - all talk about "readability" should start, and more importantly stop, at physical and mechanical limitations of human vision. Everything else is just familiarity with a particular notation or style.
- avgcorrection 3y ago
  If all the reasons that you can come up with for the opponent are wrong and misguided then your heuristics might be badly tuned.
- deleted 3y ago
  [deleted]
- godelski 3y ago
  > Some people are mad about that typing extra characters because they don't use their IDE properly to avoid it. I don't know a single person who thinks this way. As a vim user I've never typed all characters in a name (you don't need plugins). This isn't the 80's, everyone has autocomplete and uses it. I just don't want an ultrawide monitor to read your line of code.
godelski 3y ago
I still have a 80 character line guide. Not because I'm using punchcards but because it helps create readable code. It lets me know when to linebreak. No one wants to read a line of code where you have to scroll or where linebreaks are random. It's not a hard rule, but guides help. Side benefit is that with 80 characters I can usually fit 2 or 3 vertical splits and comfortably read the code, depending on the monitor size. May not be a direct answer to your question but I think it captures the spirit and reasoning.

When more than half of the words could be removed without losing much meaning, that's too long. And believe me, people actually write those. It's horrible. It's like those science guys who name every single variable x, but in reverse.

godelski 3y ago
I always think variables should be the minimal meaningfully unique identifier. We don't want to obscurificate code but we also want it to be readable. It's why we have style guides in the first place.

smt88 3y ago

Nothing is wrong with long names. Long names are good and serve as self-documentation. Some people are mad about that typing extra characters because they don't use their IDE properly to avoid it.

vikingerik 3y ago
The problem isn't about typing it, it's about readability, when the length starts to interfere with reading comprehension for maintainability. With more than three or four words, the brain can't easily tokenize it into a single unit or distinguish between similar phrases, and it starts to take a lot of extra mental processing time to scan and parse it all.
- klibertp 3y ago
  You can cheat with underscores, though. Said another way, you can trick your brain into tokenizing the looooong input by using, as a convention, some kinds of separators. In Elisp, you'll see names-that::have-_a_field_name+in-it. (Because of lack of namespacing and loose syntax rules for identifiers). Even if you do, though, a bad long name is still bad (one with 50% words to be removed without losing the meaning). Because you loose time on sifting through irrelevant or redundant information. At some point, you'll remember and learn to recognize the whole symbol, or a distinct part of it. Until that happens, though, you need to actually read, not just look, to know what's going on. It's slow, like a cache miss, and can be slowed down further by both not enough information, and too much information.
  - godelski 3y ago
    You can, but why? There's a reason a lot of people prefer two column formats when writing as opposed to single. It is easier to grab a chunk. Your brain is now able to pick up the full width of a page without moving your eyes. Two column lets you change movements to a vertical scan rather than rasterization (left to right, move a line down, repeat). It literally requires more muscles and frankly, many people will accidentally move vertically when trying to move horizontally. I'm sure I'm not the only one who reads a line and then when moving down to the next line accidentally starts on the wrong new line. Horizontal spacing, be in variable names, code line length, etc is about the receptive field of your vision, which is circular in nature. Recognize how humans see and exploit that nature to maximize readability. This reduces mistakes and errors both when writing and reading.
    - klibertp 3y ago
      In Elisp, there's no other way, because you cannot create private symbols, everything is public and global. What's even worse is that in the case of name clash, the named entity (variable, function, macro) gets silently replaced with the new definition. So, without a convention of, roughly: package-name--private-function package-name-public-function package-name-class-name-_field_name You're playing with fire. But that's an extreme edge case. For other cases, I agree completely. Indeed, the only meaningful consideration when talking about readability is the mechanics of eye movement. You can get used to reading almost anything, but you can't change how your eye works. Line length limits are important also because of this, not only because of better diffs. I also dislike spamming newlines everywhere, as if the line length limit was 20 chars. The newline suggests, to me at least, that something was done and we're moving on. It's a weak signal, but convenient. Now, when you split every single object.call1().call2().callN() into multiple lines, it's actually harder to see the whole thing (you can't see much more than a few lines at the same time) and it makes that signal disappear in the noise. In any case - all talk about "readability" should start, and more importantly stop, at physical and mechanical limitations of human vision. Everything else is just familiarity with a particular notation or style.
avgcorrection 3y ago
If all the reasons that you can come up with for the opponent are wrong and misguided then your heuristics might be badly tuned.
deleted 3y ago
[deleted]
godelski 3y ago
> Some people are mad about that typing extra characters because they don't use their IDE properly to avoid it. I don't know a single person who thinks this way. As a vim user I've never typed all characters in a name (you don't need plugins). This isn't the 80's, everyone has autocomplete and uses it. I just don't want an ultrawide monitor to read your line of code.

godelski 3y ago

I still have a 80 character line guide. Not because I'm using punchcards but because it helps create readable code. It lets me know when to linebreak. No one wants to read a line of code where you have to scroll or where linebreaks are random. It's not a hard rule, but guides help. Side benefit is that with 80 characters I can usually fit 2 or 3 vertical splits and comfortably read the code, depending on the monitor size. May not be a direct answer to your question but I think it captures the spirit and reasoning.