原文鏈接：https://mp.weixin.qq.com/s/nA26g46tM_hu-khaGYniAQ

文章目錄

Uber Go語言編碼規範

Go語言中文網 20191014

Uber是世界領先的生活出行服務提供商，也是Go語言的早期adopter，根據Uber工程博客的內容，大致可以判斷出Go語言在Uber內部扮演了十分重要的角色。Uber內部的Go語言工程實踐也是碩果累累，有大量Go實現的內部工具被Uber開源到github上，諸如被Gopher圈熟知的zap、jaeger等。2018年年末Uber將內部的Go風格規範開源到github，經過一年的積累和更新，該規範已經初具規模，並受到廣大Gopher的關注。本文是該規範的中文版本，並”夾帶“了部分筆者的點評，希望對國內Gopher有所幫助。

注：該版本基於commit 3baa2bd翻譯，後續不會持續更新。

一. 介紹

樣式(style)是支配我們代碼的慣例。術語“樣式”有點用詞不當，因爲這些約定涵蓋的範圍不限於由gofmt替我們處理的源文件格式。

本指南的目的是通過詳細描述在Uber編寫Go代碼的注意事項來管理這種複雜性。這些規則的存在是爲了使代碼庫易於管理，同時仍然允許工程師更有效地使用Go語言功能。

該指南最初由Prashant Varanasi和Simon Newton編寫，目的是使一些同事能快速使用Go。多年來，該指南已根據其他人的反饋進行了修改。

本文檔記錄了我們在Uber遵循的Go代碼中的慣用約定。其中許多是Go的通用準則，而其他擴展準則依賴於下面外部的指南：

Effective Go
The Go common mistakes guide

所有代碼都應該通過golint和go vet的檢查並無錯誤。我們建議您將編輯器設置爲：

保存時運行goimports
運行golint和go vet檢查源碼

您可以在以下Go編輯器工具支持頁面中找到更爲詳細的信息：https : //github.com/golang/go/wiki/IDEsAndTextEditorPlugins

二. 指導原則

指向interface的指針

您幾乎不需要指向接口類型的指針。您應該將接口作爲值進行傳遞，在這樣的傳遞過程中，實質上傳遞的底層數據仍然可以是指針。

接口實質上在底層用兩個字段表示：

一個指向某些特定類型信息的指針。您可以將其視爲“類型”。
數據指針。如果存儲的數據是指針，則直接存儲。如果存儲的數據是一個值，則存儲指向該值的指針。

如果要接口方法修改底層數據，則必須用指向目標對象的指針賦值給接口類型變量(譯註：感覺原指南中這裏表達過於簡略，不是很清晰，因此在翻譯時增加了自己的一些詮釋)。

接收器(receiver)與接口

使用值接收器的方法既可以通過值調用，也可以通過指針調用。

例如:

type S struct {
  data string
}

func (s S) Read() string {
  return s.data
}

func (s *S) Write(str string) {
  s.data = str
}

sVals := map[int]S{1: {"A"}}

// 你只能通過值調用Read
sVals[1].Read()

// 下面無法通過編譯：
//  sVals[1].Write("test")

sPtrs := map[int]*S{1: {"A"}}

// 通過指針既可以調用Read，也可以調用Write方法
sPtrs[1].Read()
sPtrs[1].Write("test")

同樣，即使該方法具有值接收器，也可以通過指針來滿足接口。

type F interface {
  f()
}

type S1 struct{}

func (s S1) f() {}

type S2 struct{}

func (s *S2) f() {}

s1Val := S1{}
s1Ptr := &S1{}
s2Val := S2{}
s2Ptr := &S2{}

var i F
i = s1Val
i = s1Ptr
i = s2Ptr

// 下面代碼無法通過編譯。因爲s2Val是一個值，而S2的f方法中沒有使用值接收器
//   i = s2Val

《Effective Go》中有一段關於"pointers vs values"的精彩講解。

譯註：關於Go類型的method集合的問題，在我之前的文章《關於Go，你可能不注意的7件事》中有詳盡說明。

零值Mutex是有效的

sync.Mutex和sync.RWMutex是有效的。因此你幾乎不需要一個指向mutex的指針。

Bad:

mu := new(sync.Mutex)
mu.Lock()

vs.

Good:

var mu sync.Mutex
mu.Lock()

如果你使用結構體指針，mutex可以非指針形式作爲結構體的組成字段，或者更好的方式是直接嵌入到結構體中。

如果是私有結構體類型或是要實現Mutex接口的類型，我們可以使用嵌入mutex的方法：

type smap struct {
  sync.Mutex

  data map[string]string
}

func newSMap() *smap {
  return &smap{
    data: make(map[string]string),
  }
}

func (m *smap) Get(k string) string {
  m.Lock()
  defer m.Unlock()

  return m.data[k]
}

對於導出類型，請使用私有鎖：

type SMap struct {
  mu sync.Mutex

  data map[string]string
}

func NewSMap() *SMap {
  return &SMap{
    data: make(map[string]string),
  }
}

func (m *SMap) Get(k string) string {
  m.mu.Lock()
  defer m.mu.Unlock()

  return m.data[k]
}

在邊界處拷貝Slices和Maps

slices和maps包含了指向底層數據的指針，因此在需要複製它們時要特別注意。

接收Slices和Maps

請記住，當map或slice作爲函數參數傳入時，如果您存儲了對它們的引用，則用戶可以對其進行修改。

Bad

func (d *Driver) SetTrips(trips []Trip) {
  d.trips = trips
}

trips := ...
d1.SetTrips(trips)

// 你是要修改d1.trips嗎？
trips[0] = ...

vs.

Good

func (d *Driver) SetTrips(trips []Trip) {
  d.trips = make([]Trip, len(trips))
  copy(d.trips, trips)
}

trips := ...
d1.SetTrips(trips)

// 這裏我們修改trips[0]，但不會影響到d1.trips
trips[0] = ...

返回slices或maps

同樣，請注意用戶對暴露內部狀態的map或slice的修改。

Bad

type Stats struct {
  sync.Mutex

  counters map[string]int
}

// Snapshot返回當前狀態
func (s *Stats) Snapshot() map[string]int {
  s.Lock()
  defer s.Unlock()

  return s.counters
}

// snapshot不再受到鎖的保護
snapshot := stats.Snapshot()

vs.

Good

type Stats struct {
  sync.Mutex

  counters map[string]int
}

func (s *Stats) Snapshot() map[string]int {
  s.Lock()
  defer s.Unlock()

  result := make(map[string]int, len(s.counters))
  for k, v := range s.counters {
    result[k] = v
  }
  return result
}

// snapshot現在是一個拷貝
snapshot := stats.Snapshot()

使用defer做清理

使用defer清理資源，諸如文件和鎖。

Bad

p.Lock()
if p.count < 10 {
  p.Unlock()
  return p.count
}

p.count++
newCount := p.count
p.Unlock()

return newCount

// 當有多個return分支時，很容易遺忘unlock

vs.

Good

p.Lock()
defer p.Unlock()

if p.count < 10 {
  return p.count
}

p.count++
return p.count

// 更可讀

Defer的開銷非常小，只有在您可以證明函數執行時間處於納秒級的程度時，才應避免這樣做。使用defer提升可讀性是值得的，因爲使用它們的成本微不足道。尤其適用於那些不僅僅是簡單內存訪問的較大的方法，在這些方法中其他計算的資源消耗遠超過defer。

Channel的size要麼是1，要麼是無緩衝的

channel通常size應爲1或是無緩衝的。默認情況下，channel是無緩衝的，其size爲零。任何其他尺寸都必須經過嚴格的審查。考慮如何確定大小，是什麼阻止了channel在負載下被填滿並阻止寫入，以及發生這種情況時發生了什麼。

Bad

// 應該足以滿足任何人
c := make(chan int, 64)

vs.

Good

// 大小：1
c := make(chan int, 1) // 或
// 無緩衝channel，大小爲0
c := make(chan int)

枚舉從1開始

在Go中引入枚舉的標準方法是聲明一個自定義類型和一個使用了iota的const組。由於變量的默認值爲0，因此通常應以非零值開頭枚舉。

Bad

type Operation int

const (
  Add Operation = iota
  Subtract
  Multiply
)

// Add=0, Subtract=1, Multiply=2

vs.

Good

type Operation int

const (
  Add Operation = iota + 1
  Subtract
  Multiply
)

// Add=1, Subtract=2, Multiply=3

在某些情況下，使用零值是有意義的(枚舉從零開始)，例如，當零值是理想的默認行爲時。

type LogOutput int

const (
  LogToStdout LogOutput = iota
  LogToFile
  LogToRemote
)

// LogToStdout=0, LogToFile=1, LogToRemote=2

錯誤類型

Go中有多種聲明錯誤（Error)的選項：

errors.New 對於簡單靜態字符串的錯誤
fmt.Errorf 用於格式化的錯誤字符串
實現Error()方法的自定義類型
使用 “pkg/errors”.Wrap的wrapped error

返回錯誤時，請考慮以下因素以確定最佳選擇：

這是一個不需要額外信息的簡單錯誤嗎？如果是這樣，errors.New 就足夠了。
客戶需要檢測並處理此錯誤嗎？如果是這樣，則應使用自定義類型並實現該Error()方法。
您是否正在傳播下游函數返回的錯誤？如果是這樣，請查看本文後面有關錯誤包裝(Error Wrap)部分的內容
否則，fmt.Errorf就可以。

如果客戶端需要檢測錯誤，並且您已使用創建了一個簡單的錯誤errors.New，請使用一個錯誤變量(sentinel error )。

Bad

// package foo

func Open() error {
  return errors.New("could not open")
}

// package bar

func use() {
  if err := foo.Open(); err != nil {
    if err.Error() == "could not open" {
      // handle
    } else {
      panic("unknown error")
    }
  }
}

vs.

Good

// package foo

var ErrCouldNotOpen = errors.New("could not open")

func Open() error {
  return ErrCouldNotOpen
}

// package bar

if err := foo.Open(); err != nil {
  if err == foo.ErrCouldNotOpen {
    // handle
  } else {
    panic("unknown error")
  }
}

如果您有可能需要客戶端檢測的錯誤，並且想向其中添加更多信息（例如，它不是靜態字符串），則應使用自定義類型。

Bad

func open(file string) error {
  return fmt.Errorf("file %q not found", file)
}

func use() {
  if err := open(); err != nil {
    if strings.Contains(err.Error(), "not found") {
      // handle
    } else {
      panic("unknown error")
    }
  }
}

vs.

Good

type errNotFound struct {
  file string
}

func (e errNotFound) Error() string {
  return fmt.Sprintf("file %q not found", e.file)
}

func open(file string) error {
  return errNotFound{file: file}
}

func use() {
  if err := open(); err != nil {
    if _, ok := err.(errNotFound); ok {
      // handle
    } else {
      panic("unknown error")
    }
  }
}

直接導出自定義錯誤類型時要小心，因爲它們已成爲程序包公共API的一部分。最好公開匹配器功能以檢查錯誤。

// package foo

type errNotFound struct {
  file string
}

func (e errNotFound) Error() string {
  return fmt.Sprintf("file %q not found", e.file)
}

func IsNotFoundError(err error) bool {
  _, ok := err.(errNotFound)
  return ok
}

func Open(file string) error {
  return errNotFound{file: file}
}

// package bar

if err := foo.Open("foo"); err != nil {
  if foo.IsNotFoundError(err) {
    // handle
  } else {
    panic("unknown error")
  }
}

錯誤包裝(Error Wrapping)

一個(函數/方法)調用失敗時，有三種主要的錯誤傳播方式：

如果沒有要添加的其他上下文，並且您想要維護原始錯誤類型，則返回原始錯誤。
添加上下文，使用"pkg/errors".Wrap以便錯誤消息提供更多上下文，“pkg/errors”.Cause可用於提取原始錯誤。
使用fmt.Errorf，如果調用者不需要檢測或處理的特定錯誤情況。

建議在可能的地方添加上下文，以使您獲得諸如“調用服務foo：連接被拒絕”之類的更有用的錯誤，而不是諸如“連接被拒絕”之類的模糊錯誤。

在將上下文添加到返回的錯誤時，請避免使用“ failed to”之類的短語來保持上下文簡潔，這些短語會陳述明顯的內容，並隨着錯誤在堆棧中的滲透而逐漸堆積：

Bad

s, err := store.New()
if err != nil {
    return fmt.Errorf(
        "failed to create new store: %s", err)
}

failed to x: failed to y: failed to create new store: the error

vs.

Good

s, err := store.New()
if err != nil {
    return fmt.Errorf(
        "new store: %s", err)
}

x: y: new store: the error

但是，一旦將錯誤發送到另一個系統，就應該明確消息是錯誤消息（例如使用err標記，或在日誌中以"Failed"爲前綴）。

另請參見Don’t just check errors, handle them gracefully.

處理類型斷言失敗

類型斷言的單個返回值形式針對不正確的類型將產生panic。因此，請始終使用“comma ok”的慣用法。

Bad

t := i.(string)

vs.

Good

t, ok := i.(string)
if !ok {
  // 優雅地處理錯誤
}

不要panic

在生產環境中運行的代碼必須避免出現panic。panic是級聯失敗的主要根源。如果發生錯誤，該函數必須返回錯誤，並允許調用方決定如何處理它。

Bad

func foo(bar string) {
  if len(bar) == 0 {
    panic("bar must not be empty")
  }
  // ...
}

func main() {
  if len(os.Args) != 2 {
    fmt.Println("USAGE: foo <bar>")
    os.Exit(1)
  }
  foo(os.Args[1])
}

vs.

Good

func foo(bar string) error {
  if len(bar) == 0
    return errors.New("bar must not be empty")
  }
  // ...
  return nil
}

func main() {
  if len(os.Args) != 2 {
    fmt.Println("USAGE: foo <bar>")
    os.Exit(1)
  }
  if err := foo(os.Args[1]); err != nil {
    panic(err)
  }
}

panic/recover不是錯誤處理策略。僅當發生不可恢復的事情（例如:nil引用）時，程序才必須panic。程序初始化是一個例外：程序啓動時應使程序中止的不良情況可能會引起panic。

var _statusTemplate = template.Must(template.New("name").Parse("_statusHTML"))

即便是在test中，也優先使用t.Fatal或t.FailNow來標記test是失敗的，而不是panic。

Bad

// func TestFoo(t *testing.T)

f, err := ioutil.TempFile("", "test")
if err != nil {
  panic("failed to set up test")
}

vs.

Good

// func TestFoo(t *testing.T)

f, err := ioutil.TempFile("", "test")
if err != nil {
  t.Fatal("failed to set up test")
}

使用go.uber.org/atomic

使用sync/atomic包的原子操作對原始類型（int32，int64等）進行操作(譯註：指atomic包的方法名中均使用原始類型名，如SwapInt32等)，因此很容易忘記使用原子操作來讀取或修改變量。

go.uber.org/atomic通過隱藏基礎類型爲這些操作增加了類型安全性。此外，它包括一個方便的atomic.Bool類型。

Bad

type foo struct {
  running int32  // atomic
}

func (f* foo) start() {
  if atomic.SwapInt32(&f.running, 1) == 1 {
     // already running…
     return
  }
  // start the Foo
}

func (f *foo) isRunning() bool {
  return f.running == 1  // race!
}

vs.

Good

type foo struct {
  running atomic.Bool
}

func (f *foo) start() {
  if f.running.Swap(true) {
     // already running…
     return
  }
  // start the Foo
}

func (f *foo) isRunning() bool {
  return f.running.Load()
}

三. 性能

性能方面的特定準則，適用於熱路徑。

優先使用strconv而不是fmt

將原語轉換爲字符串或從字符串轉換時，strconv速度比fmt快。

Bad

for i := 0; i < b.N; i++ {
  s := fmt.Sprint(rand.Int())
}

BenchmarkFmtSprint-4    143 ns/op    2 allocs/op

vs.

Good

for i := 0; i < b.N; i++ {
  s := strconv.Itoa(rand.Int())
}

BenchmarkStrconv-4    64.2 ns/op    1 allocs/op

避免字符串到字節的轉換

不要反覆從固定字符串創建字節slice。相反，請執行一次轉換並捕獲結果。

Bad

for i := 0; i < b.N; i++ {
  w.Write([]byte("Hello world"))
}

BenchmarkBad-4   50000000   22.2 ns/op

vs.

Good

data := []byte("Hello world")
for i := 0; i < b.N; i++ {
  w.Write(data)
}

BenchmarkGood-4  500000000   3.25 ns/op

四. 樣式

相似的聲明放在一組

Go語言支持將相似的聲明放在一個組內：

Bad

import "a"
import "b"

vs.

Good

import (
  "a"
  "b"
)

這同樣適用於常量、變量和類型聲明：

Bad

const a = 1
const b = 2



var a = 1
var b = 2



type Area float64
type Volume float64

vs.

Good

const (
  a = 1
  b = 2
)

var (
  a = 1
  b = 2
)

type (
  Area float64
  Volume float64
)

僅將相關的聲明放在一組。不要將不相關的聲明放在一組。

Bad

type Operation int

const (
  Add Operation = iota + 1
  Subtract
  Multiply
  ENV_VAR = "MY_ENV"
)

vs.

Good

type Operation int

const (
  Add Operation = iota + 1
  Subtract
  Multiply
)

const ENV_VAR = "MY_ENV"

分組使用的位置沒有限制，例如：你可以在函數內部使用它們：

Bad

func f() string {
  var red = color.New(0xff0000)
  var green = color.New(0x00ff00)
  var blue = color.New(0x0000ff)

  ...
}

vs.

Good

func f() string {
  var (
    red   = color.New(0xff0000)
    green = color.New(0x00ff00)
    blue  = color.New(0x0000ff)
  )

  ...
}

import組內的包導入順序

應該有兩類導入組：

標準庫
其他一切

默認情況下，這是goimports應用的分組。

Bad

import (
  "fmt"
  "os"
  "go.uber.org/atomic"
  "golang.org/x/sync/errgroup"
)

vs.

Good

import (
  "fmt"
  "os"

  "go.uber.org/atomic"
  "golang.org/x/sync/errgroup"
)

包名

當命名包時，請按下面規則選擇一個名稱：

全部小寫。沒有大寫或下劃線。
大多數使用命名導入的情況下，不需要重命名。
簡短而簡潔。請記住，在每個使用的地方都完整標識了該名稱。
不用複數。例如net/url，而不是net/urls。
不是“common”，“util”，“shared”或“lib”。這些是不好的，信息量不足的名稱。

另請參閱Go包名稱和Go包樣式指南。

函數名

我們遵循Go社區關於使用MixedCaps作爲函數名的約定。有一個例外，爲了對相關的測試用例進行分組，函數名可能包含下劃線，如: TestMyFunction_WhatIsBeingTested。

包導入別名

如果程序包名稱與導入路徑的最後一個元素不匹配，則必須使用導入別名。

import (
  "net/http"

  client "example.com/client-go"
  trace "example.com/trace/v2"
)

在所有其他情況下，除非導入之間有直接衝突，否則應避免導入別名。

Bad

import (
  "fmt"
  "os"


  nettrace "golang.net/x/trace"
)

vs.

Good

import (
  "fmt"
  "os"
  "runtime/trace"

  nettrace "golang.net/x/trace"
)

函數分組與順序

函數應按粗略的調用順序排序。
同一文件中的函數應按接收者分組。

因此，導出的函數應先出現在文件中，放在struct、const和var定義的後面。

在定義類型之後，但在接收者的其餘方法之前，可能會出現一個newXYZ()/ NewXYZ()。

由於函數是按接收者分組的，因此普通工具函數應在文件末尾出現。

Bad

func (s *something) Cost() {
  return calcCost(s.weights)
}

type something struct{ ... }

func calcCost(n int[]) int {...}

func (s *something) Stop() {...}

func newSomething() *something {
    return &something{}
}

vs.

Good

type something struct{ ... }

func newSomething() *something {
    return &something{}
}

func (s *something) Cost() {
  return calcCost(s.weights)
}

func (s *something) Stop() {...}

func calcCost(n int[]) int {...}

減少嵌套

代碼應通過儘可能先處理錯誤情況/特殊情況並儘早返回或繼續循環來減少嵌套。減少嵌套多個級別的代碼的代碼量。

Bad

for _, v := range data {
  if v.F1 == 1 {
    v = process(v)
    if err := v.Call(); err == nil {
      v.Send()
    } else {
      return err
    }
  } else {
    log.Printf("Invalid v: %v", v)
  }
}

vs.

Good

for _, v := range data {
  if v.F1 != 1 {
    log.Printf("Invalid v: %v", v)
    continue
  }

  v = process(v)
  if err := v.Call(); err != nil {
    return err
  }
  v.Send()
}

不必要的else

如果在if的兩個分支中都設置了變量，則可以將其替換爲單個if。

Bad

var a int
if b {
  a = 100
} else {
  a = 10
}

vs.

Good

a := 10
if b {
  a = 100
}

頂層變量聲明

在頂層，使用標準var關鍵字。請勿指定類型，除非它與表達式的類型不同。

Bad

var _s string = F()

func F() string { return "A" }

vs.

Good

var _s = F()
// 由於F已經明確了返回一個字符串類型，因此我們沒有必要顯式指定_s的類型

func F() string { return "A" }

如果表達式的類型與所需的類型不完全匹配，請指定類型。

type myError struct{}

func (myError) Error() string { return "error" }

func F() myError { return myError{} }

var _e error = F()
// F返回一個myError類型的實例，但是我們要error類型

對於未導出的頂層常量和變量，使用_作爲前綴

譯註：這個是Uber內部的慣用法，目前看並不普適。

在未導出的頂級vars和consts，前面加上前綴_，以使它們在使用時明確表示它們是全局符號。

例外：未導出的錯誤值，應以err開頭。

基本依據：頂級變量和常量具有包範圍作用域。使用通用名稱可能很容易在其他文件中意外使用錯誤的值。

Bad

// foo.go

const (
  defaultPort = 8080
  defaultUser = "user"
)

// bar.go

func Bar() {
  defaultPort := 9090
  ...
  fmt.Println("Default port", defaultPort)

  // We will not see a compile error if the first line of
  // Bar() is deleted.
}

vs.

Good

// foo.go

const (
  _defaultPort = 8080
  _defaultUser = "user"
)

結構體中的嵌入

嵌入式類型（例如mutex）應位於結構體內的字段列表的頂部，並且必須有一個空行將嵌入式字段與常規字段分隔開。

Bad

type Client struct {
  version int
  http.Client
}

vs.

Good

type Client struct {
  http.Client

  version int
}

使用字段名初始化結構體

初始化結構體時，幾乎始終應該指定字段名稱。現在由go vet強制執行。

Bad

k := User{"John", "Doe", true}

vs.

Good

k := User{
    FirstName: "John",
    LastName: "Doe",
    Admin: true,
}

例外：如果有3個或更少的字段，則可以在測試表中省略字段名稱。

tests := []struct{
}{
  op Operation
  want string
}{
  {Add, "add"},
  {Subtract, "subtract"},
}

本地變量聲明

如果將變量明確設置爲某個值，則應使用短變量聲明形式（:=）。

Bad

var s = "foo"

vs.

Good

s := "foo"

但是，在某些情況下，var 使用關鍵字時默認值會更清晰。例如，聲明空切片。

Bad

func f(list []int) {
  filtered := []int{}
  for _, v := range list {
    if v > 10 {
      filtered = append(filtered, v)
    }
  }
}

vs.

Good

func f(list []int) {
  var filtered []int
  for _, v := range list {
    if v > 10 {
      filtered = append(filtered, v)
    }
  }
}

nil是一個有效的slice

nil是一個有效的長度爲0的slice，這意味着：

您不應明確返回長度爲零的切片。返回nil 來代替。

Bad

if x == "" {
  return []int{}
}

vs.

Good

if x == "" {
  return nil
}

要檢查切片是否爲空，請始終使用len(s) == 0。不要檢查 nil。

Bad

func isEmpty(s []string) bool {
  return s == nil
}

vs.

Good

func isEmpty(s []string) bool {
  return len(s) == 0
}

零值切片可立即使用，無需調用make創建。

Bad

nums := []int{}
// or, nums := make([]int)

if add1 {
  nums = append(nums, 1)
}

if add2 {
  nums = append(nums, 2)
}

vs.

Good

var nums []int

if add1 {
  nums = append(nums, 1)
}

if add2 {
  nums = append(nums, 2)
}

縮小變量作用域

如果有可能，儘量縮小變量作用範圍。除非它與減少嵌套的規則衝突。

Bad

err := ioutil.WriteFile(name, data, 0644)
if err != nil {
    return err
}

vs.

Good

if err := ioutil.WriteFile(name, data, 0644); err != nil {
    return err
}

如果需要在if之外使用函數調用的結果，則不應嘗試縮小範圍。

Bad

if data, err := ioutil.ReadFile(name); err == nil {
  err = cfg.Decode(data)
  if err != nil {
    return err
  }

  fmt.Println(cfg)
  return nil
} else {
  return err
}

vs.

Good

data, err := ioutil.ReadFile(name)
if err != nil {
   return err
}

if err := cfg.Decode(data); err != nil {
  return err
}

fmt.Println(cfg)
return nil

避免裸參數

函數調用中的裸參數可能會損害可讀性。當參數名稱的含義不明顯時，請爲參數添加C樣式註釋（/* … */）。

Bad

// func printInfo(name string, isLocal, done bool)

printInfo("foo", true, true)

vs.

Good

// func printInfo(name string, isLocal, done bool)

printInfo("foo", true /* isLocal */, true /* done */)

更好的作法是，將裸bool類型替換爲自定義類型，以獲得更易讀和類型安全的代碼。將來，該參數不僅允許兩個狀態（true/false）。

type Region int

const (
  UnknownRegion Region = iota
  Local
)

type Status int

const (
  StatusReady = iota + 1
  StatusDone
  // Maybe we will have a StatusInProgress in the future.
)

func printInfo(name string, region Region, status Status)

使用原始字符串字面值，避免轉義

Go支持原始字符串字面值，可以跨越多行幷包含引號。使用這些字符串可以避免更難閱讀的手工轉義的字符串。

Bad

wantError := "unknown name:\"test\""

vs.

Good

wantError := `unknown error:"test"`

初始化結構體引用

在初始化結構引用時，請使用&T{}代替new(T)，以使其與結構體初始化一致。

Bad

sval := T{Name: "foo"}

// 不一致
sptr := new(T)
sptr.Name = "bar"

vs.

Good

sval := T{Name: "foo"}

sptr := &T{Name: "bar"}

格式化字符串放在Printf外部

如果你爲Printf-style函數聲明格式字符串，請將格式化字符串放在外面，並將其設置爲const常量。

這有助於go vet對格式字符串執行靜態分析。

Bad

msg := "unexpected values %v, %v\n"
fmt.Printf(msg, 1, 2)

vs.

Good

const msg = "unexpected values %v, %v\n"
fmt.Printf(msg, 1, 2)

命名Printf樣式的函數

聲明Printf-style函數時，請確保go vet可以檢測到它並檢查格式字符串。

這意味着您應儘可能使用預定義的Printf-style函數名稱。go vet將默認檢查這些。有關更多信息，請參見Printf系列。

如果不能使用預定義的名稱，請以f結束選擇的名稱：Wrapf，而不是Wrap。go vet可以要求檢查特定的Printf樣式名稱，但名稱必須以f結尾。

另請參閱"go vet：Printf家族檢查"。

五. 模式

測試表

在覈心測試邏輯重複時，將表驅動測試與子測試一起使用，以避免重複代碼。

Bad

// func TestSplitHostPort(t *testing.T)

host, port, err := net.SplitHostPort("192.0.2.0:8000")
require.NoError(t, err)
assert.Equal(t, "192.0.2.0", host)
assert.Equal(t, "8000", port)

host, port, err = net.SplitHostPort("192.0.2.0:http")
require.NoError(t, err)
assert.Equal(t, "192.0.2.0", host)
assert.Equal(t, "http", port)

host, port, err = net.SplitHostPort(":8000")
require.NoError(t, err)
assert.Equal(t, "", host)
assert.Equal(t, "8000", port)

host, port, err = net.SplitHostPort("1:8")
require.NoError(t, err)
assert.Equal(t, "1", host)
assert.Equal(t, "8", port)

vs.

Good

// func TestSplitHostPort(t *testing.T)

tests := []struct{
  give     string
  wantHost string
  wantPort string
}{
  {
    give:     "192.0.2.0:8000",
    wantHost: "192.0.2.0",
    wantPort: "8000",
  },
  {
    give:     "192.0.2.0:http",
    wantHost: "192.0.2.0",
    wantPort: "http",
  },
  {
    give:     ":8000",
    wantHost: "",
    wantPort: "8000",
  },
  {
    give:     "1:8",
    wantHost: "1",
    wantPort: "8",
  },
}

for _, tt := range tests {
  t.Run(tt.give, func(t *testing.T) {
    host, port, err := net.SplitHostPort(tt.give)
    require.NoError(t, err)
    assert.Equal(t, tt.wantHost, host)
    assert.Equal(t, tt.wantPort, port)
  })
}

測試表使向錯誤消息添加上下文，減少重複的邏輯以及添加新的測試用例變得更加容易。

我們遵循這樣的約定：將結構體切片稱爲tests。每個測試用例稱爲tt。此外，我們鼓勵使用give和want前綴說明每個測試用例的輸入和輸出值。

tests := []struct{
  give     string
  wantHost string
  wantPort string
}{
  // ...
}

for _, tt := range tests {
  // ...
}

功能選項

功能選項是一種模式，您可以在其中聲明一個不透明Option類型，該類型在某些內部結構中記錄信息。您接受這些選項的可變編號，並根據內部結構上的選項記錄的全部信息採取行動。

將此模式用於您需要擴展的構造函數和其他公共API中的可選參數，尤其是在這些功能上已經具有三個或更多參數的情況下。

Bad

// package db

func Connect(
  addr string,
  timeout time.Duration,
  caching bool,
) (*Connection, error) {
  // ...
}

// Timeout and caching must always be provided,
// even if the user wants to use the default.

db.Connect(addr, db.DefaultTimeout, db.DefaultCaching)
db.Connect(addr, newTimeout, db.DefaultCaching)
db.Connect(addr, db.DefaultTimeout, false /* caching */)
db.Connect(addr, newTimeout, false /* caching */)

vs.

Good

type options struct {
  timeout time.Duration
  caching bool
}

// Option overrides behavior of Connect.
type Option interface {
  apply(*options)
}

type optionFunc func(*options)

func (f optionFunc) apply(o *options) {
  f(o)
}

func WithTimeout(t time.Duration) Option {
  return optionFunc(func(o *options) {
    o.timeout = t
  })
}

func WithCaching(cache bool) Option {
  return optionFunc(func(o *options) {
    o.caching = cache
  })
}

// Connect creates a connection.
func Connect(
  addr string,
  opts ...Option,
) (*Connection, error) {
  options := options{
    timeout: defaultTimeout,
    caching: defaultCaching,
  }

  for _, o := range opts {
    o.apply(&options)
  }

  // ...
}

// Options must be provided only if needed.

db.Connect(addr)
db.Connect(addr, db.WithTimeout(newTimeout))
db.Connect(addr, db.WithCaching(false))
db.Connect(
  addr,
  db.WithCaching(false),
  db.WithTimeout(newTimeout),
)

還可以參考下面資料：

Self-referential functions and the design of options
Functional options for friendly APIs

推薦閱讀

Go GC 卡頓由秒級降到毫秒級以下：到底做了哪些優化？

——2019-10-14——

【轉載】Uber Go語言編碼規範

文章目錄

Uber Go語言編碼規範

一. 介紹

二. 指導原則

指向interface的指針

接收器(receiver)與接口

零值Mutex是有效的

在邊界處拷貝Slices和Maps

接收Slices和Maps

返回slices或maps

使用defer做清理

Channel的size要麼是1，要麼是無緩衝的

枚舉從1開始

錯誤類型

錯誤包裝(Error Wrapping)

處理類型斷言失敗

不要panic

使用go.uber.org/atomic

三. 性能

優先使用strconv而不是fmt

避免字符串到字節的轉換

四. 樣式

相似的聲明放在一組

import組內的包導入順序

包名

函數名

包導入別名

函數分組與順序

減少嵌套

不必要的else

頂層變量聲明

對於未導出的頂層常量和變量，使用_作爲前綴

結構體中的嵌入

使用字段名初始化結構體

本地變量聲明

nil是一個有效的slice

縮小變量作用域

避免裸參數

使用原始字符串字面值，避免轉義

初始化結構體引用

格式化字符串放在Printf外部

命名Printf樣式的函數

五. 模式

測試表

功能選項