Go Style
google.github.io
Go Style
1–10 of 212 posts
Re: Go Style
#2Isn’t the point of go is that go fmt follows the languages global style guide?
Re: Go Style
#3Isn’t the point of go is that go fmt follows the languages global style guide?
Go's fmt enforces some parts of formatting, like indentation, spaces vs. tabs and spacing around brackets and parentheses. But it is by no means a complete style guide. Fmt doesn't give your packages, structs or methods reasonable names automatically. Fmt doesn't tell you where to use values and where to use structs, what your interfaces should be, and how large your functions should be.
There is still room for a style guide.
Re: Go Style
#4Isn’t the point of go is that go fmt follows the languages global style guide?
Formatting ⊊ Style
Style may also include naming, documentation requirements, recommendations regarding function length, etc.
Re: Go Style
#5Isn’t the point of go is that go fmt follows the languages global style guide?
It includes things that are not formatting specific like naming (https://google.github.io/styleguide/go/best-practices)
Re: Go Style
#6Isn’t the point of go is that go fmt follows the languages global style guide?
At first glance, that question makes sense; however, fmt doesn't cover all code format issues. Ex from the post:
> Line length
> There is no fixed line length for Go source code. If a line feels too long, it should be refactored instead of broken. If it is already as short as it is practical for it to be, the line should be allowed to remain long.
> Do not split a line:
> Before an indentation change (e.g., function declaration, conditional)
>To make a long string (e.g., a URL) fit into multiple shorter lines
fmt doesn't force arbitrarily short lines in lieu of readability (looking at you python + pep8; I can't recall how many lines of code were a few characters long and pep8 formatting made the multiple lines a mess to visually parse). The Google Team decided that it was important to not break up perfectly readable lines and gave guidance on how to do that.
Re: Go Style
#7Isn’t the point of go is that go fmt follows the languages global style guide?
Yeah, and that allows them to just write "all Go source files must conform to the format outputted by the gofmt tool" under "Formatting" and move on to the stuff for which a style guide is still needed...
Re: Go Style
#8I found this "best practice" curious to read:
> The standard net/http server violates this advice and recovers panics from request handlers. Consensus among experienced Go engineers is that this was a historical mistake. If you sample server logs from application servers in other languages, it is common to find large stacktraces that are left unhandled. Avoid this pitfall in your servers.
I don't think I've ever seen a server library — HTTP or otherwise — that didn't have a top-level "catch all exceptions" or "recover from panic" step in place, so that if there's a problem, it can return 500 (or the Internal Server Error equivalent) to the user and then carry on serving other requests.
My reasoning is that any panic-worthy programming error is almost certainly going to be in the "business logic" part of the server, rather than the protocol-parsing "deal with the network" part, and thus, recoving from a panic caused by processing a request is "safe". One incoming request could cause a panic, but the next request may touch completely unrelated parts of the program, and still be processed as normal. Furthermore, returning a 500 error but having nobody read the stacktrace is bad, yes, but it's way, way, way better than having your server crash meaning nobody can use it ever.
Oh wait, is the assumption here that your service is being run under Borg and has another 1000 instances running ready to jump in and take the crashed one's place? Is this another case of Google forgetting that people use Go outside of Google, or am I reading too much into this?
Re: Go Style
#9Isn’t the point of go is that go fmt follows the languages global style guide?
That is just a formatting guide. How to write spaces, newlines, semicolons.
Go fmt doesn't change anything that is not formatting.
Re: Go Style
#10> Name constants based on their role, not their values. If a constant does not have a role apart from its value, then it is unnecessary to define it as a constant.
This breaks the linter in most cases because "magic numbers". Like having to declare a constant for the number of cents in a euro/dollar.
I think Google are right in this case, and linters need to be smarter.