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

61–70 of 77 posts

Re: Go Naming Conventions: A Practical Guide

#61

Post by wpollock »

Allowing Unicode characters, then stating best practice is to stick with ASCII, is weird. (Go is not alone in this practice.) Unicode identifiers have a host of issues, such as some characters have no case distinction, some have title-case but not uppercase, some "capitalize" the last letter in a word and not the first (Hebrew has five "final form" letters), etc. Does Go specify the meaning (exported or not) if a letter has no case, or if an identifier starts with a zero-width joiner character? Without a huge list of detailled rules, too much is left to the implementation to decide. I prefer to stick with ASCII for names.

Fun fact: When printing with movable type began, printers would travel with large "type cases" containing the small wood or metal blocks with glyphs on them. The ones the used frequently were kept in the lower half of the case, in easy reach. That's where the terms "lowercase" and "uppercase" come from.

Re: Go Naming Conventions: A Practical Guide

#62

Post by ManuelKiessling »

graynk wrote: post #59
voidfunc wrote: post #56

Earlier quoted context omitted.

Using a linter doesn't get you noticed by leadership and net you a promo.

Sure it does, just say you "established org-wide coding standards and drove adoption of automated linting tooling, reducing review friction and enforcing style consistency at scale" in your assessment.

Better yet, post about it on LinkedIn and explain what it taught you about marriage proposals!

Re: Go Naming Conventions: A Practical Guide

#63

Post by saghm »

ickyforce wrote: post #17
saghm wrote: post #14

Earlier quoted context omitted.

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

> and any decent formatter will split up long lines Any decent editor can wrap long lines on demand. But it's even better not to have to do either of those if not necessary. > I've felt strongly for a while now that abbreviations should be "lossless" in order to be useful This is how we got lpszClassName. The world moved away from hungarian notation and even away from defining types for variables in some contexts (au…

I'd argue there's a stark difference between abbreviating words and adding extra ones. `p` as a shorthand for `person` is silly to me, but that doesn't mean that `personObject` would also be silly to me. I fundamentally don't agree with the premise that it's possible to be too verbose means that terseness is its own goal; the goal should be clarity, and I don't think that lossy abbreviations actually help with that except when someone already knows what the code is doing, in which case they don't need to read it in the first place.

Re: Go Naming Conventions: A Practical Guide

#64

Post by arcxi »

wpollock wrote: post #61

Allowing Unicode characters, then stating best practice is to stick with ASCII, is weird. (Go is not alone in this practice.) Unicode identifiers have a host of issues, such as some characters have no case distinction, some have title-case but not uppercase, some "capitalize" the last letter in a word and not the first (Hebrew has five "final form" letters), etc. Does Go specify the meaning (exported or not) if a let…

it is weird, especially for Go with its semantic naming and famously opinionated compiler. it will gladly build code with a variable named 𖤐界ᥱᥲΣ੭, but God forbid it's unused.

Re: Go Naming Conventions: A Practical Guide

#65

Post by mysterymath »

laserlight wrote: post #31
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.

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

Another point of view: ideally it would just be "Age". But in languages that don't have the ability to "open" scopes, one might be satisfied p.Age, being "the age". I've also seen $.age and it.age, in languages with constructs that automatically break out "it" anaphora.

Re: Go Naming Conventions: A Practical Guide

#66

Post by layer8 »

wpollock wrote: post #61

Allowing Unicode characters, then stating best practice is to stick with ASCII, is weird. (Go is not alone in this practice.) Unicode identifiers have a host of issues, such as some characters have no case distinction, some have title-case but not uppercase, some "capitalize" the last letter in a word and not the first (Hebrew has five "final form" letters), etc. Does Go specify the meaning (exported or not) if a let…

It’s bad to disallow non-ASCII characters when programming for non-English business domains. The domain vocabulary often doesn’t translate well to English, or you need a glossary for someone familiar with the business domain to know which English term is supposed to mean which native business term. It’s just a pain. Conversely, transliterating the native term in ASCII can introduce ambiguities or be awkward or just plain weird for the native speaker.

Of course, Unicode can be abused, but ASCII isn’t completely free of that either. (Maybe it tickles your fancy to name a variable _o0O0o_ or l1lIl1lIl1lIl1l.) If your native script doesn’t have upper and lower case, compromises may have to be made. We have to trust programmers to use good judgement.

Re: Go Naming Conventions: A Practical Guide

#67

Post by fragmede »

layer8 wrote: post #66
wpollock wrote: post #61

Allowing Unicode characters, then stating best practice is to stick with ASCII, is weird. (Go is not alone in this practice.) Unicode identifiers have a host of issues, such as some characters have no case distinction, some have title-case but not uppercase, some "capitalize" the last letter in a word and not the first (Hebrew has five "final form" letters), etc. Does Go specify the meaning (exported or not) if a let…

It’s bad to disallow non-ASCII characters when programming for non-English business domains. The domain vocabulary often doesn’t translate well to English, or you need a glossary for someone familiar with the business domain to know which English term is supposed to mean which native business term. It’s just a pain. Conversely, transliterating the native term in ASCII can introduce ambiguities or be awkward or just p…

I believe https://imgur.com/dN9Nz3h is the canonical example of why full Unicode support is maybe not desirable.

Re: Go Naming Conventions: A Practical Guide

#68

Post by arcxi »

layer8 wrote: post #66
wpollock wrote: post #61

Allowing Unicode characters, then stating best practice is to stick with ASCII, is weird. (Go is not alone in this practice.) Unicode identifiers have a host of issues, such as some characters have no case distinction, some have title-case but not uppercase, some "capitalize" the last letter in a word and not the first (Hebrew has five "final form" letters), etc. Does Go specify the meaning (exported or not) if a let…

It’s bad to disallow non-ASCII characters when programming for non-English business domains. The domain vocabulary often doesn’t translate well to English, or you need a glossary for someone familiar with the business domain to know which English term is supposed to mean which native business term. It’s just a pain. Conversely, transliterating the native term in ASCII can introduce ambiguities or be awkward or just p…

Anecdotally I'm programming for non-English business domains in Go and Python and I've literally never seen anyone use native alphabet in identifiers - it's always either poor translations or transliterations.

Re: Go Naming Conventions: A Practical Guide

#69

Post by kalaksi »

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…

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

Re: Go Naming Conventions: A Practical Guide

#70

Post by throawayonthe »

fragmede wrote: post #67
layer8 wrote: post #66

Earlier quoted context omitted.

It’s bad to disallow non-ASCII characters when programming for non-English business domains. The domain vocabulary often doesn’t translate well to English, or you need a glossary for someone familiar with the business domain to know which English term is supposed to mean which native business term. It’s just a pain. Conversely, transliterating the native term in ASCII can introduce ambiguities or be awkward or just p…

I believe https://imgur.com/dN9Nz3h is the canonical example of why full Unicode support is maybe not desirable.

because ths is so much better:

    class pppp {
        func ppp(_ c: Int, m: Int) -> Int {
            return c + m
        }
    }
    
    var b = 3
    var s = b + 2
    
    var p = pppp()
    print(p.ppp(b, m: s))
Post reply on HN