每门开发语言都会有其特有的风格规范（亦或指南），开发者遵循规范能带来显著收益，有效促进团队协作、减少 bug 错误、降低维护成本等。

Google 开源的 Google Style Guides （https://google.github.io/styleguide/）为多种编程语言提供了风格规范，包括 C++、Java、Python、JavaScript 等。在 2022 年 11 月，Go 语言风格规范（https://google.github.io/styleguide/go/index）也终于得到开源。

Google 发布的 Go 语言风格规范一共包括四部分内容。

• 概述篇：https://google.github.io/styleguide/go/index

• 指南篇：https://google.github.io/styleguide/go/guide

• 决策篇：https://google.github.io/styleguide/go/decisions

• 最佳实践篇：https://google.github.io/styleguide/go/best-practices

如果你所在的团体还未形成一套系统的 Go 风格规范，不妨参考这份指南。

本公众号将持续更新该规范的中文译本。本文以下内容将是该系列的第一部分，即【概述篇】。

关于

Go 语言风格规范和附录文档整理了当前编写易读且正宗的 Go 的最佳方法。遵循编程指南不是绝对的，因为这些文档不可能面面俱到。我们的目的是尽可能减少编写可读性 Go 代码试错成本，新手们可以避免常见错误。这份规范还为那些在 Google 内部 Go 代码审查的人提供统一的风格指导。

文档

1.【指南篇】概述了 Google Go 代码风格的基础。该文档是权威的，并用作【决策篇】和【最佳实践篇】中建议的依据。

2.【决策篇】是一个更详细的文档，它总结了关于特定风格点的决策，并适当地讨论了这些决策背后的原因。

这些决策可能会因为新数据类型、新语言特性、新标准库或新的模型而改变，但我们并不需要 Google 的 Go 程序员与该文档实时一致。

3.【最佳实践篇】记录了一些随着时间的推移而演变的模式，这些模式解决了常见问题，易于阅读，高鲁棒性也满足了代码可维护性要求。

这些最佳实践并不权威，但我们鼓励 Google 的 Go 程序员尽可能使用它们，以保持代码库的统一。

这些文档的目的：

• 就权衡可替代编码风格的一套原则达成一致。

• 编纂 Go 编码风格已解决的问题。

• 记录并提供正宗 Go 代码的规范示例。

• 记录各种编码风格决策的利弊。

• 帮助减少 Go 可读性代码审查中的意外。

• 帮助代码可读性代码审查者使用一致的术语和指南。

非这些文档的目的：

• 成为代码可读性审查者在代码评论下的详尽清单。

• 列出所有规则，并希望每个人都记住并始终遵守。

• 失去对语言特性和风格使用的良好判断。

• 为消除代码风格差异而成为大规模修改的借口。

各 Go 程序员之间，以及各团队的代码库之间总会存在差异。然而，为了符合 Google 和 Alphabet 的最大利益，我们的代码库尽可能得保持一致，因此，请自由地对你认为合适的编码风格进行改进，发现不符合风格规范的行为时，你也不需要过于吹毛求疵。特别是，这些文档可能会随着时间而改变，它不应该是导致现有代码库需要额外改动的理由；使用最新的最佳实践去编写新代码就足够了，随着时间的推移这部分内容就已经被解决了。

重要的是要认识到代码风格问题本质上是个人的，并且总是存在固有的权衡。这些文档中的大部分指导都是主观的，但就像gofmt一样，它们提供的统一性具有重要价值。因此，这些编码风格建议不会在未经适当讨论的情况下修改。我们鼓励 Google 的 Go 程序员遵循这些编程风格规范，即使他们可能对某些内容并不同意。

定义

整个代码风格系列文档中使用的一些词语，定义如下

Canonical（权威的）：建立规范且持久的规则。

在这些文档中，“权威的”用于描述被认为是所有代码（旧的和新的）都应该遵循的标准，并且语句不会随着时间的推移而发生重大变化。权威的文档中的原则应该被代码作者和审查人理解，权威的文档中包含的所有内容都必须达到高标准。因此，与非权威的文档相比，权威的文档通常更短，并且规定的代码风格元素也更少。

https://google.github.io/styleguide/go#canonical

Normative（规范的）：旨在建立一致性。

在这些文档中，“规范的”用于描述 Go 代码审查者都同意的代码风格元素，以确保他们在提供建议、术语和理由时能保持一致。这些风格元素可能会随着时间的推移而发生变化，这些文档将反映这些变化，以便代码审查者可以保持一致与最新。Go 代码开发者不用熟悉这些规范性文档，但这些文档应该被代码审查者用作可读性审查的参考。

https://google.github.io/styleguide/go#normative

Idiomatic（正宗的）：常见且熟悉的。

在这些文档中，“正宗的”用于指代 Go 代码中普遍存在的东西，并已成为一种易于识别的熟悉模式。一般而言，如果两种模式在上下文中起到相同的目的，那么正宗的模式应该优先于非正宗的模式，因为这是代码读者最熟悉的模式。

https://google.github.io/styleguide/go#idiomatic

附加参考

本指南假定读者熟悉 Effective Go（https://go.dev/doc/effective_go），因为它为整个 Go 社区的 Go 代码提供了一个共同的基线。

下面是一些额外的资源，供那些希望自学 Go 代码风格的人，和为代码审查者提供更多能使用的评论意见依据链接。我们并不期望 Go 代码可读性的参与者熟悉这些资源，但他们可能会作为代码可读性审查的背景出现。

外部参考

• [Go 语言规范] https://go.dev/ref/spec
• [Go 高频问题问答] https://go.dev/doc/faq
• [Go内存模型] https://go.dev/ref/mem
• [Go数据结构] https://research.swtch.com/godata
• [Go接口] https://research.swtch.com/interfaces
• [Go谚语] https://go-proverbs.github.io/
• Go 小技巧 - 敬请关注.

相关的“厕所测试“文档

• [TotT: Identifier Naming] https://testing.googleblog.com/2017/10/code-health-identifiernamingpostforworl.html
• [TotT: Testing State vs. Testing Interactions] https://testing.googleblog.com/2013/03/testing-on-toilet-testing-state-vs.html
• [TotT: Effective Testing] https://testing.googleblog.com/2014/05/testing-on-toilet-effective-testing.html
• [TotT: Risk-driven Testing] https://testing.googleblog.com/2014/05/testing-on-toilet-risk-driven-testing.html
• [TotT: Change-detector Tests Considered Harmful] https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html

额外的外部著作

• [Go教条] https://research.swtch.com/dogma

• [少即是多] https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html

• [埃斯梅拉达的想象力] https://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html

• [用于解析的正则表达式] https://commandcenter.blogspot.com/2011/08/regular-expressions-in-lexing-and.html

• [Gofmt 的风格没有人喜欢，但 Gofmt 却是每个人的最爱] https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s (YouTube)