Ask HN: I prefer single letter variables

So it's almost universally accepted variable names should always be descriptive, consistent, etc... but I'm sure there are scenarios where single variable names are preferable. I can't quite formulate solid parameters of when that is, but here is a try:

- There are few variables in the whole code block - Amount of lines is - Code is very functional in nature. ie. no a.getObj()

Sometimes I appreciate good variable names and sometimes I hate descriptive variable names. Short var names might be better where extra effort required to parse long names is not worth in terms of utility gained.

One example: variables are not meant to be used for long term just exist for next two lines....

i.e. filteredData = arr.filter(...) , noDateFilteredData = filteredData.filter(...), noNameDateFiltered = noDateFilteredData.filter(..)....

this would be easier to read when it's written like this

a = arr.filter(...), b = a.filter(...), filteredData = b.filter(...)

another situation...

data = arr.filter(n => n.flag === true);

// it's completely obvious what's happening here, n is iterable. calling it obj|arr|users|etc... doesn't add much value for this piece of code as is. you probably already know we are getting users. It's like not using pronouns "he"/"she" and just keep using first name: Mike wanted to come in because Mike had said that Mike needed to talk to Aniqa, Aniqa knows about the insurance stuff. Aniqa has worked in insurance....

There is inverse correlation between length of a variable name and the speed of understanding logic of the code. But smaller the name the more you need to remember what it is, and the longer it's carried over the more difficult it's to continue remembering it. So in situations where it doesn't need to be carried for a long time I prefer smaller names.

I'm sure of it from my experiences. I prefer short names generally when is less data massaging and more algorithmic in nature, because sometimes it's hard to name a var in a way that captures vague concept in algo, without making it downright misleading. i.e. i call something a sliding_window but then later don't use it as one. Reader would be like um... wait what??

TLDR: I guess correct name matters more and more, the farther you are from its declaration.

filteredData, noDateFilteredData, etc. gives me more info than a, b, etc.

Let's say you have 2 lines of code where the variable a is used: a = expr, b = a.filter(...)

Now I have to do the mental effort to see what expr is doing, instead of going directly to the second line and see filteredDateData = filteredData.filter(...)

I'd prefer it like this...

// get users older than 90

a = data.results;

b = a.filter(u => u.dob > 123456)

seniorUsers = b.map(x => {name: x.name, age: x.age})

// self contained

// comes out with one final var that is named to be used later on

// other vars are obviously meant to be ignored and just placeholders

// comment explains what is happening so each var doesn't need sacrifice comprehension speed

Yea, often vars are placeholders and making them descripting just makes them misleading and harder to get to the point. But yea at least I trust myself to refactor code and make the var name more descriptive if I see it's no longer just temporary placeholder... but would be a challenge to have others follow the same principle. One using is short name because it only helps, another to use it because you are just lazy.

Gonna need parens around that object constructor. ;)