5 ms·

> A C programmer would call that variable tmp, which is much easier to write, and not the least more difficult to understand. Yuck. Abbreviations are usually b

> A C programmer would call that variable tmp, which is much easier to write, and not the least more difficult to understand. Yuck. Abbreviations are usually bad. For one thing, people tend to pick different ways to abbreviate things so an hour later when you're trying to grep for where the variable was used you have to try to remember whether the variable was written tmp, temp, or temporary. In this example, "temporary" is probably the least useful thing to know about the variable, since most variables are temporary. How about "counter"?

quotemstr 9y ago
Short idioms are essential for concision in specific domains though. My favorite example: I was writing some graphics code recently, and some reviewer said: "I don't understand this uv abbreviation that appears all over the code. Please expand it." headdesk.gif (For those who aren't familiar: u and v are conventional names of texture coordinates, like x, y, and z are conventional names of spatial coordinates. There's no abbreviation to expand.)
- javajosh 9y ago
  I am sure you are right, but I can't figure out what "xy" would mean in a program, either. Perhaps all the points on a plane normal to z?
  - krylon 9y ago
    I used to use x and y as my generic loop iteration variables until I worked on code that involved two-dimensional coordinates, and suddenly x and y had very specific meaning. I skipped to i and j, but I am certain there are mathematicians out there who find that confusing, too. I guess, it's about context, too, at least a little.
    - lomnakkus 9y ago
      > I skipped to i and j, but I am certain there are mathematicians out there who find that confusing, too. IME it's pretty standard in most of mathematics to use "i" and "j" as index variables when e.g. doing sums and products over indices/sets. (Though I suppose you could be talking about the use of i, j, k as axes?)
      - krylon 9y ago
        I think in Quaternions, i, j, and k are the non-real components.
        lomnakkus 9y ago
        Good point, I'd missed that one! :) What does one for index variables in that notation? Or is the main point of q notation that you don't need index variables? ;)
steveklabnik 9y ago
In some sense this is true, but also, I strongly prefer Arc<T> to AtomiclyReferenceCounted<T>. It's all about knowing what should be abbreviated and what shouldn't.
- chimprich 9y ago
  I think abbreviations make sense if the abbreviation is better known than the full name, or if it's standard jargon in the problem domain, or it's used so frequently in the program that it can be considered a convention. But using abbreviations just to save some typing makes life difficult for newcomers to a project and can be a source of bugs.
kevhito 9y ago
Not really. Go also encourages short, concise names, and it seems to work pretty well... or at least not be causing significant headaches so far as I can tell. Why would one be forgetting and grepping for tmp? That's the kind of variable that would be inside a function (so max one or two screenfuls, according to the guidelines here), and more realistically would usually be declared and used entirely within the same block of a dozen or so lines of code. Nobody is going to forget whether it is temp or temp while reading those 12 lines of code. And using temporary is just silly -- I can't think of a single time I've ever seen that used in any language.
- chimprich 9y ago
  Maybe grepping for the variable is a bad example. I have seen bugs where a variable has been accidentally defined twice though due to inconsistent abbreviations. I'm struggling to think of any case where "tmp" couldn't be replaced by a better name. It's always going to be a temporary something. I'm not arguing against short, concise names where they won't cause problems. Variable names of e.g. x, y, i all have their place.
ams6110 9y ago
You should not need to grep for the local temporary variable, whether it's named tmp or temp or anything else -- because it should be right there in front of you since your functions should not be more than about a screen page in length. If you have a variable tmp that's defined 6 pages back or worse, is global -- consider refactoring first, not just a more descriptive name.

quotemstr 9y ago

Short idioms are essential for concision in specific domains though. My favorite example: I was writing some graphics code recently, and some reviewer said: "I don't understand this uv abbreviation that appears all over the code. Please expand it." headdesk.gif (For those who aren't familiar: u and v are conventional names of texture coordinates, like x, y, and z are conventional names of spatial coordinates. There's no abbreviation to expand.)

javajosh 9y ago
I am sure you are right, but I can't figure out what "xy" would mean in a program, either. Perhaps all the points on a plane normal to z?
- krylon 9y ago
  I used to use x and y as my generic loop iteration variables until I worked on code that involved two-dimensional coordinates, and suddenly x and y had very specific meaning. I skipped to i and j, but I am certain there are mathematicians out there who find that confusing, too. I guess, it's about context, too, at least a little.
  - lomnakkus 9y ago
    > I skipped to i and j, but I am certain there are mathematicians out there who find that confusing, too. IME it's pretty standard in most of mathematics to use "i" and "j" as index variables when e.g. doing sums and products over indices/sets. (Though I suppose you could be talking about the use of i, j, k as axes?)
    - krylon 9y ago
      I think in Quaternions, i, j, and k are the non-real components.
      - lomnakkus 9y ago
        Good point, I'd missed that one! :) What does one for index variables in that notation? Or is the main point of q notation that you don't need index variables? ;)

steveklabnik 9y ago

In some sense this is true, but also, I strongly prefer Arc<T> to AtomiclyReferenceCounted<T>. It's all about knowing what should be abbreviated and what shouldn't.

chimprich 9y ago
I think abbreviations make sense if the abbreviation is better known than the full name, or if it's standard jargon in the problem domain, or it's used so frequently in the program that it can be considered a convention. But using abbreviations just to save some typing makes life difficult for newcomers to a project and can be a source of bugs.

kevhito 9y ago

Not really. Go also encourages short, concise names, and it seems to work pretty well... or at least not be causing significant headaches so far as I can tell. Why would one be forgetting and grepping for tmp? That's the kind of variable that would be inside a function (so max one or two screenfuls, according to the guidelines here), and more realistically would usually be declared and used entirely within the same block of a dozen or so lines of code. Nobody is going to forget whether it is temp or temp while reading those 12 lines of code. And using temporary is just silly -- I can't think of a single time I've ever seen that used in any language.

chimprich 9y ago
Maybe grepping for the variable is a bad example. I have seen bugs where a variable has been accidentally defined twice though due to inconsistent abbreviations. I'm struggling to think of any case where "tmp" couldn't be replaced by a better name. It's always going to be a temporary something. I'm not arguing against short, concise names where they won't cause problems. Variable names of e.g. x, y, i all have their place.

ams6110 9y ago

You should not need to grep for the local temporary variable, whether it's named tmp or temp or anything else -- because it should be right there in front of you since your functions should not be more than about a screen page in length. If you have a variable tmp that's defined 6 pages back or worse, is global -- consider refactoring first, not just a more descriptive name.