前言
本篇主要講述Go語言的命名規范。優秀的代碼必須具備良好的可讀性，而可讀性的關鍵即在于命名風格。
Go的函數、變量、常量、自定義類型、包(Package)的命名方式遵循以下規則：
1）首字符可以是任意的Unicode字符或者下劃線
2）剩余字符可以是Unicode字符、下劃線、數字
3）字符長度不限
Go只有25個關鍵字
break default func interface select
case defer go map struct
chan else goto package switch
const fallthrough if range type
continue for import return var
優秀的命名
- 優秀的命名應當是一貫的、短小的、精確的。
- 所謂一貫，就是說同一個意義在不同的環境下的命名應當一致，譬如依賴關系，不要在一個方法中命名為depend，另一個方法中命名為rely。
- 所謂短小，不必多言，當命名過長的時候，讀者可能更關注命名本身，而忽視真正的邏輯內容。
- 所謂精確，就是命名達意、易于理解
首條經驗
聲明位置與使用位置越遠，則命名應當越長。
駱駝命名法
- Go語言應該使用 MixedCase
- (不要使用 names_with_underscores)
- 首字母縮寫詞都應該用大寫,譬如ServeHTTP、sceneID、CIDRProcessor。
局部變量
- 局部變量應當盡可能短小，譬如使用buf指代buffer，使用i指代index
- 在很長的函數中可能會有很多的變量，這個時候可以適當使用一些長名字。
- 但是寫出這么長的函數，通常意味著代碼需要重構了！🙅🏻
參數
函數的參數和局部變量類似，但是它們默認還具有文檔的功能
當參數類型具有描述性的時候，參數名就應該盡可能短小：
func AfterFunc(d Duration, f func()) *Timer
func Escape(w io.Writer, s []byte)
當參數類型比較模糊的時候，參數名就應當具有文檔的功能：
func Unix(sec, nsec int64) Time
func HasPrefix(s, prefix []byte) bool
返回值
在Go語言中，返回值可以定義名稱的，它可以當做一種特殊的參數。
尤其重要的是，在外部可見的函數中，返回值的名稱應當可以作為文檔參考。
func Copy(dst Writer, src Reader) (written int64, err error)
func ScanBytes(data []byte, atEOF bool) (advance int, token []byte,
err error)
方法接收者（Receiver）
方法接收者也是一種特殊的參數。Go語言中沒有明顯的面向對象的概念，可以對方法定義方法接收者來實現類似于對象的方法的概念。
按照慣例，由于方法接收者在函數內部經常出現，因此它經常采用一兩個字母來標識方法接收者的類型。
func (b *Buffer) Read(p []byte) (n int, err error)
func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request)
func (r Rectangle) Size() Point
需要注意的是，方法接收者的名字在同一類型的不同方法中應該保持統一，這也是前文所述的一貫性的需求。
導出包級別命名
導出名被使用的時候通常是放在包名后
所以，在導出變量、常數、函數和類型的時候，
不要把包名的意義再寫一遍
比較好的名字
bytes.Buffer strings.Reader
比較蠢的名字
bytes.ByteBuffer strings.StringReader
接口類型
只含有一個方法的接口類型通常以函數名加上er后綴作為名字
type Reader interface {
Read(p []byte) (n int, err error)
}
有時候可能導致蹩腳的英文，但別管他，能看懂就好
type Execer interface {
Exec(p []byte) (n int, err error)
}
有時候可以適當調整一下英文單詞的順序，增加可讀性：
type ByteReader interface {
ReadByte(p []byte) (n int, err error)
}
當接口含有多個方法的時候，還是要選取一個能夠精準描述接口目的的名字，譬如net.Conn、http/ResponseWriter
Error的命名
Error類型應該寫成FooError的形式
type ExitError struct {
....
}
Error變量協程ErrFoo的形式
var ErrFormat = errors.New("unknown format")
包的命名
應當與它導出代碼的內容相關，避免util、common這種寬泛的命名
引入路徑
包路徑的最后一個單詞應該和包名一致
包路徑應該盡可能簡潔
記得把庫的主要代碼直接放在代碼庫的根目錄
避免在包路徑中使用任何大寫字母（并非所有文件系統都區分大小寫）
標準庫
上述很多例子都是從標準庫中來的
標準庫的很多內容都可以作為參考
多看看標準庫來尋求靈感吧
但是要記住：
當作者寫標準庫的時候，他們自己也在學習過程中。
多數情況下作者是對的，但是偶爾還是會犯一些錯誤
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。
參考文獻
What's in a name? - Andrew Gerrand
