Well-known abbreviations are fine, like "iter" and "prev", but single-letter variable names notoriously impede readability for me.
If the name is more than a few characters long, it starts to become non-instantaneous to recognize it. Things get much easier to follow with visually-instantly-recognizable symbols.
So in conditions where a variable is used over a short area in the code (or where it's used _constantly_ over a wide area), I prefer short variables.
id identifier
i loop counter
j inner loop counter
c general purpose non loop counter
a, b, comparator methods
k, v, key value setters, array iteration
e, event, error or exception. Contextual rule but rarely collides.
Other than those I pretty much always write entire full word names. If it's abbreviated or shorthand it likely sounds funny in my head, or it leads to ambiguation. If I need to even ask / recall for a split second it's not good enough.
Programmers incorrectly place far too much weight on time to type. I write like ten lines of code on a good day. It's just not important. I want readable code that is clear and concise as possible. Every branch, block or shorthand variable raises a question I have to think about before moving on.
Clever code is why I call ten lines of code a good day. It sure as shit isn't my typing speed.
If it's less "boilerplate" code, I'd go for more descriptive names. I think.
I like the sorta described "rule" in this document; the longer the variable is used, the more descriptive it should be.
As an extreme example, scalaz is similarly a very specialized DSL. Or in my personal experience, functional constructions like map, flatMap, foldLeft and reduce (which I never learned in school).
Up to four or five single letter variables is pretty trivial to remember. Especially when three of those are i, j, and k. More than 6 or 7 rapidly becomes painful. But if you are manipulating 6 or 7 variables _in the same scope_ you are doing to much.
I also agree with Pikes comments about typography here: http://doc.cat-v.org/bell_labs/pikestyle
Also names vary with there contextual scope. Larger scopes mean longer names generally. Russ Cox gives a succinct description here: https://research.swtch.com/names
A name's length should not exceed its information content.
For a local variable, the name i conveys as much information as
index or idx and is quicker to read. Similarly, i and j are a
better pair of names for index variables than i1 and i2
(or, worse, index1 and index2), because they are easier to
tell apart when skimming the program. Global names must convey
relatively more information, because they appear in a larger
variety of contexts. Even so, a short, precise name can say more
than a long-winded one: compare acquire and take_ownership.
Make every name tell.
This is only true because i is a specific, common abbreviation for index. When writing arbitrary glue code, a single letter variable would be a meaningless abbreviation without shared context. If you encounter "i" and it doesn't mean "index of a for loop", you're going to be taking additional time parsing meaning.
`usersList.stream().forEach(u -> someSet.add(u))`
It's immediately obvious that u is a user in usersList. I realize that it's debatable if u is really more readable than spelling out user, but I prefer it, and I don't think anyone is going to be confused by it. If the chain does get really long, also, I will spell it out explicitly.
For Javascript at least that would work.
`usersList.stream().forEach(someSet::add)`
Many times your function should be longer, rather than shorter.
Short methods and functions used just for the sake of being short just move the complexity of understanding in the interaction between them, making logic harder to follow an algorithm when it could have been all in the same place (for related functionality of course, I don't advocate having a function do 2 different irrelevant things).
Yeah, I noticed that for myself, too. so instead of i I might use frame_index, or whatever it "actually is". Up to a certain length it seems faster to just read what is there, without an additional mental translation step. But to be honest, I just do it because I like it.