對於空的 maps,請使用make(..)初始化,並且以程式設計的方式填充的。這使得map的初始化在表現上不同於宣告,並且可以方便地在以後新增容量大小提示(如果有的話)。
bad
var (
// m1 可以安全的讀寫
// m2 在寫時會panic
m1 = map[t1]t2{}
m2 map[t1]t2
)//宣告和初始化看起來非常相似
good
var (
// m1 可以安全的讀寫
// m2 寫時會panic
m1 = make(map[t1]t2)
m2 map[t1]t2
)// 宣告和初始化看起來是不同的
在盡可能的情況下,在使用make()初始化 map時,提供容量提示。請查閱specifying map capacity hints 獲取更多資訊。
另一方面,如果map包含乙個固定的元素列表,則使用map字面量初始化該map。
bad
m := make(map[t1]t2, 3)
m[k1] = v1
m[k2] = v2
m[k3] = v3
good
m := map[t1]t2
基本的經驗法則是:在初始化時,新增一組固定的元素時,請使用map字面量,否則使用make(並盡可能指定容量)。 Uber Go 語言程式設計規範 Linting
我們建議至少使用以下的linters 因為我們認為它們有助於發現最常見的問題,並且在沒有不必要的規定的情況下為 質量建立乙個高標準 我們推薦 golangci lint 作為go 的首選lint執行器,主要是因為它在大型 庫中的效能以及同時配置和使用多個規範lint的能力。這個repo 有個例子.g...
Uber Go 語言程式設計規範 錯誤型別
在golang中有多種宣告錯誤的方式 當返回錯誤時,請考慮以下內容以確定最佳選擇 如果客戶端需要檢測錯誤,並且您已經使用errors.new建立了乙個簡單的錯誤,請使用var定義有乙個錯誤變數。bad package foo 直接返回乙個error func open error package b...
C語言程式設計規範之我見 變數初始化
c語言程式設計規範中,乙個爭論已久的問題,就是變數是否該在定義時進行初始化。針對這個問題,談談我的個人想法。首先,相比於變數定義時初始化,本人更傾向於變數按需初始化,具體如下 a 變數按需初始化,即變數定義時不初始化,而在變數使用前再進行賦值,此時可明確的知道該變數需要乙個什麼樣的值 b 而變數定時...