昨天正巧翻到一位Gopher的博客，发现他写的文章质量都挺高的于是今天早上就一直在看。
https://lailin.xyz/post/go-training-week4-project-layout.html
正好觉得自己的Golang使用起来感觉总是不大规范，趁着看到这篇博客，来总结一下一些Golang社区中约定俗成的规范。
命名规范
https://go.dev/talks/2014/names.slide#1
https://go.dev/doc/effective_go#names
https://go.dev/blog/package-names
上面的网址是谷歌还有go社区来讲命名规范的，总结一下就是信（准确）、达（明了）、雅（简洁）。大家肯定也明白是这样，所以就具体讲一下怎么做会更容易达到信达雅。
Use MixedCase
命名规范应该使用驼峰命名法（大小写混合），而不是蛇形命名法（下划线）。
缩写名词应该都是大写。
Local variables
尽量保持简洁，因为他们会较常在接下来的代码里使用。
Bad
func RuneCount(buffer []byte) int {
runeCount := 0
for index := 0; index < len(buffer); {
if buffer[index] < RuneSelf {
index++
} else {
_, size := DecodeRune(buffer[index:])
index += size
}
runeCount++
}
return runeCount
}
Good
func RuneCount(b []byte) int {
count := 0
for i := 0; i < len(b); {
if b[i] < RuneSelf {
i++
} else {
_, n := DecodeRune(b[i:])
i += n
}
count++
}
return count
}
Parameters
当参数类型名已经较为生动的时候，就简短的字母表示
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
Return values
我们应该在需要查看对外暴露函数使用方法的时候，对这个函数的返回值进行命名。
除此以外都不建议命名。
一些例子：
func Copy(dst Writer, src Reader) (written int64, err error)
func ScanBytes(data []byte, atEOF bool) (advance int, token []byte, err error)
Receivers
receivers算是一种特殊的参数，他们应该以1个或者2个字符来命名，因为使用频率太高了。
func (b *Buffer) Read(p []byte) (n int, err error)
func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request)
func (r Rectangle) Size() Point
同时receiver的命名应该是一致的，不应该一会是 r 另一个方法内用 rr 来命名。
Interface Types
如果一个接口只含有一个方法，那么我们通常以er结尾来命名。
type Reader interface {
Read(p []byte) (n int, err error)
}
即使是不符合英文规范的，我们仍会这样做：
type Execer interface {
Exec(query string, args []Value) (Result, error)
}
有时我们也会根据英文习惯将命名变得更好：
type ByteReader interface {
ReadByte() (c byte, err error)
}
当接口有多个方法的时候，应该要选择一个恰当准确的名字去表现它，比如 net.Conn, http.ResponseWriter, io.ReadWriter
Packages
应该选择更为代表性切简短的命名，注意避开common与util等命名。
By convention, packages are given lower case, single-word names; there should be no need for underscores or mixedCaps.
按照惯例，包被赋予小写的单个单词名称；应该不需要下划线或混合大写字母。
过于简洁反而是错的，因为每个人使用的人都需要输入包名，同时你不需要当心包名重复问题，因为包可以在import的时候重命名，但还是要尽量避免包名重复，以免客户端调用时非常麻烦。
另外一个约定就是包名就是其所在目录名，src/encoding/base64 中的包被导入为“encoding/base64”，但名称为 base64，而不是 encoding_base64 而不是 encodingBase64。
长名称不会自动使内容更具可读性。有用的文档注释通常比超长的名称更有价值。
如果您不能想出一个包名称作为包内容的有意义的前缀，则包抽象边界可能是错误的。
编写像客户那样使用您的包的代码，如果结果看起来很差，则重组您的包。这种方法将生成更易于客户理解和包开发人员维护的包。
Getter与Setter
Go 不提供对 getter 和 setter 的自动支持。自己提供 getter 和 setter 没有错，这样做通常是合适的，但是将 Get 放入 getter 的名称中既不符合习惯也没有必要。如果您有一个名为 owner（小写，未导出）的字段，则 getter 方法应称为 Owner（大写，已导出），而不是 GetOwner。如果需要，setter 函数可能会被称为 SetOwner。这两个名字在实践中读起来都很好
owner := obj.Owner()
if owner != user {
obj.SetOwner(user)
}
if
如果else中是以return结尾的话，建议取消else，直接在反向if中return
f, err := os.Open(name)
if err != nil {
return err
}
codeUsing(f)
ps. 好像学了很多，又好像什么都没学，还是需要在写的时候多看看。
标签：index,社区,err,命名,func,Go,约定俗成,byte,go From： https://www.cnblogs.com/Vikyanite/p/16965914.html