[piekvorst]

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.

[monooso]

I would argue that ambiguity and uncertainty slow down reading, and more importantly comprehension, far more than a few additional characters.

[lokar]

It depends on whom you are optimizing for. Someone who knows the language, but not this system/codebase, or someone who works in this area often?

[diath]

Something like "AnIteratorObjectWithPersonPointer" would be a long word, "person" is absolutely not. If a 6 letter identifier causes you that much trouble with code being too verbose, then it's likely a screen resolution/density/font issue, not a naming issue.

> That would make “ProductIndex” superior to “i”, which doesn't add any clarity.

And then you introduce extra two levels of nested loops and suddenly "i", "j", and "k" don't make any sense on their own, but "ProductIndex", "BatchIndex" and "SeriesIndex" do.

[bborud]

And then you introduce extra two levels of nested loops and suddenly "i", "j", and "k" don't make any sense on their own, but "ProductIndex", "BatchIndex" and "SeriesIndex" do.

ijk for indices in loops are actually clearer than random names in nested loops precisely because it is a *very common convention* and because they occur in a defined order. So you always know that "j" is the second nesting level, for instance. Which relates to the visual layout of the code.

You may not have known of this convention or you are unable to apply "the principle of least astonishment". A set of random names for indices is less useful because it communicates less and takes longer to comprehend.

Just like most humans do not read text one letter at a time, many programmers also do not read code as prose. They scan it rapidly looking at shapes and familiar structures. "ProductIndex", "BatchIndex" and "SeriesIndex" do not lend themselves to scanning, so you force people who need to understand the code to slow down to the speed of someone who reads code like they'd read prose. That is a bit amateurish.

[zahlman]

> ijk for indices in loops are actually clearer than random names in nested loops precisely because it is a very common convention and because they occur in a defined order. So you always know that "j" is the second nesting level, for instance. Which relates to the visual layout of the code.

In problem domains that emphasize multidimensional arrays, yes.

More often nowadays I would see `i` and think "an element of some sequence whose name starts with i". (I tend to use `k` and `v` to iterate keys and values of dictionaries, but spell `item` in full. I couldn't tell you why.)

[Groxx]

I partly agree, and partly don't. When ijk really is unambiguous and the order is common (say you're implementing a well-known algorithm) I totally agree, the convention aids understanding.

But nesting order often doesn't control critical semantics. Personally, it has much more often implied a heuristic about the lengths or types (map, array, linked list) of the collections (i.e. mild tuning for performance but not critical), and it could be done in any order with different surrounding code. There the letters are meaningless, or possibly worse because you can't expect that similar code elsewhere does things in the same nesting order.

This likely depends heavily on your field though.

[bborud]

I think I know what you mean. Let's assume a nesting structure like this:

Company -> Employee -> Device

That is, a company has a number of employees that have a number of devices, and you may want to traverse all cars. If you are not interested in where in the list/array/slice a given employee is, or a given device is, the index is essentually a throwaway variable. You just need it to address an entity. You're really interested in the Person structure -- not its position in a slice. So you'd assign it to a locally scoped variable (pointer or otherwise).

In Go you'd probably say something like:

for _, company := range companies { for _, employee := range company.Employees { for _, device := range employee.Devices // ..do stuff } }

ignoring the indices completely and going for the thing you want (the entity, not its index).

Of course, there are places where you do care about the indices (since you might want to do arithmetic on them). For instance if you are doing image processing or work on dense tensors. Then using the convention borrowed from math tends to be not only convenient, but perhaps even expected.

[Joker_vD]

A good variable name is the one that is understood by reading it in context, which is why you don't have names like "current_person" or "CurrentIndexOfProductBeingUpdated".

[bborud]

I think this may be related to how people read code. You have people who scan shapes, and then you have people who read code almost like prose.

I scan shapes. For me, working with people who read code is painful because their code tends to to have less clear "shapes" (more noise) and reads like more like a verbal description.

For instance, one thing I've noticed is the preference for "else if" rather than switch structures. Because they reason in terms of words. And convoluted logic that almost makes sense when you read it out loud, but not when you glance at it.

This is also where I tend to see unnecessarily verbose code like

func isZero(a int) bool { if a == 0 { return true } else { retur false } }

strictly speaking not wrong, but many times slower to absorb. (I think most developers screech to a halt and their brain goes "is there something funny going on in the logic here that would necessitate this?")

I deliberately chose to learn "scanning shapes" as the main way to orient myself because my first mentor showed me how you could navigate code much faster that way. (I'd see him rapidly skip around in source files and got curious how he would read that fast. Turns out he didn't. He just knew what shape the code he was looking for would be).

[kalaksi]

> strictly speaking not wrong, but many times slower to absorb. (I think most developers screech to a halt and their brain goes "is there something funny going on in the logic here that would necessitate this?")

I agree with this, but can't see how this applies to variable naming. Variable names can be too long, sure, but in my opinion, very short non-obvious variable names also make scanning and reading harder since they are not familiar shapes like more complete words. Additionally, when trying to understand more deeply, you have to stop and read code more often if variable's meaning is not clear.

That said, 1-2 char variable names work well in short scopes, like in some lambda, or when using 'i' for an index in a loop (nested loops would depend on situation), but those are an exception.

Like always, this is probably subjective too. And well-organized codebase probably helps to keep functions shorter, but there's often not much I can do about the existing codebase having overgrown functions all over.

[zer00eyz]

> I think this may be related to how people read code. You have people who scan shapes, and then you have people who read code almost like prose.

I think this is an astute observation.

I think there is another category of "reading" that happens, is what you're reading for "interaction" or "isolation".

Sure c.method is a scalable shape but if your system deals with Cats, Camels, Cars, and Crabs that same c.method when dealing with an abstract api call divorced from the underlying representation might not be as helpful.

I would think that we would have more and better research on this, but the only paper I could find was this: https://arxiv.org/pdf/2110.00785 its a meta analysis of 57 other papers, a decent primer but nothing ground breaking here.

> I scan shapes. ... verbal description.

I would be curious if you frequently use a debugger? Because I tend to find the latter style much more useful (descriptive) in that context.

[bborud]

dealing with an abstract api call divorced from the underlying representation

I don't understand what you mean. Could you give me an example?

I would be curious if you frequently use a debugger?

I practically never use a debugger.

[functional_dev]

The shape argument works well in small packages but it starts to fail once you have multiple domain models starting with the same letter

[bborud]

I wasn’t talking about just symbols but entire paragraphs of code as well.

[ConcurrentCrab]

I think this is pretty insightful, and I might add this as another reason LLM code looks so revolting. It's basically writing prose in a different language, which make sense - it's a _language_ model, it has no structural comprehension to speak of.

Whereas I write code (and expect good code to be written) such that most information is represented structurally: in types, truth tables, shape of interfaces and control flow, etc.

[jayd16]

> That would make “ProductIndex” superior to “i”, which doesn't add any clarity.

Adds a ton of clarity, especially if you have a nested loop.

[Groxx]

and god help you if those loops are pairing People and Products.

though now that I write that out... it would be really nice if you could optionally type iteration vars so they couldn't be used on other collections / as plain integers. I haven't seen any languages that do that though, aside from it being difficult to do by accident in proof-oriented languages.

[jayd16]

You usually don't need an index that can't be used elsewhere. If you don't then you can abstract it away entirely and use an iterator or foreach features.

[Groxx]

Depends on the language. Doing that is a huge pain in Go (until fairly recently, and it's still quite abnormal or closure-heavy), so the vast majority of code there does manual index-pairing instead of e.g. a zip iterator when going through two paired arrays.