3 ms·

If you use a decent IDE, having longer variable names is nearly no cost.

by danssig 15y ago

snprbob86 15y ago
I don't buy this argument, but you're in good company holding this belief. Generally, I find that long names fall into three categories: 1) refactoring opportunities Use more namespaces, write smaller functions, embrace lexical scoping, etc. You don't need to call something a foo-bar-frobber when it's being used in the foo-bar context, just call it a frobber. 2) line noise If you're only using the frobber within a two line function, and it is initialized via create-frobber, do you really need to spell it out? f or x will do. If your function grows, rename the variable. Or refactor! 3) an absentee synonym Maybe you've got a monster-which-attempts-to-defeat-player, when you really need a baddie. Or maybe the word you need doesn't exist yet? It's rare, but sometimes you really do need to invent or repurpose a word. ... I always feel dirty when I have a long variable name. pg writes about this in On Lisp: long names feel heavier. They might be super cheap to call, but because the name is long, you're less likely to call it. Furthermore, I much rather adhere to a line length limit, as I find wrapping lines far harder to read than lines with short variable names. Long names makes this harder. All that said, I almost never use abbreviations other than standin variables like a single letter. The only exception to this is well known abbreviations, like for your most commonly used utility functions or for objects which are extremely common in your problem domain. Such a set of abbreviations becomes a part of the language you share between your compiler and your team.
- gbog 15y ago
  What you say is true but only for variable names. Functions can have longer names, especially those called far away by some client code. For me the rule off thumb is that if you need a comment, you are better off with a longer name.
- lemming 15y ago
  f or x will do. If your function grows, rename the variable. Why would you just not give it a reasonable name to begin with? Why not call your variable frobber? The only possible reason for not doing so is that you're using an editor that makes you type it every single time. I insist that calling your Frobber variable frobber is strictly easier to understand than f or x. Why not t? Or sdfsdg? None of them make any sense to someone reading the code, and it increases the amount the reader of the code has to keep in their short-term memory, making it more challenging to understand. pg writes about this in On Lisp: long names feel heavier. They might be super cheap to call, but because the name is long, you're less likely to call it. Even if pg wrote it this is patently absurd, and it's endemic in lisp code which contributes greatly to the famously write-only nature of lisp. Again, if you're using a decent editor, there is no reason to call your UserDetails object anything but user-details (or maybe details if you're in a context only relating to users).
  - snprbob86 15y ago
    > The only possible reason for not doing so is that you're using an editor that makes you type it every single time. Here's some C: for (int player_index = 0; player_index < players.length; player_index++) { int rank = player_index + 1; render_score(rank, players[player_index].name); } Blah. So much for the brain to parse! for (int p = 0; p < players.length; p++) { int rank = p + 1; render_score(rank, players[p].name); } I find that much, much easier to parse in my head. The definition of p is available without any backtracking. The word "player" appears five fewer times, reducing confusion with the players array. This is a small case. If this code were to start to grow, and the definition of p and its usages start to grow appart, it's trivial to replace.... but it's probably better for you to refactor.
    - lemming 15y ago
      That's kind of a pathological case you have there - I don't think many people would argue that loop indices should have long variable names. None of the examples in your post above were loop variables, and what I see a lot of in lisp code is using ps for players, for example. In your example you've used pretty sensible names for players, rank and render_score - why not ps, r and rs respectively?
      - snprbob86 15y ago
        > why not ps, r and rs respectively? Um... Because that would be hard to read? I'm advocating using full words in general, avoiding long variables (multi-word phrases, adjectives, contextualization, etc), and not being afraid of short variables names if they help, rather than hurt readability. There are plenty of cases where short names are totally fine. If you've got a module full of string utilities and every single function takes a first argument of type String, why not just call it "s"? Everyone will figure it out in seconds and it will save the mental overhead of differentiating "String" and "string". when that does come up. Things like that; I'm saying use your judgement.
- danssig 15y ago
  >Use more namespaces, write smaller functions, embrace lexical scoping, etc. You don't need to call something a foo-bar-frobber when it's being used in the foo-bar context, just call it a frobber. I agree with this part and code this way. >line noise I generally follow this, it depends on how clear the abbreviation is. If I would need a comment I'll spell out the name instead. >I always feel dirty when I have a long variable name. Once it passes a certain size, I do too. >pg writes about this in On Lisp: long names feel heavier. This is something I strongly disagree with pg on and I would point to arch as prove that he's wrong here. Arch uses ridiculously short names for everything and I personally can't stand the language. As far as I can tell, the language never got popular despite a decent sized group of people waiting to see what pg would make. >They might be super cheap to call, but because the name is long, you're less likely to call it. I think pg arrives at this position because he uses vi. If you have a really nice IDE that does advanced code completion (e.g. I can type "RBV <tab>" for ReallyBigVariable) you'll find that you're no less likely to use a long variable or function name. >Furthermore, I much rather adhere to a line length limit, Agreed.
jmonegro 15y ago
That is true. When I do Objective-c using Xcode (glorious IDE), variable length is a non-issue. Ruby on TextMate is a different story, though.

If you use a decent IDE, having longer variable names is nearly no cost.

by danssig 15y ago

If you use a decent IDE, having longer variable names is nearly no cost.

I don't buy this argument, but you're in good company holding this belief. Generally, I find that long names fall into three categories: 1) refactoring opportunities Use more namespaces, write smaller functions, embrace lexical scoping, etc. You don't need to call something a foo-bar-frobber when it's being used in the foo-bar context, just call it a frobber. 2) line noise If you're only using the frobber within a two line function, and it is initialized via create-frobber, do you really need to spell it out? f or x will do. If your function grows, rename the variable. Or refactor! 3) an absentee synonym Maybe you've got a monster-which-attempts-to-defeat-player, when you really need a baddie. Or maybe the word you need doesn't exist yet? It's rare, but sometimes you really do need to invent or repurpose a word. ... I always feel dirty when I have a long variable name. pg writes about this in On Lisp: long names feel heavier. They might be super cheap to call, but because the name is long, you're less likely to call it. Furthermore, I much rather adhere to a line length limit, as I find wrapping lines far harder to read than lines with short variable names. Long names makes this harder. All that said, I almost never use abbreviations other than standin variables like a single letter. The only exception to this is well known abbreviations, like for your most commonly used utility functions or for objects which are extremely common in your problem domain. Such a set of abbreviations becomes a part of the language you share between your compiler and your team.

gbog 15y ago
What you say is true but only for variable names. Functions can have longer names, especially those called far away by some client code. For me the rule off thumb is that if you need a comment, you are better off with a longer name.
lemming 15y ago
f or x will do. If your function grows, rename the variable. Why would you just not give it a reasonable name to begin with? Why not call your variable frobber? The only possible reason for not doing so is that you're using an editor that makes you type it every single time. I insist that calling your Frobber variable frobber is strictly easier to understand than f or x. Why not t? Or sdfsdg? None of them make any sense to someone reading the code, and it increases the amount the reader of the code has to keep in their short-term memory, making it more challenging to understand. pg writes about this in On Lisp: long names feel heavier. They might be super cheap to call, but because the name is long, you're less likely to call it. Even if pg wrote it this is patently absurd, and it's endemic in lisp code which contributes greatly to the famously write-only nature of lisp. Again, if you're using a decent editor, there is no reason to call your UserDetails object anything but user-details (or maybe details if you're in a context only relating to users).
- snprbob86 15y ago
  > The only possible reason for not doing so is that you're using an editor that makes you type it every single time. Here's some C: for (int player_index = 0; player_index < players.length; player_index++) { int rank = player_index + 1; render_score(rank, players[player_index].name); } Blah. So much for the brain to parse! for (int p = 0; p < players.length; p++) { int rank = p + 1; render_score(rank, players[p].name); } I find that much, much easier to parse in my head. The definition of p is available without any backtracking. The word "player" appears five fewer times, reducing confusion with the players array. This is a small case. If this code were to start to grow, and the definition of p and its usages start to grow appart, it's trivial to replace.... but it's probably better for you to refactor.
  - lemming 15y ago
    That's kind of a pathological case you have there - I don't think many people would argue that loop indices should have long variable names. None of the examples in your post above were loop variables, and what I see a lot of in lisp code is using ps for players, for example. In your example you've used pretty sensible names for players, rank and render_score - why not ps, r and rs respectively?
    - snprbob86 15y ago
      > why not ps, r and rs respectively? Um... Because that would be hard to read? I'm advocating using full words in general, avoiding long variables (multi-word phrases, adjectives, contextualization, etc), and not being afraid of short variables names if they help, rather than hurt readability. There are plenty of cases where short names are totally fine. If you've got a module full of string utilities and every single function takes a first argument of type String, why not just call it "s"? Everyone will figure it out in seconds and it will save the mental overhead of differentiating "String" and "string". when that does come up. Things like that; I'm saying use your judgement.
danssig 15y ago
>Use more namespaces, write smaller functions, embrace lexical scoping, etc. You don't need to call something a foo-bar-frobber when it's being used in the foo-bar context, just call it a frobber. I agree with this part and code this way. >line noise I generally follow this, it depends on how clear the abbreviation is. If I would need a comment I'll spell out the name instead. >I always feel dirty when I have a long variable name. Once it passes a certain size, I do too. >pg writes about this in On Lisp: long names feel heavier. This is something I strongly disagree with pg on and I would point to arch as prove that he's wrong here. Arch uses ridiculously short names for everything and I personally can't stand the language. As far as I can tell, the language never got popular despite a decent sized group of people waiting to see what pg would make. >They might be super cheap to call, but because the name is long, you're less likely to call it. I think pg arrives at this position because he uses vi. If you have a really nice IDE that does advanced code completion (e.g. I can type "RBV <tab>" for ReallyBigVariable) you'll find that you're no less likely to use a long variable or function name. >Furthermore, I much rather adhere to a line length limit, Agreed.

jmonegro 15y ago

That is true. When I do Objective-c using Xcode (glorious IDE), variable length is a non-issue. Ruby on TextMate is a different story, though.