4 ms·

x is a variable name I still use quite a lot. Because it is quite meaningful as 'a meaningless parameter that is just a variable'. Same with y and z, though les

by rocqua 7y ago

x is a variable name I still use quite a lot. Because it is quite meaningful as 'a meaningless parameter that is just a variable'. Same with y and z, though less often. I'd also say that short names are sooner a product of line-length limitations than refactoring. Having to spread out every single statement over many lines because your reference a 12 character function 3 times in the same line and you are limited to 80 characters sucks.

elsurudo 7y ago
Point taken that it is ok to use i, x, y, z sometimes (eg. when iterating), but the notion 'a meaningless parameter that is just a variable' doesn't really exist... if it's meaningless, why are you saving it? Only other use case I can think of is doing metaprogramming or some sort of templating where you have a variable, but might no even know what it represents, because it isn't your concern.
- marcosdumay 7y ago
  > if it's meaningless, why are you saving it? Because you are writing abstract code. Odds are that a lot of your code is better done abstract, and only fully specified in a short context.
- mrgriffin 7y ago
  What about implementing something like map for lists? You know literally nothing about the values and the function except for their types. map :: (a -> b) -> [a] -> [b] map f [] = [] map f (a:as) = f a : map f as Personally I don't see any reason to use longer names than f, a, and as because you can't add any additional information. You might say "well I don't write code like that", and I don't have any answer for you. But I find I write a fair amount of generic code.
  - chalst 7y ago
    > you can't add any additional information Well you could... map transforming_function (element:rest_of_list) = transforming_function element : map transforming_function rest_of_list ...but the cost in terms of loss of brevity would far outweigh a benefit that would only accrue to complete beginners, who would be better served by comments and test cases.
- Firadeoclus 7y ago
  A variable can be a substitute for a longer expression for which a name/description is unnecessary because the expression itself is self-explanatory. The substitution with a (essentially meaningless) short name just makes repeated use of that expression more readable. Using a long, descriptive name would defeat the point.
mxschumacher 7y ago
Maybe it's also time to loosen the 80char limit a little bit, screen resolutions have advanced dramatically and large screens are commonplace. I'm not a fan of sacrificing readability for some arbitrary screen-width limitation. Going up to 100 or 120 is already sufficient
- Fnoord 7y ago
  You'd need to make a case of which value, and why, and why it is better, so that the terminals can standardize on it. I actually like the limitation, because it makes me use more enters, so that the information ends up not within one line but in multiple. Which mans more lines (and LOC) but better readability. I guess a good comparison is Twitter's limitation on the characters. It has its pros and cons.
- kbob 7y ago
  Contrariwise, I try to keep my code under 72 columns wide, and impose a hard limit at 80. Long lines are hard to read, no matter what screen they're on.

by rocqua 7y ago

elsurudo 7y ago

Point taken that it is ok to use i, x, y, z sometimes (eg. when iterating), but the notion 'a meaningless parameter that is just a variable' doesn't really exist... if it's meaningless, why are you saving it? Only other use case I can think of is doing metaprogramming or some sort of templating where you have a variable, but might no even know what it represents, because it isn't your concern.

marcosdumay 7y ago
> if it's meaningless, why are you saving it? Because you are writing abstract code. Odds are that a lot of your code is better done abstract, and only fully specified in a short context.
mrgriffin 7y ago
What about implementing something like map for lists? You know literally nothing about the values and the function except for their types. map :: (a -> b) -> [a] -> [b] map f [] = [] map f (a:as) = f a : map f as Personally I don't see any reason to use longer names than f, a, and as because you can't add any additional information. You might say "well I don't write code like that", and I don't have any answer for you. But I find I write a fair amount of generic code.
- chalst 7y ago
  > you can't add any additional information Well you could... map transforming_function (element:rest_of_list) = transforming_function element : map transforming_function rest_of_list ...but the cost in terms of loss of brevity would far outweigh a benefit that would only accrue to complete beginners, who would be better served by comments and test cases.
Firadeoclus 7y ago
A variable can be a substitute for a longer expression for which a name/description is unnecessary because the expression itself is self-explanatory. The substitution with a (essentially meaningless) short name just makes repeated use of that expression more readable. Using a long, descriptive name would defeat the point.

mxschumacher 7y ago

Maybe it's also time to loosen the 80char limit a little bit, screen resolutions have advanced dramatically and large screens are commonplace. I'm not a fan of sacrificing readability for some arbitrary screen-width limitation. Going up to 100 or 120 is already sufficient

Fnoord 7y ago
You'd need to make a case of which value, and why, and why it is better, so that the terminals can standardize on it. I actually like the limitation, because it makes me use more enters, so that the information ends up not within one line but in multiple. Which mans more lines (and LOC) but better readability. I guess a good comparison is Twitter's limitation on the characters. It has its pros and cons.
kbob 7y ago
Contrariwise, I try to keep my code under 72 columns wide, and impose a hard limit at 80. Long lines are hard to read, no matter what screen they're on.