每门开发语言都会有其特有的风格规范(亦或指南),开发者遵循规范能带来显著收益,有效促进团队协作、减少 bug 错误、降低维护成本等。
Google 开源的 Google Style Guides (https://google.github.io/styleguide/)为多种编程语言提供了风格规范,包括 C++、Java、Python、JavaScript 等。在 2022 年 11 月,Go 语言风格规范(https://google.github.io/styleguide/go/index)也终于得到开源。
如果你所在的团体还未形成一套系统的 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)