Single letter variable names annoy me so much. Every programmer uses an editor or IDE with autocomplete. Just use a damn name that describes the thing, if it's a little long no one cares.

CS papers are the worst in my experience. I know lines have to be kept short, but I think some people believe a tiny code block makes them look like a better programmer.

I like how Swift does it[0] — it reads nicer than any other language I've used.

[0]: https://swift.org/documentation/api-design-guidelines/

> Every programmer uses an editor or IDE with autocomplete.

This is news to me. I use JOE and, occasionally, vi (sic). But when I use short variable names it's often because they're idiomatic and expressive. In C for example, i, j, n, src, buf, cp, etc.

Many moons ago I used IDEs. Eventually I tired of installing, configuring, and maintaining bespoke environments.

I'm confident I'm not alone.

It's cool you have found a workflow that works for you, but I don't think there are many people using JOE or (plain) vi to write software.

https://insights.stackoverflow.com/survey/2019#technology-_-...

I can't imagine working that way myself. I need syntax highlighting, code completion, and go to definition at the minimum. Another newer feature I like is spelling and grammar checking of code comments.

Edit: Have you given Sublime Text 3 a shot?

The breakdown of "All Respondents" (i.e. all programmers) into Web, Mobile, and SRE/DevOps is telling.

Let's just say that it's a big world. People programming Excel spreadsheets aren't using vi, either. I won't dispute that.

I’d love to understand the rationale for preferring extremely short variable names.

I like short variable names - for variables used in only a short block of code. I like long variable names - for e.g. a field on a struct used all over a file, and certainly exported ones.

I think "Go uses single letter variable names" is not so true in practice. There's a balance, in every language, between when to use short and long names. Go's balance is tilted (a good bit) more towards short, but it's not a hard rule.

There's significant mental overhead in reading `numberOfSubprotosOnProto`, as well as time hearing it in my head. I'd rather see `n` declared, used a few times in the next <10 lines, and then disappear. If there's two similar concepts in the same function, use slightly longer names, sure. Certainly not m and n.

I think that's the same reason math tends to use single letter variables. "Taylor series are easy! Just memorize: 'f_series_degree(evaluation_point, expansion_point) = sum(derivative_order=0..series_degree, (evaluation_point - expansion_point)^derivative_order * f^{derivative_order}(expansion_point) / derivative_order!)'

No thanks, I'll take f_n(x, a) = sum(i=0..n, f^n(a)(x-a)^n/n!).

I don’t know if it’s ironic or not, but as someone not into mathematics, the first example is far more readable, and it’s not close.

By readable, I think you mean you get to read some whole words thereby get the impression of better readability, but in actuality it doesn't not necessarily aid comprehension if you don't know anything about taylor series, or maths in general.

I'm not saying more descriptive variable names doesn't help, but saying that you are not into mathematics makes your point moot.

But I know what an evaluation is, a point is, a degree is, etc. These words contain semantic data.

Single letter variable names are throw away variables which you don't actually care about except for maybe a line or so.

I think to use them when I'm trying to "show my working out" and it takes me back to algebra class days so I don't mind

Gotta save those bytes

Some people prefer lattes, some cappuccinos, but it's all milk baby.