by techsin101 on 12/27/22, 1:12 AM with 50 comments
- There are few variables in the whole code block < 5.
- Amount of lines is < 25.
- 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.
by orzig on 12/27/22, 1:28 AM
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.
by lucb1e on 12/27/22, 1:58 AM
Even in your example cases, though, compare these two lines:
a = arr.filter(n => n.flag === true);
a = arr.filter(user => user.flag === true);
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.
by moloch-hai on 12/27/22, 2:24 AM
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.
by mudrockbestgirl on 12/27/22, 2:20 AM
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
by pjdkoch on 12/27/22, 2:18 AM
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.
by readthenotes1 on 12/27/22, 2:07 AM
That's worked well for me on a qualitative level
by akerl_ on 12/27/22, 1:21 AM
“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”
by borplk on 12/27/22, 6:09 AM
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.
by saeranv on 12/27/22, 2:03 AM
by pestatije on 12/27/22, 1:23 AM
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(...)
by cirrus3 on 12/27/22, 3:33 AM
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.
by Gualdrapo on 12/27/22, 5:27 AM
by igtztorrero on 12/27/22, 1:53 AM
by justsomeuser on 12/27/22, 3:45 PM
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).
by D-Coder on 12/27/22, 1:26 AM
by sublinear on 12/27/22, 1:59 AM
by AlphaWeaver on 12/27/22, 2:11 AM
by bityard on 12/27/22, 2:43 AM
by heavyset_go on 12/27/22, 1:51 AM
by KptMarchewa on 12/27/22, 1:55 AM
by decremental on 12/27/22, 2:05 AM
by sys_64738 on 12/27/22, 2:28 AM
by Tagbert on 12/27/22, 1:37 AM