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

Go Naming Conventions: A Practical Guide

alexedwards.net

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Go Naming Conventions: A Practical Guide

#31

Post by laserlight »

bborud wrote: post #23
laserlight wrote: post #12

> we use the identifier p to represent a value in the people slice — the range block is so small and tight that using a single letter name is clear enough. No, it's not. When you see `p.Age`, you have to go back and find the body of the loop, see what it operates on and decipher what p stands for. When you see `person.Age`, you understand it. I've never understood what is gained by using `p` instead of spelling it ou…

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

person.Age is easier to understand than p.Age regardless of the loop size.

Re: Go Naming Conventions: A Practical Guide

#32

Post by jayd16 »

piekvorst wrote: post #13
laserlight wrote: post #12

> we use the identifier p to represent a value in the people slice — the range block is so small and tight that using a single letter name is clear enough. No, it's not. When you see `p.Age`, you have to go back and find the body of the loop, see what it operates on and decipher what p stands for. When you see `person.Age`, you understand it. I've never understood what is gained by using `p` instead of spelling it ou…

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.

> 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.

Re: Go Naming Conventions: A Practical Guide

#33

Post by ConcurrentCrab »

bborud wrote: post #27
piekvorst wrote: post #13

Earlier quoted context omitted.

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.

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

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.

Re: Go Naming Conventions: A Practical Guide

#34

Post by bborud »

diath wrote: post #22
piekvorst wrote: post #13

Earlier quoted context omitted.

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.

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 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.

Re: Go Naming Conventions: A Practical Guide

#35

Post by Groxx »

jayd16 wrote: post #32
piekvorst wrote: post #13

Earlier quoted context omitted.

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.

> 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.

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.

Re: Go Naming Conventions: A Practical Guide

#36

Post by Groxx »

bborud wrote: post #34
diath wrote: post #22

Earlier quoted context omitted.

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

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.

Re: Go Naming Conventions: A Practical Guide

#37

Post by zer00eyz »

bborud wrote: post #27
piekvorst wrote: post #13

Earlier quoted context omitted.

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.

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

> 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.

Re: Go Naming Conventions: A Practical Guide

#38

Post by bborud »

zer00eyz wrote: post #30
bborud wrote: post #23

Earlier quoted context omitted.

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

You arent wrong, but it is not an absolute. Furniture maker, house framer, finish carpenter are all under the category of woodworking, but these jobs are not the same. Years of honed skill in tool use makes working in the other categories possible, but quality and productivity will suffer. Does working in JS, on the front end teach you how to code, it sure does. So does working in an embedded system. But these jobs m…

I didn't say it was an absolute. But once a scope grows to the point where you have to navigate to absorb a function or a loop, both readability and complexity tends to worsen. As does your mental processing time. Especially for people who "scan" code rapidly rather than reading it.

The slower "readers" will probably not mind as much.

This is why things like function size is usually part of coding standards at a company or on a project. (Look at Google, Linux etc)

Re: Go Naming Conventions: A Practical Guide

#39

Post by alex_edwards »

qezz wrote: post #8

I was surprised to see literally invalid names in the "bad" section, e.g. "Cannot start with a digit". Why even presenting this if it's rejected by the compiler?

Author here. The answer is because I mentioned it as one of the bullet pointed hard-rules, and I wanted to include an example to illustrate it.

Re: Go Naming Conventions: A Practical Guide

#40

Post by lokar »

monooso wrote: post #19
piekvorst wrote: post #13

Earlier quoted context omitted.

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.

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

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