golang 編程風格最佳實踐

介紹

本文更多的介紹代碼管理和檢查工具而不是大篇幅風格文檔，畢竟文檔只能那裏看，不如工具有時效性和可行性，畢竟說到不如做到

官方代碼編程風格文檔 https://golang.org/doc/effective_go.html
uber golang 代碼規範 https://github.com/uber-go/guide
uber golang 代碼規範中文 https://github.com/xxjwxc/uber_go_guide_cn

代碼目錄規範

目錄結構推薦目錄結構 https://github.com/golang-standards/project-layout

GOPATH 設置規範

建議保留 GOPATH 規則，便於維護代碼

建議只使用一個 GOPATH
不建議使用多個 GOPATH，如果使用多個 GOPATH，編譯生效的 bin 目錄是在第一個 GOPATH 下

golang 在 1.11 以後，弱化了 GOPATH 規則，已有代碼 (很多庫肯定是在 1.11 之前建立的) 肯定符合這個規則

go mod 工具鏈在 GOPATH 代碼下，需要額外打開環境變量配置 GO111MODULE=on go 1.13 以後可以設置兼容

$ go env -w GO111MODULE='on'

工程根目錄規範

golang 工程結構很重要，決定了代碼是否可以共享和維護

編寫的代碼在$GOPATH/src/ 下

按維護需求必須這樣放置

${GOPATH}/src/${GIT_HOST}/{$GIT_USER}|${GIT_GROUP}/${PROJ_ROOT}

GIT_HOST git 倉庫 host
GIT_USER git 用戶名稱同 GIT_GROUP 二選一
GIT_GROUP git 工作組名稱 GIT_USER 二選一
PROJ_ROOT 項目根

例如 github.com/sinlov/go-cli-fast-temp golang CLI 工具模板項目就在 $GOPATH/src/ 下 github.com 的 host sinlov 用戶 go-cli-fast-temp 工程名

工程名，在模板或者非產品工程，使用 - 分割，如果是產品線級，防止跨平臺兼容問題請使用 全小寫無分割符的 c 風格

工程子包名規範

代碼包名必須和當前文件路徑的父目錄同名，增強可讀性
防止跨平臺兼容問題請使用 全小寫無分割符的 c 風格
不要使用任何 golang 官方包已經存在的包名
必須使用 git 全路徑來定義新的包名，防止命名衝突
不要使用 DI 注入工具編寫業務代碼，防止引用錯誤

golang 代碼文件命名規範

工具代碼文件 駝峯命名描述工具作用，暴露 Pascal 風格的操作名
模型代碼文件，全小寫，描述單一模型，暴露 Pascal 風格的模型 type 或者 interface
業務代碼文件 全小寫，描述業務合輯，不得暴露工具類意圖
測試代碼文件，必須爲某個代碼的 _test.go 不得跨文件編寫測試代碼

golang 編碼實現規範

不要在 init 函數里做與變量初始化無關的工作
不要在業務代碼裏面寫 test 或者其他非輸出的代碼

更多規範建議看

uber golang 代碼規範 https://github.com/uber-go/guide
uber golang 代碼規範中文 https://github.com/xxjwxc/uber_go_guide_cn

編程規範檢查工具

golang 生態鏈本身提供很多代碼規範的工具，不用額外製定規範

靜態檢查工具

靜態檢查工具在 CI/CD 鏈中集成，即時發現即時補救

go vet

go vet 是一個用於檢查 Go 語言源碼中靜態錯誤的簡單工具 go vet 命令可以接受 -n 標記和 -x 標記

go tool vet

go tool vet 命令的作用是檢查 Go 語言源代碼並且報告可疑的代碼編寫問題

比如，在調用 Printf 函數時沒有傳入格式化字符串，以及某些不標準的方法簽名，等等

該命令使用試探性的手法檢查錯誤，因此並不能保證報告的問題確實需要解決。它確實能夠找到一些編譯器沒有捕捉到的錯誤。

go tool vet 命令的標記

-all 進行全部檢查。如果有其他檢查標記被設置，則命令程序會將此值變爲false。默認值爲true。
-asmdecl 對彙編語言的源碼文件進行檢查。默認值爲false。
-assign 檢查賦值語句。默認值爲false。
-atomic 檢查代碼中對代碼包sync/atomic的使用是否正確。默認值爲false。
-buildtags 檢查編譯標籤的有效性。默認值爲false。
-composites 檢查複合結構實例的初始化代碼。默認值爲false。
-compositeWhiteList 是否使用複合結構檢查的白名單。僅供測試使用。默認值爲true。
-methods 檢查那些擁有標準命名的方法的簽名。默認值爲false。
-printf 檢查代碼中對打印函數的使用是否正確。默認值爲false。
-printfuncs 需要檢查的代碼中使用的打印函數的名稱的列表，多個函數名稱之間用英文半角逗號分隔。默認值爲空字符串。
-rangeloops 檢查代碼中對在```range```語句塊中迭代賦值的變量的使用是否正確。默認值爲false。
-structtags 檢查結構體類型的字段的標籤的格式是否標準。默認值爲false。
-unreachable 查找並報告不可到達的代碼。默認值爲false。

race condition 競爭檢查

資源競爭檢查，併發時遇到的問題，會導致併發能力下降, 長時間運行一般會出現這個錯誤

panic: runtime error: invalid memory address or nil pointer dereference

檢查方法

# 任意代碼，構建時加入參數`-race`
go build -race

文檔見 http://blog.golang.org/race-detector

風格檢查

不建議制定風格檢查文檔，又冗長，又無法實施

golint

安裝方法

go get -v github.com/golang/lint
go install github.com/golang/lint

使用

golint [dir or file]

風格檢查樣例 https://github.com/golang/lint/tree/master/testdata

golint 檢查範圍就非常廣了，也很嚴格，可以配合 vscode 的 go 插件，或者 goland 的 golint 來檢查代碼風格

轉自：sinlov

blog.sinlov.cn/posts

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/FbjZ1oK0RZY49bOMvdJAYw

介紹