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

Go Style

google.github.io

Post reply on HN
Print view View original

71–80 of 212 posts

Re: Go Style

#71

Post by throwaway2203 »

Go is absurd. It's opinionated in all the wrong ways.

> Functions that return something are given noun-like names.

> // Good: > func (c Config) JobName(key string) (value string, ok bool)

> A corollary of this is that function and method names should avoid the prefix Get.

> // Bad: > func (c Config) GetJobName(key string) (value string, ok bool)

That's dumb. I'd like a function to be GetJobName to indicate that it doesn't mutate anything. Maybe CreateJobName to indicate mutation. Just JobName is useless.

The other day, I spent a whole day trying to figure out the "idiomatic" way to return a an object not found case from my db. Do you return a nil pointer (don't, passing pointers leads to bugs), or an empty struct (then how do you reliably "test" its emptiness?) or an error? And of course, there's no real hierarchy of errors, no built-in extensible handling of errors that is semantic and makes sense, so every project just goes and reinvents their wheel.

Re: Go Style

#72

Post by Thaxll »

throwaway2203 wrote: post #71

Go is absurd. It's opinionated in all the wrong ways. > Functions that return something are given noun-like names. > // Good: > func (c Config) JobName(key string) (value string, ok bool) > A corollary of this is that function and method names should avoid the prefix Get. > // Bad: > func (c Config) GetJobName(key string) (value string, ok bool) That's dumb. I'd like a function to be GetJobName to indicate that it do…

If you rely on naming function to know if things can be mutated you're doing things wrong. The only source of truth is the type received.

Re: Go Style

#73

Post by throwaway2203 »

Thaxll wrote: post #72
throwaway2203 wrote: post #71

Go is absurd. It's opinionated in all the wrong ways. > Functions that return something are given noun-like names. > // Good: > func (c Config) JobName(key string) (value string, ok bool) > A corollary of this is that function and method names should avoid the prefix Get. > // Bad: > func (c Config) GetJobName(key string) (value string, ok bool) That's dumb. I'd like a function to be GetJobName to indicate that it do…

If you rely on naming function to know if things can be mutated you're doing things wrong. The only source of truth is the type received.

Why? Let's say I have a table full of cars and have a method

> func Car(id string) Car

How do I know whether it fetched that from the database or created a new one and returned that to me?

Re: Go Style

#74

Post by keybored »

> Go source code uses MixedCaps or mixedCaps (camel case) rather than underscores (snake case) when writing multi-word names.

> This applies even when it breaks conventions in other languages. For example, a constant is MaxLength (not MAX_LENGTH) if exported and maxLength (not max_length) if unexported.

Good. All-caps for constants would make no sense in a language like Go.

Re: Go Style

#75

Post by metaltyphoon »

encryptluks2 wrote: post #24

Interesting that Google uses GitHub still. With Microsoft owning it and it becoming less free than alternatives, you'd think for documentation like this they'd use an externally hosted GitLab instance for their external projects or that they'd have acquired something to compete with GitHub by now like Gitea.

Less free? Microsoft didn't change a damn thing on GH, in fact its only getting better after acquisition.

Re: Go Style

#76

Post by CSSer »

mroche wrote: post #60

I found the following statement in the Maintainability section interesting: > Maintainable code minimizes its dependencies (both implicit and explicit). Depending on fewer packages means fewer lines of code that can affect behavior. Avoiding dependencies on internal or undocumented behavior makes code less likely to impose a maintenance burden when those behaviors change in the future. Obviously this guide was writte…

A lot of this comes down to available resources too. I used to hate how many third party things we used on principle and because I directly felt all the pain of tying them together. Now I’m a lead and I still dislike it but because I have a realistic read on how much bandwidth my team has I think this has balanced my view. I also still feel the pain but sometimes more indirectly (code reviews, for example).

I think where I still struggle is “rules for thee but not for me”. At some point, someone on the team (usually the person in charge) is just going to be better at picking which external libs to let in. I find this really hard to teach without it seeming arbitrary. I find it a lot easier to teach good coding habits.

Re: Go Style

#77

Post by seritools »

Zach_the_Lizard wrote: post #17
enneff wrote: post #15

Earlier quoted context omitted.

The question: what is the state of your server after a handler panics? The answer: you have no idea. It is not wise to continue serving requests when you may have serious issues in the state of your server. Maybe some central data structure is now corrupt. You have no way of knowing. Fail fast and fail hard. OTOH, maybe your priorities are different and you would prefer to be more available than correct. In that case…

In my experience, the panic is most likely because someone accessed a nil field when adapting some data. Nothing is corrupt, we just threw an exception in a mundane way. The reality is this is far more common than something truly fatal. Mistake for someone or not, it probably is correct for most use cases

> most likely

> probably is correct

Yeah I don't know...

Re: Go Style

#78

Post by leetrout »

jawzz wrote: post #69
Xeoncross wrote: post #58

Earlier quoted context omitted.

The constancy in Go makes this better. I have come to expect `r` to be an io.Reader or http.Request depending on context. There are a few interfaces in Go that are used heavily and I don't mind that people often use a single character for them. It's the same thing as everyone using `i` for iterators.

This makes me wonder: what if there was a language where variable names are determined according to the type, with the option of overriding with a custom name. So a variable of type http.Request would automatically be named “req”, the next one in scope would be “req2”, etc. If you think about it, when you solve a physics problem, for instance, you call every mass “m1”, “m2”, etc. Maybe this would be another step in G…

This is interesting.

The idea of having a standard library of types related to what are effectively program keywords... could be really good. Or hideous like global vars.

I wonder if any language has tried this?

Re: Go Style

#79

Post by everybodyknows »

adamgordonbell wrote: post #27

> The general rule of thumb is that the length of a name should be proportional to the size of its scope and inversely proportional to the number of times that it is used within that scope. > A variable created at file scope may require multiple words, whereas a variable scoped to a single inner block may be a single word or even just a character or two, to keep the code clear and avoid extraneous information. I love…

> A variable created at file scope

How does one declare a variable to be of file scope in Go? An ordinary "var x int" has package scope, visible from any file in the directory (aside from the special cases around _test.go files).

Scope of package import declarations is narrowed to a single .go file, but these of course are not variables.

Re: Go Style

#80

Post by jeffbee »

jefftk wrote: post #68
encryptluks2 wrote: post #24

Interesting that Google uses GitHub still. With Microsoft owning it and it becoming less free than alternatives, you'd think for documentation like this they'd use an externally hosted GitLab instance for their external projects or that they'd have acquired something to compete with GitHub by now like Gitea.

https://gerrit.googlesource.com/

It is nevertheless the case that the Go Style Guide and all the other style guides were officially hosted in the past at https://google-styleguide.googlecode.com/ and now that's a 404.
Post reply on HN