length of name vs completeness capturing scope vs ignoring it (foo.foo_thing vs foo.thing) capturing type vs ignoring it (studentList vs students)

and so on. I often struggle with competing desires in naming. Code Complete dedicates an entire chapter to variable naming.

In the same vein, length of name vs abundance of other candidate tokens of the same length. By example, in C language, there are only 52 possible one-character names (26 if you stick to the convention of using only lower case characters), 5263 two-character names, 5263^2 three-character names, etc, etc.

It follows that shorter names should be reserved for more restricted scopes where additional context is available. i.e. the use of "i" and "j" as a conventional names for counters, "x" and "y" for arithmetic operands, and "N" for the number of elements in a collection is a good thing. On the other hand, the use of terse names like "atoi" in standard library is terrible, because its scope is in all existing programs (or at least in all C modules that directly or indirectly include stdlib.h

Picking takes time. It might be a small trade-off or you might be able to pay the cost only once by building up a habit of standardizing your variable names but still.

Picking variable names can definitely involve tradeoffs. For example, how long the variable name will be could be a tradeoff based on how much information the rest of your team has about the context in which the variable will be used. Do you need a variable to be very long so as to explicitly spell out a lot of details about itself? Is a very short name (such as i for iteration) acceptable in the current context?

Well, of course. But what is good? C.f. https://twitter.com/paskow/status/398811660057837568

I get the impression that the priority, among a large crowd here, is to say profound things rather than true things.