6 ms·

I think that the most important thing to understanding about naming is how it interacts with scope. Class names tend to be longer because there is no outer scop

I think that the most important thing to understanding about naming is how it interacts with scope. Class names tend to be longer because there is no outer scope (unless you have packages or namespaces). Likewise, single character names are fine in very localized contexts like this: users.map {|u| "(" + u.first_name + ")" } 'u' would be a very bad variable name in a broader context. Here, we can easily see it's a user.

choward 10y ago
"u" is a terrible variable name in that context also.
- burkaman 10y ago
  Why?
  - Larrikin 10y ago
    3 extra characters to make the variable user takes no time and makes the code clearer
    - conistonwater 10y ago
      Does it actually make the code clearer, though? If u is used as a temporary local variable meaning a user from users throughout the code, I think it's quite clear. Consistency seems like the important thing here.
      - choward 10y ago
        > If u is used as a temporary local variable meaning a user from users throughout the code Until it isn't. How do you enforce this? "Please use descriptive variables everywhere, except for when you are iterating over a list of users. Use "u" in that case. Thanks."
        icebraining 10y ago
        All names depend on context. "user" may or may not be description depending on the surrounding context. Single-letter variables are the same. Your own post provides good examples - you use "it" and "this" because, in context, they are clear and easier to write and read than a longer version.
        akavi 10y ago
        "Please use variable names that are more descriptive the larger the scope of their use is." When the scope is limited to a single line lambda, "first letter of the thing it is" is plenty descriptive enough, especially given that it's a strong convention in ruby. (In an example of the opposite extreme, I'm currently working int codebase where every non-function local/non-instance variable has to use its fully qualified path name. Extremely descriptive; extremely unreadable.)
        yongjik 10y ago
        In the same way you enforce anything else: common sense. The other direction is the same. If your team doesn't share a "common sense", then someone will end up writing value[axis_x][axis_y][axis_z], because single-letter names are prohibited.
- jng 10y ago
  I disagree. It is a great, clear, readable, succinct name, the same way that 'i' is a great name for an index in a loop, or i,j,k can be great names for nested indices. Einstein's multi-index notation was based in the same principles and works great in the contexts where it is used, the same that 'u' works great above.
  - choward 10y ago
    Why "u"? Why not "a"? Because "u" stands for "user"? Then make the variable "user" and don't add extra mental overhead for me when I read it.
    - pklausler 10y ago
      And then you have the similar names "user" and "users" present in the same scope. There's absolutely nothing wrong with single-letter variable names with miniscule scopes. (Well, never use lower-case 'l' for anything, but the rest are fine.)
      - choward 10y ago
        > And then you have the similar names "user" and "users" present in the same scope. So? They are different names and have different types. Maybe this is a ruby specific thing. Are you suggesting since "u" looks more different from "users" than "user", it's easier to tell it's a different type? Usually in non statically typed languages, I thought you make the variable more descriptive to make up for lack of types not less descriptive. For example: user_collection.each { |user| puts user.name }
        khedoros 10y ago
        Single letters for iteration values are a common convention in a number of languages. In the case of user/users, I'm likely to miss the distinction when scanning the code. If I've got a bunch of little lambdas, short loops (under 10 lines, perhaps), or list comprehensions, I'm not going to use longer names in them, because the context is clear and limited in scope. If the variable's got to stick around longer (like throughout a function/method), it'll get a more descriptive name. As the scope grows, the variable loses the context that it came from, and it's more likely to need a longer name to make its meaning clear.
- falsedan 10y ago
  I agree, they should have used '_'.
  - shmageggy 10y ago
    I disagree. In my experience, _ is used for assignments that will not be reused, basically throwaways. This is not one of those cases.
- dmansen 10y ago
  i'll take 'u' here any day. would never mistake it for anything else
GregBuchholz 10y ago
class Array def method_missing(m, *args, &block) self.map {|x| x.send(m)} end end users.first_name
- coderzach 10y ago
  using `x` as a variable name is not the reason this code is terrible.
mightybyte 10y ago
This. So much this. There are at least two reasons scope is important. First, the larger a name's scope, the more likely it is that short names will end up conflicting with other names at some point. Of course conversely, the smaller the scope is, the less likely it will conflict with something and the shorter you can make the name. And second, if the definition of something is a long ways away, then it becomes harder to find it to figure out the context. But in the example above, `u` has very small scope and its definition `users.map` is right there and makes it very easy to see what u stands for. It's also important to realize that long names have a cost. Above the obvious small cost of typing time, it is also harder to disambiguate them visually.
vorg 10y ago
> users.map {|u| "(" + u.first_name + ")" } If you need to specify the "u" in order to re-use it in one place only, then your language is syntactically challenged. Use a better language instead of caring about the names. A more flexible language would enable a predefined name like "it" or "_" instead, e.g: users.map{"(" + it.first_name + ")"} or even provide syntax to do common stuff, e.g. the asterix in: users*.{"(" + first_name + ")"}
- GregBuchholz 10y ago
  You may be interested in "Programming Shorthands" http://research.microsoft.com/apps/pubs/default.aspx?id=69746 http://research.microsoft.com/apps/pubs/default.aspx?id=6974... http://lambda-the-ultimate.org/node/2035 http://lambda-the-ultimate.org/node/2035
- kazinator 10y ago
  In a tight scope like this, `u` is the same thing as the classic "dummy variable", like the `i` in a for loop. "For a user u, do this". Dummy variables must never be given long names, because long names say, "this is not a dummy variable", which is a lie in that case.
- robwilliams 10y ago
  >Use a better language instead of caring about the names. That's not always an option. Also, I don't find the language OP linked syntactically challenged. C# has a similar syntax and it's much more readable than what you've provided: people.Sort(p => p.FirstName);

choward 10y ago

"u" is a terrible variable name in that context also.

burkaman 10y ago
Why?
- Larrikin 10y ago
  3 extra characters to make the variable user takes no time and makes the code clearer
  - conistonwater 10y ago
    Does it actually make the code clearer, though? If u is used as a temporary local variable meaning a user from users throughout the code, I think it's quite clear. Consistency seems like the important thing here.
    - choward 10y ago
      > If u is used as a temporary local variable meaning a user from users throughout the code Until it isn't. How do you enforce this? "Please use descriptive variables everywhere, except for when you are iterating over a list of users. Use "u" in that case. Thanks."
      - icebraining 10y ago
        All names depend on context. "user" may or may not be description depending on the surrounding context. Single-letter variables are the same. Your own post provides good examples - you use "it" and "this" because, in context, they are clear and easier to write and read than a longer version.
      - akavi 10y ago
        "Please use variable names that are more descriptive the larger the scope of their use is." When the scope is limited to a single line lambda, "first letter of the thing it is" is plenty descriptive enough, especially given that it's a strong convention in ruby. (In an example of the opposite extreme, I'm currently working int codebase where every non-function local/non-instance variable has to use its fully qualified path name. Extremely descriptive; extremely unreadable.)
      - yongjik 10y ago
        In the same way you enforce anything else: common sense. The other direction is the same. If your team doesn't share a "common sense", then someone will end up writing value[axis_x][axis_y][axis_z], because single-letter names are prohibited.
jng 10y ago
I disagree. It is a great, clear, readable, succinct name, the same way that 'i' is a great name for an index in a loop, or i,j,k can be great names for nested indices. Einstein's multi-index notation was based in the same principles and works great in the contexts where it is used, the same that 'u' works great above.
- choward 10y ago
  Why "u"? Why not "a"? Because "u" stands for "user"? Then make the variable "user" and don't add extra mental overhead for me when I read it.
  - pklausler 10y ago
    And then you have the similar names "user" and "users" present in the same scope. There's absolutely nothing wrong with single-letter variable names with miniscule scopes. (Well, never use lower-case 'l' for anything, but the rest are fine.)
    - choward 10y ago
      > And then you have the similar names "user" and "users" present in the same scope. So? They are different names and have different types. Maybe this is a ruby specific thing. Are you suggesting since "u" looks more different from "users" than "user", it's easier to tell it's a different type? Usually in non statically typed languages, I thought you make the variable more descriptive to make up for lack of types not less descriptive. For example: user_collection.each { |user| puts user.name }
      - khedoros 10y ago
        Single letters for iteration values are a common convention in a number of languages. In the case of user/users, I'm likely to miss the distinction when scanning the code. If I've got a bunch of little lambdas, short loops (under 10 lines, perhaps), or list comprehensions, I'm not going to use longer names in them, because the context is clear and limited in scope. If the variable's got to stick around longer (like throughout a function/method), it'll get a more descriptive name. As the scope grows, the variable loses the context that it came from, and it's more likely to need a longer name to make its meaning clear.
falsedan 10y ago
I agree, they should have used '_'.
- shmageggy 10y ago
  I disagree. In my experience, _ is used for assignments that will not be reused, basically throwaways. This is not one of those cases.
dmansen 10y ago
i'll take 'u' here any day. would never mistake it for anything else

GregBuchholz 10y ago

class Array def method_missing(m, *args, &block) self.map {|x| x.send(m)} end end users.first_name

coderzach 10y ago
using `x` as a variable name is not the reason this code is terrible.

mightybyte 10y ago

This. So much this. There are at least two reasons scope is important. First, the larger a name's scope, the more likely it is that short names will end up conflicting with other names at some point. Of course conversely, the smaller the scope is, the less likely it will conflict with something and the shorter you can make the name. And second, if the definition of something is a long ways away, then it becomes harder to find it to figure out the context. But in the example above, `u` has very small scope and its definition `users.map` is right there and makes it very easy to see what u stands for. It's also important to realize that long names have a cost. Above the obvious small cost of typing time, it is also harder to disambiguate them visually.

vorg 10y ago

> users.map {|u| "(" + u.first_name + ")" } If you need to specify the "u" in order to re-use it in one place only, then your language is syntactically challenged. Use a better language instead of caring about the names. A more flexible language would enable a predefined name like "it" or "_" instead, e.g: users.map{"(" + it.first_name + ")"} or even provide syntax to do common stuff, e.g. the asterix in: users*.{"(" + first_name + ")"}

GregBuchholz 10y ago
You may be interested in "Programming Shorthands" http://research.microsoft.com/apps/pubs/default.aspx?id=69746 http://research.microsoft.com/apps/pubs/default.aspx?id=6974... http://lambda-the-ultimate.org/node/2035 http://lambda-the-ultimate.org/node/2035
kazinator 10y ago
In a tight scope like this, `u` is the same thing as the classic "dummy variable", like the `i` in a for loop. "For a user u, do this". Dummy variables must never be given long names, because long names say, "this is not a dummy variable", which is a lie in that case.
robwilliams 10y ago
>Use a better language instead of caring about the names. That's not always an option. Also, I don't find the language OP linked syntactically challenged. C# has a similar syntax and it's much more readable than what you've provided: people.Sort(p => p.FirstName);