6 ms·
"u" is a terrible variable name in that context also.
by choward 10y ago
"u" is a terrible variable name in that context also.
- burkaman 10y agoWhy?
- Larrikin 10y ago3 extra characters to make the variable user takes no time and makes the code clearer
- conistonwater 10y agoDoes 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 agoAll 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 agoIn 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 agoI 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 agoWhy "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 agoAnd 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 agoSingle 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 agoI agree, they should have used '_'.
- shmageggy 10y agoI disagree. In my experience, _ is used for assignments that will not be reused, basically throwaways. This is not one of those cases.
- dmansen 10y agoi'll take 'u' here any day. would never mistake it for anything else