I am with you on this, though I am in a minority at work. An underappreciated benefit is that you are signaling to the reader, when they first see the variable, that it will only be used briefly. That helps them ration their attention.

The strongest counter argument is that developers cannot be trusted to avoid building a house of cards if you let them use, even a single shortcut. And there is plenty of evidence, including my own experience, to back that up. But if you can prove you will re-factor when the time is right, it becomes a lot easier to make your case for brevity.

Exceptions exist, sure. The title is that you prefer single letters generally but the submission text is more about exception situations for throwaway variables, so it doesn't quite sound consistent. The title and submission text also contain no concrete question, so I'm not really sure what you're looking for here.

Even in your example cases, though, compare these two lines:

   a = arr.filter(n => n.flag === true);
   a = arr.filter(user => user.flag === true);

Which one is more clear here?

I hate ${JavaStyleVariableName}s that are so long that it takes extra mental effort to parse the names, so I'm fully with you if you argue for appropriate variable name lengths, but having any name at all (one character is typically not a name) can give some indication of what it is, even if abbreviated or otherwise terse. The variable 'n' sounds like a number, rather than an object that would have a .flag property. While not very confusing, it's also not the most intuitive thing to call it. I wouldn't flag this as "please fix" in a code review, but it's also not better than using any name at all.

This is a ridiculous thing to have to discuss. Probably it is a product of software development's version of the "Homeowner's Association", Code Review, where petty rule enforcement is allowed to overrule good sense.

The essence of a name is twofold: it identifies a thing, and distinguishes it from every other thing. Anything that achieves these two ends is a good name.

Where there is only one thing, its name doesn't matter: only language syntax demands it have a name at all. Shortest is best. In some languages, "_" is that name.

Where there are only two, you need two names visibly distinct. The easiest and cleanest way is two one-letter names.

Using longer names lets you provide documentation without adding a comment which could later become incorrect. That is the only value in a longer name. A longer name has a cost that has nothing to do with how long it takes to type: the reader has to read it to determine it is this thing and not that. It squanders readers' attention. It is worst if it is similar to another name.

If you want to use talking about names in code review to make code better, pay more attention to names that are too similar than to short names.

I generally agree with you, but it depends on how obvious the semantics of the code are.

In your example, noNameDateFiltered is most likely superfluous. If the filter function is short it's self-descriptive what it does. Adding long variables names makes the code harder to read and adds cognitive overhead. In this case, I would strongly prefer just re-using arr or a.

On the other hand, I have seen long complex function that use single-letter variable names and end up with 20 variables that mean different things. Keeping track of what's what in such a case becomes difficult, and you want something more descriptive.

Taking a step back, the goal of variable names is to make the code easily comprehensible by someone else or you at a later time. You have a few choices to do this, in order of preference:

- The code is self-explanatory, like a simpler filter function - use a short simple variable names. This is always the preferred method. Why make it harder than it needs to be? Reading over-the-top verbose code is just as bad as the opposite.

- The code expression may cause confusion - use a more descriptive variable name, but don't go overboard

- It's difficult to describe the result succinctly even with a variable name - use comments

You're not alone. 3 to 5 letters works best for me.

Obligatory reference, given the aesthetic: https://archive.vn/mIwG0

My rule of thumb is to avoid variable names that are only used once. Instead, use something like pipeline operators, flow(), etc.

Another preference I have is to use initialisms. Might feel dumb at first, but eventually you realize (or I did, at least) that it matters more how things are "braided together" than having perfect names, and your editor prolly highlights all the uses of the variable where you have your cursor.

But, as always, prefer consistency with the rest of the team, even if you feel the rule is dumb. Don't proselytize. If the style really gets in your way to understanding the code, rewrite it and throw it away. There's something elucidating (and satisfying) in seeing a non-obvious piece of code in your native style.

Clean Code advocates that the length of a variable name should be proportional to it's scope.

That's worked well for me on a qualitative level

Do you type your variable names using vim or emacs?

“When should you use single letter var names” feels like one of those style/preference calls that doesn’t ever have solid rules, other than “if you’re working on a collaborative project, pick a rule and enforce it, even if it’s not perfect”

I agree with you and let me make another argument for it.

Consider the fact that a sensible longer variable name can not be THAT MUCH longer.

This creates a problem where you have to manufacture a 10-20-30 character name that somewhat describes what the variable is.

Inevitably you end up creating a somewhat misleading name that badly describes what that variable is supposed to be. Probably leaving something out to avoid the name getting too long. You can't write an essay as the variable name.

If you accept the short single letter variable name instead you avoid this losing battle to manufacture a name for an abstract thing.

Instead you will have the ability to maybe describe what "a" is in a more elaborate code comment.

Yeap, me too. Especially when dealing with math/physics. Full named variables for math and physics is incredibly difficult to grok, once you're used to reading it in traditional math form.

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

If nothing else, do it for the increased search scope... you can never predict when someone later is going to be desperately searching any reference to something and when digging into an issue with "foo" then the var name of "fooOutputDirectory" is going to save time vs if you named it "out" or "o".

There is no excuse about "well maybe the controller/service/repository/whatever should have been named foo* in that case, I was just holding this temp var for 2 lines of code in helper function and it shouldn't matter".... just don't. Don't be that person. No one thinks you are smarter or cooler for that.

Also consider that if you are really using tiny-scoped vars so often, maybe you are doing something else wrong.

If you have "data = arr.filter(n => n.flag === true);" and it is so tightly scoped, why do you even need "data"? Maybe just return it... if you need to do some other operation on "data", maybe chain the call? If you need to do literally anything else (even just logging it), name it it something useful.

"n" is fine here. "arr" is not... wtf is contained in "arr", what are these types that have "flag"?

Sounds like you got slammed in a code review by someone who has had to debug this type of stuff more than you and you are looking for validation. Just stop being this way sooner than later.

The only thing I can say is that I remember having quite a hard time when my buddy used all single letter variables and reading his code, back when we were learning C at uni. Not sure if after a while one can get used to it and have some "buffer memory" (sort of speak) in the brain for allocating single letter variables while reading or working with code (and if I ever had such thing for the time being), but I do remember writing in paper which variable was which when I got lost after 50 lines or so while reading - and helped me to "debug" because, a couple of times, things didn't work as expected because it seemed it was he who mixed vars when writing the code

In GoLang we use single letter variables names in selectors and local variables in small functions

I agree. For public interfaces/types or global variables descriptive names are important.

But for temp vars in short functions or closures, I also use single letter vars because I want to see what is being done to the variables rather than the description. If a description is needed I'll use a comment.

Another pattern I find myself using is trying not to use `else`, instead using a function return (either returning early with an if, or a default return at the bottom of the function).

For me, at least, typing is a lot easier than thinking.

I can only think of a few scenarios: math functions, string formatting, iterators, and generic code where there is no meaningful name.

I've encountered this in Erlang, but when using Elixir, pipes solve this problem quite nicely.

Single-letter variable names are fine for very short loops in some cases and that's about it. Nearly all other uses unnecessarily obfuscate the code for those who have to maintain it later. (Including Future You.)

The only time I feel comfortable using them is in short anonymous functions.

In lambdas, sure, but in longer functions there's usually better way.

I prefer variables of the same length so that code is symmetrical. I'll sometimes use synonyms to achieve this.

Single char bars are terrible when you’re trying to maintain code. Searching becomes really hard with cscope.

conversely, what is the case for single letter names, even in the situations you bring up? Why would someone chose to use single letter names?