Short variable names work less well when you have more than about 4 of them in the same function/block or there is no common convention suggesting what the variable might be from its name alone.
Short variable names are also not good for globals or struct members, because those names are used across many contexts. Combine this convention with a short local variable name and you end up getting things like:
typedef struct {
int retry_count;
} connection_t;
// If "connection_t" is used widely throughout your codebase,
// you get used to seeing a variable "c" that is a connection.
void func(connection_t *c) {
fprintf(stderr, "Retry count: %d\n", c->retry_count);
}
I personally think the variable name length should match the scope size, bu then I'm reasonable like that.
Perfect summation, matches my thoughts.
A tip is to look at the function declaration in the header files. There I, at least, use somewhat longer parameter names for descriptive purposes (along with documentation) but usually use short ones in the function bodies.
So, if your functions are short and to the point (low coupling, high cohesion, in Coding Complete parlance), then I consider short parameter and variable names a good style. But it's just one ingredient in good code.
Unless you're looking at competitive programming, I feel the best programmers make clear code with short names.
Too much of "longer names are better" fetishism adds noise and detracts from overall clarity.
Read up on good user interface design. One of the key points is that texts should be short and the shape of words easily distinguishable. index1, index2, index3 might be more descriptive than i, j, k but the latter have more unique overall shape which makes it easier to identify for a reader. Likewise CoordinateX, CoordinateY, CoordinateZ is harder to read than x, y, z.
How do you like reading the line below: divideBy(multiply(rocketmass, multiply(rocketvelocity, rocketvelocity), 2)
compared to: (mv^2)/2
Sure the former describes what the individual variables are, but immediately getting an overview or sense of what is being calculated is harder. But using short variable names doesn't mean you can only use short names. You can mix and match to optimize understanding and clarity.
rocketKineticEnergy = (m*v^2)/2
... of course you do.
As long as variable scopes are kept tightly controlled, length of the overall code-base is irrelevant. Avoid "spooky action at a distance" and you never have to care that there's a variable named s instead of string_for_truncation_html_aware 500,000 lines away from the function in front of you.
I never seen a code with long local variable names that was not awful.
And it is not about typing. Long names harm reading in the first place.