5 ms·

Question to C programmers: Every time I encounter some C code, it doesn't take long until the obscurely short variable names start popping up from all direction

Question to C programmers: Every time I encounter some C code, it doesn't take long until the obscurely short variable names start popping up from all directions. Is naming variables in this manner considered acceptable by today's "C best practices" or what's the deal with that?

throwaway_exer 10y ago
K&R used short variable names, and C programmers are proud not be programming in Java, which encourages longer names. I personally think the variable name length should match the scope size, bu then I'm reasonable like that.
- shermanyo 10y ago
  > the variable name length should match the scope size Perfect summation, matches my thoughts.
csl 10y ago
Well, as long as the functions are short and the name is descriptive, I always use short names when the meaning is clear. For example strlower, you don't need more than `s` as the parameter name. It will probably be short, so using `len` or even just `l` for the string length should be fine for a ~15 line function. 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.
kzhahou 10y ago
Strangely, golang adopted this practice of very short variable names. Surprising since golang is so focused on clarity and readability.
- raverbashing 10y ago
  Exactly. The assumption that only long variables are readable is false
- msbarnett 10y ago
  Not surprising at all, if you're aware that Kernighan and Pike also wrote a book together (The Practice of Programming) in which they persuasively argued that brevity is an important component of clarity. Too much of "longer names are better" fetishism adds noise and detracts from overall clarity.
sklogic 10y ago
What's wrong with the short variable names? Did you ever encounter long variable names in any decent, readable mathematical paper or even a textbook?
- joesmo 10y ago
  When was the last time you read a math formula that was two million lines long? I don't see why short variable names would be better. With a proper editor you don't even save on typing and I've never seen code with short names that was easier to read than the same code with variable names of proper length that reflect their semantics (not necessarily long).
  - sklogic 10y ago
    When did you see a local context two millions lines long? 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.
  - jernfrost 10y ago
    When are you long variable name fanatics going to understand that it is NOT about typing ;-) It is in fact about READING! People who think longer is better simple do not have a insight into how the human brain process information. 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 I follow Rob Pike's advice and use long names for global and seldom used variables and functions while I use short names for locally defined variables and functions. I might also use short names for key concepts frequently used. If your key domain is geomtry then nobody will have problems understanding in context what: x, y, w, h, dx, dy etc means. You don't have to write XCoordinate, YCoordinate, Width, Height, DeltaX, DeltaY.
haberman 10y ago
Think of short variable names as pronouns. Like saying "it", except you have maybe 1-4 distinct "it"s. Short variable names work well for things that have common and obvious meanings. "i" for an iterator or loop index (add "j" and "k" if you have nested loops). "fd" for a file descriptor. "n" for a count of something. "p" for a pointer. "ofs" for an offset. Other conventions can apply within a codebase. 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); } ...which I think is pretty readable.
- forgotpwtomain 10y ago
  The prevalent opinion* is that it doesn't play well with existing standards to use `_t` in your own code, although personally I find an extension which tells me that it's a type to be very helpful. [0] http://stackoverflow.com/a/231807/3467349 http://stackoverflow.com/a/231807/3467349

throwaway_exer 10y ago

K&R used short variable names, and C programmers are proud not be programming in Java, which encourages longer names. I personally think the variable name length should match the scope size, bu then I'm reasonable like that.

shermanyo 10y ago
> the variable name length should match the scope size Perfect summation, matches my thoughts.

csl 10y ago

Well, as long as the functions are short and the name is descriptive, I always use short names when the meaning is clear. For example strlower, you don't need more than `s` as the parameter name. It will probably be short, so using `len` or even just `l` for the string length should be fine for a ~15 line function. 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.

kzhahou 10y ago

Strangely, golang adopted this practice of very short variable names. Surprising since golang is so focused on clarity and readability.

raverbashing 10y ago
Exactly. The assumption that only long variables are readable is false
msbarnett 10y ago
Not surprising at all, if you're aware that Kernighan and Pike also wrote a book together (The Practice of Programming) in which they persuasively argued that brevity is an important component of clarity. Too much of "longer names are better" fetishism adds noise and detracts from overall clarity.

sklogic 10y ago

What's wrong with the short variable names? Did you ever encounter long variable names in any decent, readable mathematical paper or even a textbook?

joesmo 10y ago
When was the last time you read a math formula that was two million lines long? I don't see why short variable names would be better. With a proper editor you don't even save on typing and I've never seen code with short names that was easier to read than the same code with variable names of proper length that reflect their semantics (not necessarily long).
- sklogic 10y ago
  When did you see a local context two millions lines long? 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.
- jernfrost 10y ago
  When are you long variable name fanatics going to understand that it is NOT about typing ;-) It is in fact about READING! People who think longer is better simple do not have a insight into how the human brain process information. 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 I follow Rob Pike's advice and use long names for global and seldom used variables and functions while I use short names for locally defined variables and functions. I might also use short names for key concepts frequently used. If your key domain is geomtry then nobody will have problems understanding in context what: x, y, w, h, dx, dy etc means. You don't have to write XCoordinate, YCoordinate, Width, Height, DeltaX, DeltaY.

haberman 10y ago

Think of short variable names as pronouns. Like saying "it", except you have maybe 1-4 distinct "it"s. Short variable names work well for things that have common and obvious meanings. "i" for an iterator or loop index (add "j" and "k" if you have nested loops). "fd" for a file descriptor. "n" for a count of something. "p" for a pointer. "ofs" for an offset. Other conventions can apply within a codebase. 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); } ...which I think is pretty readable.

forgotpwtomain 10y ago
The prevalent opinion* is that it doesn't play well with existing standards to use `_t` in your own code, although personally I find an extension which tells me that it's a type to be very helpful. [0] http://stackoverflow.com/a/231807/3467349 http://stackoverflow.com/a/231807/3467349