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

21–30 of 77 posts

Re: Go Naming Conventions: A Practical Guide

#21

Post by jplona »

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…

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.

Re: Go Naming Conventions: A Practical Guide

#22

Post by diath »

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.

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.

Re: Go Naming Conventions: A Practical Guide

#23

Post by bborud »

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.

Re: Go Naming Conventions: A Practical Guide

#24

Post by esrauch »

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…

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.

Re: Go Naming Conventions: A Practical Guide

#27

Post by bborud »

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.

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

Re: Go Naming Conventions: A Practical Guide

#28

Post by alexfoo »

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?

I wondered if you could sneak in some unicode digit but it seems to reject those too:

    $ go run z.go
    # command-line-arguments
    ./z.go:6:2: identifier cannot begin with digit U+0661 '١'
    ./z.go:7:27: identifier cannot begin with digit U+0661 '١'
(I tried a few of them but not all.)

Re: Go Naming Conventions: A Practical Guide

#30

Post by zer00eyz »

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.

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 might be further apart than any of the ones I highlighted in the previous category.

There are plenty of combinations of systems and languages where your rule about a screen just isn't going to apply. There are plenty of problems that make scenarios where "ugly loops" are a reality.

Post reply on HN