10.6 包和命名
10.6 包和命名
针对 package 和其成员的命名，本节会提供一些建议，使其与 Go 特有惯例相符。
1. package 的命名
先说创建、命名 package 时的注意事项：
保持名字短小，但不能太过简单短，以至于晦涩难懂。
标准包中最常用的被命名为 bufio, bytes, flag, fmt, http, io, json, os, sort, sync, time 。
名字要做清晰描述，杜绝通用含糊。
举例来说，工具包不要命名为 util ，要使用更明确，同时不失简洁的名字：imageutil 或 ioutil 。
package 名字，避开常用的变量名。
否则你就是在强迫使用者使用 renaming imports ，就像 path 包
包名称采用单数形式。
只有少数例外，才会采用复数形式，一种以 bytes, errors, strings 为代表, 目的是避开 Go 内置类型名称，另一种以 go/types 为代表，目的是避开对应的 Go 保留关键字。
避免会引发误解的名字
举例来说，2.5 节中温度转换包，我们开始叫 temp ，但没多久，我们就意识到这名字很糟，因为 temp 一般用于表示 temporary 。我们又改为 temperature ，但也没过多久，我们发现它又长，又不能说明它的作用。最终使用的名字是 tempconv ，它既短小，又和 strconv 这样的名字一致。
2. package 内部成员的命名
现在说说包内部成员的命名。
因为编码时，引用另一个包中的成员，要使用全名，比如 fmt.Println，因此描述成员，等同于包的名称加上成员的名称。
你可能已经发现用于格式化的函数 Println ，其函数名中并不提及“格式化”，这是因为该含义由包名达成。
这就是说，当设计一个 package 时，不能只关注成员命名，要意识到全名是由 2 个部分组成的，重点关注它俩组合后的整体效果 ？
下面是一些典型例子：
bytes.Equal
flag.Int
http.Get
json.Marshal该如何借鉴一些已有的优秀命名模式 ？以 strings 包提供的一组彼此独立的字符串操作函数为例
package strings
func Index(needle, haystack string) int
type Replacer struct{ /* ... */ }
func NewReplacer(oldnew ...string) *Replacer
type Reader struct{ /* ... */ }
func NewReader(s string) *Reader字符串 string 不会在其中的任何一个函数名称中出现。而使用者是通过 strings.Index, strings.Replacer 实现这些函数的引用。
3. 其他情况下的命名
除此之外，还有一些包，我们称为 single-type packages 。
比如 html/template 或是 math/rand ，它们会暴露一个主要的类型以及该类型的各种方法，还有一个 New 函数用来创建类型的实例。
package rand // "math/rand"
type Rand struct{ /* ... */ }
func New(source Source) *Rand这些名字引用时一定会导致同义反复(重复)，比如 template.Template 或 rand.Rand , 这就是为什么这类包的名字要取得特别短的原因。
最后还有一类特殊的情况。
那就是类似 net/http 这样的包，包内含有一堆的成员名，但并没有特定结构，这通常是因为这些包完成的任务太过复杂，与此同时，包内也许会含有一沓子各种类型，以及数量更多的函数。
要注意的是，包中最重要的成员的名字，应该是最简单的，比如 Get, Post, Handle, Error, Client, Server 。