Google’s Go style guide published
Gaal Yahas
Hi Go community,
We've released Google's style documentation for Go: https://google.github.io/styleguide/go/.
These are the house rules that Google uses to write Go code internally.
The intention in publishing this is to help collaborators on Google open source projects, and to provide a starting place or reference for other groups to create their own. We hope that people may find it useful if they work on other codebases, but there is no expectation that Go programs at large follow it exactly: although the Go language project is of course led by Google, this guide is not specifically endorsed by the Go project.
The style documentation has its own overview section, but I thought it might be useful to include a brief FAQ.
Q: Why a style guide? Let me just gofmt.
A: Google operates a huge monorepo, with many Go programmers writing to it. Large codebases benefit from uniformity and developing idioms that minimize certain bugs and readability problems.
Q: Do I need to adopt these style rules?
A: Code checked into the main Google codebase generally needs to follow these guidelines. If you contribute to a Google open source project, you can save review churn by using this style.
Q: Who wrote this? What is the relationship to https://github.com/golang/go/wiki/CodeReviewComments/?
A: Dozens of people over at least a decade have contributed to these guidelines. A lot of the early text was written by the fledgling Go team, copied over to the wiki page (which is why there's a lot of overlap). The Go Readability team maintains the document and updates the advice when there's internal consensus to do so.
Q: What is readability?
A: It’s a program to share best practices. You can read more about how Google maintains a large codebase with many contributors in the book Software Engineering at Google (read online).
Q: I can't believe you want me to do X! I've been doing Y and it's better.
A: It may be that Y is better in your project. Our requirements may be different from yours.
Remember also that some conventions can be valuable even if they represent a choice that is mostly arbitrary. For example, using “got before want” probably isn’t a lot different from the other way around, but either one is better than every line of code doing something new.
Q: This is long! Do I really have to read all of it?
A: The style documentation is deliberately split into three parts. We advise Go programmers at Google to take the core Style Guide text seriously, and pick up more specific points as they go through the readability program.
Q: Will you take my pull request?
A: This repo is not accepting external contributions, sorry. If you spot an error such as a dead link or a typo, we welcome bug reports.