[alpaca128]

Then one year later you have to play archeologist and figure out the hard way what `f` is used for. And I also find it much more difficult to write code like this in the first place because it forces me to memorize the purpose of every identifier.

Not sure how "easier to type" is relevant - aside from Notepad pretty much every editor offers some completion feature. I'm definitely a fan of longer identifiers, though abbreviated where it makes sense and using short words where possible.

[seanmcdirmid]

If you are basing off of mathematical notation, f g and h might make sense for identifiers for very generic functions, especially if tin are implementing the chain rule somehow. I would find more verbose names harder to read because the notation was already ingrained. Same for those who name their looping integers something other than i or j.

[usrbinbash]

> and figure out the hard way what `f` is used for.

In a 20 LOC function, that takes me about a second, if that long.

> aside from Notepad pretty much every editor offers some completion feature

It's still easier to type `f` than `fi` + leadkey + N or whatever the editor uses. Bonus points if the first prediction is wrong, or ambivalent.

And the more important reason is "easier to read", especially in long expressions;

    for e := getFirst(); e != nil; e.Next()

is much easier to read than

    for currentElement := getFirst(); currentElement != nil; currentElement.Next()

Finally, not only the name itself, but also it's length should convey meaning. If I see a variable like `currentElement` in my code, I immediately know that it probably lives beyond the scope it is defined in. If I see a variable named `c` I know that it is a short lived throwaway.