[finishingmove]

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?

[haberman]

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]

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

[throwaway_exer]

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]

> the variable name length should match the scope size

Perfect summation, matches my thoughts.

[csl]

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]

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

[raverbashing]

Exactly. The assumption that only long variables are readable is false

[msbarnett]

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]

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]

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).

[jernfrost]

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.

[joesmo]

Maybe if you read my post, you'd see that I specifically mention "variable names of proper length that reflect their semantics (not necessarily long)," so I don't really appreciate being called a "long variable fanatic." I'm asking what the advantage is outside of loop variables which is everyone's favorite example because they can't find any better. Also, outside of geometry or other mathematics fields as most apps are not in that field. I find variable names that are actual, non-abbreviated words easier to read. What are you going to tell me next, that I don't know what's easier for me to read? Oh wait, you just did. Thank you for your condescending manner.

[serge2k]

> I follow Rob Pike's advice

... of course you do.

[msbarnett]

What code are you reading that variables have scope covering millions of lines of code? That's appalling.

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.

[sklogic]

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.

[bobbytherobot]

I've encountered short variable names in many hard to read mathematical papers.