?每門開發語言都會有其特有的風格規范（亦或指南），開發者遵循規范能帶來顯著收益，有效促進團隊協作、減少 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)?