>you have to go back and find the body of the loop

If the loop is long enough that you don't naturally remember how it was introduced, that's the problem. In the given example, the use of `p.Age` is literally on the next line of code after ` for _, p := range people`.

> I've never understood what is gained by using `p` instead of spelling it out as `person`.

Wisdom I received from, IIRC, the Perl documentation decades ago: tightly-scoped names should be shorter and less attention-grabbing than more broadly-scoped ones, because you should really notice when you're using a global, and you don't want to suffer attention fatigue. (I'm sure the exact wording was quite different.)

Also because it's better for information density. As I recall, Larry Wall also had the idea that more commonly used language keywords should be shorter than rare ones. Good code uses the locals much more often than globals, so you shouldn't need to expend the same amount of effort on them. (The limiting case of this is functional programming idioms where you can eliminate the variable name completely, in cases like (Python examples) `lambda x: int(x)` -> `int`, or `(foo(x) for x in xs)` -> `map(foo, xs)`.

This comes from some dated idea for stuff like C where "its okay to use shorthands for variables" but is it really? The only place I allow it is simple iterators, but now we have enhanced loops where even this is unnecessary. We don't need to save on pixel screen space like if its still the 90s. Even with a simple 1080p monitor you can fit plenty of words and code.

Give your variables, functions, classes meaningful descriptive names that make sense to humans.

I've felt strongly for a while now that abbreviations should be "lossless" in order to be useful; it should be unambiguous now get back to the unabbreviated form. For whatever reason, people seem to love trying to optimize for character count with abbreviations that actually make things more confusing (like `res` in a context where it might mean either "response" or "result).

I just don't get the obsession with terseness when we have modern tooling. I don't type particularly fast, but autocomplete makes it pretty quick for me to type out even longer names, and any decent formatter will split up long lines automatically in a way that's usually sane (and in my experience, the times when it's annoying are usually due to something like a function with way too many arguments or people not wanting to put a subexpression in a separate variable because I guess they don't know that the compiler will just inline it) rather than the names being a few characters too many.

Meanwhile, pretty much everywhere I've worked has had at least some concerns about code reviews either already being or potentially becoming a burden on the team due to the amount of time and effort it takes to read through someone else's code. I feel like more emphasis on making code readable rather than just functional and quick to write would be a sensible thing to consider, but somehow it never seems to be part of the discussion.

Long lines make reading rhythm uncomfortable (long jumps, prolonged eye movements) and long words make the text too dense and slow down the reading. It’s bad typography.

I have heard an idea that a good variable should be understood by just reading its name, out of context. That would make “ProductIndex” superior to “i”, which doesn't add any clarity.

But what if your codebase has to interact with leads, customers, and another 3rd party system called Metrica with leads, customers?

When you write a loop, do you now name the variable

OurPerson.Age MetricaPerson.Age

?

What if, 3 years from now, you include another 3rd party vendor into the system and have to write code against that data and in the data they name their stuff OurPerson.Age?

Not saying you are wrong at all. Just naming things is hard and context dependent. I think that is why it is endlessly argued.

I think this is clearly a matter of preference. Shorter variable (or rather, appropriately short variables for the context) for me are easier to recognize and disambiguate. They take up fewer tokens, so to speak. When I see `p.Age` I don't have to go back and look at the beginning of the loop because I just read that line and I remember it.

If your loops are so long you can't fit them on one screenfull you have much more fundamental issues.

This is something that it seems some Go people just don't "believe" in my experience, that for some people that letter in that context is not mentally populated immediately.

It's honestly a shame because it seems like Go is a good language but with such extremely opinionated style that is so unpleasant (not just single letters but other things stuff about tests aren't supposed to ever have helpers or test frameworks) feels aggressively bad enough to basically ruin the language for me.

I agree with this comment so much.

Tried to use the new slices package or comparables? It's a nightmare to debug, for no reason whatsoever. If they would've used interface names like Slice or Comparable or Stringable or something, it would have been so much easier.

The naming conventions are something that really fucks up my coding workflow, and it can be avoided 100% of the time if they would stop with those stupid variable names. I am not a machine, and there is no reason to make code intentionally unreadable.