Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: I prefer single letter variables

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Ask HN: I prefer single letter variables

#31

Post by cirrus3 »

mudrockbestgirl wrote: post #24

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 funct…

> The code is self-explanatory

Never overestimate this, there is no upside to the one time it isn't.

> Reading over-the-top verbose code is just as bad as the opposite

No it isn't, it is just as easy, and when can help it pays off, there is no downside.

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

This isn't an either or, if it deserves a comment by all means use one, but that doesn't negate the benefits of thoughtfully named vars.

Re: Ask HN: I prefer single letter variables

#32

Post by cirrus3 »

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.

Re: Ask HN: I prefer single letter variables

#33

Post by cirrus3 »

orzig wrote: post #6

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, inc…

> though I am in a minority at work

This should tell you something. Taking the time to name it nicely now costs almost nothing vs wasting your time trying to prove it can be refactored later and then doing that refactor later. Why? What are you getting out this? Taking 1 second to name it nicely vs the time it costs for everyone to listen to you "make a case for brevity", just please don't be that person. No one likes or respects that person more even when you are right.

Re: Ask HN: I prefer single letter variables

#34

Post by cirrus3 »

lucb1e wrote: post #15

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 =…

Using "n" here instead of "user" just screams lazy... I wouldn't flag it either, and it will probably never be a problem is this case, but I would momentarily think of the dev that wrote "n" as lazy and worry a tiny bit more about what other code they are writing lazily as well. Don't be that person.

Re: Ask HN: I prefer single letter variables

#35

Post by cirrus3 »

pjdkoch wrote: post #22

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 to…

> There's something elucidating (and satisfying) in seeing a non-obvious piece of code in your native style.

Not 5 years later, and when it is someone else's code. Just don't. Initialisms are no better than single char var names. No one later is going to know you started naming "SmartFooProcessingThing" as "sfpt" and when they search for it in millions of lines of the codebase, they are gonna come up empty and waste time.

There is nothing you should be finding "satisfying" in a non-obvious piece of code. And if you are working on team, there should be nothing "in your native style". Don't be that person.

Re: Ask HN: I prefer single letter variables

#36

Post by drpyser22 »

cirrus3 wrote: post #33
orzig wrote: post #6

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, inc…

> though I am in a minority at work This should tell you something. Taking the time to name it nicely now costs almost nothing vs wasting your time trying to prove it can be refactored later and then doing that refactor later. Why? What are you getting out this? Taking 1 second to name it nicely vs the time it costs for everyone to listen to you "make a case for brevity", just please don't be that person. No one like…

I disagree that naming something correctly always takes no time. Sometimes a useful and correct name is non-obvious, or repetitive, or you're trying to name something abstract or generic.

Re: Ask HN: I prefer single letter variables

#37

Post by techsin101 »

sli wrote: post #9
techsin101 wrote: post #5

Earlier quoted context omitted.

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

Gonna need parens around that object constructor. ;)

.... Always

Re: Ask HN: I prefer single letter variables

#38

Post by techsin101 »

cirrus3 wrote: post #32

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 cas…

If there is every time there a single variable is being searched then it means that it was not limited to that scope and by let's go. I mean in few lines front and back and if it wasn't then it should have never been a single letter variable. I see single letter variables as placeholders that are meant to live very temporarily. Few lines at best

Re: Ask HN: I prefer single letter variables

#39

Post by techsin101 »

lucb1e wrote: post #15

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 =…

Sure, in this example user looks better. But as I said this code is not going to be existing on its own. There's going to be code preceded by this. Which is going to give a pretty good idea of what is being filtered on and you can always have comments before the code that can explain the general idea of what you're trying to achieve instead of burdening short-lived variables with a role of needing to give hints of what's going on at the expense of readability and speed of parsing mentally

Re: Ask HN: I prefer single letter variables

#40

Post by Gualdrapo »

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
Post reply on HN