株洲网站设计外包首选,百度云服务器挂网站,福建省建设人才与科技发展中心网站首页,职业生涯规划大赛作品uber-go/guide 的中文翻译
English 文档链接
Uber Go 语言编码规范
Uber 是一家美国硅谷的科技公司#xff0c;也是 Go 语言的早期 adopter。其开源了很多 golang 项目#xff0c;诸如被 Gopher 圈熟知的 zap、jaeger 等。2018 年年末 Uber 将内部的 Go 风格规范 开源到 G…uber-go/guide 的中文翻译
English 文档链接
Uber Go 语言编码规范
Uber 是一家美国硅谷的科技公司也是 Go 语言的早期 adopter。其开源了很多 golang 项目诸如被 Gopher 圈熟知的 zap、jaeger 等。2018 年年末 Uber 将内部的 Go 风格规范 开源到 GitHub经过一年的积累和更新该规范已经初具规模并受到广大 Gopher 的关注。本文是该规范的中文版本。本版本会根据原版实时更新。
版本
当前更新版本2021-07-09 版本地址commit:#130
目录
uber-go/guide 的中文翻译EnglishUber Go 语言编码规范版本目录介绍指导原则 指向 interface 的指针Interface 合理性验证接收器 (receiver) 与接口零值 Mutex 是有效的在边界处拷贝 Slices 和 Maps 接收 Slices 和 Maps返回 slices 或 maps 使用 defer 释放资源Channel 的 size 要么是 1要么是无缓冲的枚举从 1 开始使用 time 处理时间 使用 time.Time 表达瞬时时间使用 time.Duration 表达时间段对外部系统使用 time.Time 和 time.Duration 错误类型错误包装 (Error Wrapping)处理类型断言失败不要 panic使用 go.uber.org/atomic避免可变全局变量避免在公共结构中嵌入类型避免使用内置名称避免使用 init()追加时优先指定切片容量主函数退出方式(Exit) 一次性退出 性能 优先使用 strconv 而不是 fmt避免字符串到字节的转换指定容器容量 指定Map容量提示指定切片容量 规范 一致性相似的声明放在一组import 分组包名函数名导入别名函数分组与顺序减少嵌套不必要的 else顶层变量声明对于未导出的顶层常量和变量使用_作为前缀结构体中的嵌入使用字段名初始化结构体本地变量声明nil 是一个有效的 slice缩小变量作用域避免参数语义不明确(Avoid Naked Parameters)使用原始字符串字面值避免转义初始化结构体 使用字段名初始化结构省略结构中的零值字段对零值结构使用 var初始化 Struct 引用 初始化 Maps字符串 string format命名 Printf 样式的函数 编程模式 表驱动测试功能选项 Linting Lint Runners Stargazers over time
介绍
样式 (style) 是支配我们代码的惯例。术语样式有点用词不当因为这些约定涵盖的范围不限于由 gofmt 替我们处理的源文件格式。
本指南的目的是通过详细描述在 Uber 编写 Go 代码的注意事项来管理这种复杂性。这些规则的存在是为了使代码库易于管理同时仍然允许工程师更有效地使用 Go 语言功能。
该指南最初由 Prashant Varanasi 和 Simon Newton 编写目的是使一些同事能快速使用 Go。多年来该指南已根据其他人的反馈进行了修改。
本文档记录了我们在 Uber 遵循的 Go 代码中的惯用约定。其中许多是 Go 的通用准则而其他扩展准则依赖于下面外部的指南
Effective GoGo Common MistakesGo Code Review Comments
所有代码都应该通过golint和go vet的检查并无错误。我们建议您将编辑器设置为
保存时运行 goimports运行 golint 和 go vet 检查错误
您可以在以下 Go 编辑器工具支持页面中找到更为详细的信息 https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins
指导原则
指向 interface 的指针
您几乎不需要指向接口类型的指针。您应该将接口作为值进行传递在这样的传递过程中实质上传递的底层数据仍然可以是指针。
接口实质上在底层用两个字段表示
一个指向某些特定类型信息的指针。您可以将其视为type。数据指针。如果存储的数据是指针则直接存储。如果存储的数据是一个值则存储指向该值的指针。
如果希望接口方法修改基础数据则必须使用指针传递(将对象指针赋值给接口变量)。
type F interface {f()
}type S1 struct{}func (s S1) f() {}type S2 struct{}func (s *S2) f() {}// f1.f()无法修改底层数据
// f2.f() 可以修改底层数据,给接口变量f2赋值时使用的是对象指针
var f1 F S1{}
var f2 F S2{}Interface 合理性验证
在编译时验证接口的符合性。这包括
将实现特定接口的导出类型作为接口API 的一部分进行检查实现同一接口的(导出和非导出)类型属于实现类型的集合任何违反接口合理性检查的场景,都会终止编译,并通知给用户
补充:上面3条是编译器对接口的检查机制, 大体意思是错误使用接口会在编译期报错. 所以可以利用这个机制让部分问题在编译期暴露.
BadGood
// 如果Handler没有实现http.Handler,会在运行时报错
type Handler struct {// ...
}
func (h *Handler) ServeHTTP(w http.ResponseWriter,r *http.Request,
) {...
}type Handler struct {// ...
}
// 用于触发编译期的接口的合理性检查机制
// 如果Handler没有实现http.Handler,会在编译期报错
var _ http.Handler (*Handler)(nil)
func (h *Handler) ServeHTTP(w http.ResponseWriter,r *http.Request,
) {// ...
}如果 *Handler 与 http.Handler 的接口不匹配, 那么语句 var _ http.Handler (*Handler)(nil) 将无法编译通过.
赋值的右边应该是断言类型的零值。 对于指针类型如 *Handler、切片和映射这是 nil 对于结构类型这是空结构。
type LogHandler struct {h http.Handlerlog *zap.Logger
}
var _ http.Handler LogHandler{}
func (h LogHandler) ServeHTTP(w http.ResponseWriter,r *http.Request,
) {// ...
}接收器 (receiver) 与接口
使用值接收器的方法既可以通过值调用也可以通过指针调用。
带指针接收器的方法只能通过指针或 addressable values调用.
例如
type S struct {data string
}func (s S) Read() string {return s.data
}func (s *S) Write(str string) {s.data str
}sVals : map[int]S{1: {A}}// 你只能通过值调用 Read
sVals[1].Read()// 这不能编译通过
// sVals[1].Write(test)sPtrs : map[int]*S{1: {A}}// 通过指针既可以调用 Read也可以调用 Write 方法
sPtrs[1].Read()
sPtrs[1].Write(test)类似的,即使方法有了值接收器,也同样可以用指针接收器来满足接口.
type F interface {f()
}type S1 struct{}func (s S1) f() {}type S2 struct{}func (s *S2) f() {}s1Val : S1{}
s1Ptr : S1{}
s2Val : S2{}
s2Ptr : S2{}var i F
i s1Val
i s1Ptr
i s2Ptr// 下面代码无法通过编译。因为 s2Val 是一个值而 S2 的 f 方法中没有使用值接收器
// i s2ValEffective Go 中有一段关于 pointers vs. values 的精彩讲解。
补充:
一个类型可以有值接收器方法集和指针接收器方法集 值接收器方法集是指针接收器方法集的子集,反之不是 规则 值对象只可以使用值接收器方法集指针对象可以使用 值接收器方法集 指针接收器方法集 接口的匹配(或者叫实现) 类型实现了接口的所有方法,叫匹配具体的讲,要么是类型的值方法集匹配接口,要么是指针方法集匹配接口
具体的匹配分两种:
值方法集和接口匹配 给接口变量赋值的不管是值还是指针对象,都ok,因为都包含值方法集 指针方法集和接口匹配 只能将指针对象赋值给接口变量,因为只有指针方法集和接口匹配如果将值对象赋值给接口变量,会在编译期报错(会触发接口合理性检查机制)
为啥 i s2Val 会报错,因为值方法集和接口不匹配.
零值 Mutex 是有效的
零值 sync.Mutex 和 sync.RWMutex 是有效的。所以指向 mutex 的指针基本是不必要的。
BadGood
mu : new(sync.Mutex)
mu.Lock()var mu sync.Mutex
mu.Lock()如果你使用结构体指针mutex 应该作为结构体的非指针字段。即使该结构体不被导出也不要直接把 mutex 嵌入到结构体中。
BadGood
type SMap struct {sync.Mutexdata map[string]string
}func NewSMap() *SMap {return SMap{data: make(map[string]string),}
}func (m *SMap) Get(k string) string {m.Lock()defer m.Unlock()return m.data[k]
}type SMap struct {mu sync.Mutexdata map[string]string
}func NewSMap() *SMap {return SMap{data: make(map[string]string),}
}func (m *SMap) Get(k string) string {m.mu.Lock()defer m.mu.Unlock()return m.data[k]
}Mutex 字段 Lock 和 Unlock 方法是 SMap 导出的 API 中不刻意说明的一部分。
mutex 及其方法是 SMap 的实现细节对其调用者不可见。
在边界处拷贝 Slices 和 Maps
slices 和 maps 包含了指向底层数据的指针因此在需要复制它们时要特别注意。
接收 Slices 和 Maps
请记住当 map 或 slice 作为函数参数传入时如果您存储了对它们的引用则用户可以对其进行修改。
BadGood
func (d *Driver) SetTrips(trips []Trip) {d.trips trips
}trips : ...
d1.SetTrips(trips)// 你是要修改 d1.trips 吗
trips[0] ...func (d *Driver) SetTrips(trips []Trip) {d.trips make([]Trip, len(trips))copy(d.trips, trips)
}trips : ...
d1.SetTrips(trips)// 这里我们修改 trips[0]但不会影响到 d1.trips
trips[0] ...返回 slices 或 maps
同样请注意用户对暴露内部状态的 map 或 slice 的修改。
BadGood
type Stats struct {mu sync.Mutexcounters map[string]int
}// Snapshot 返回当前状态。
func (s *Stats) Snapshot() map[string]int {s.mu.Lock()defer s.mu.Unlock()return s.counters
}// snapshot 不再受互斥锁保护
// 因此对 snapshot 的任何访问都将受到数据竞争的影响
// 影响 stats.counters
snapshot : stats.Snapshot()type Stats struct {mu sync.Mutexcounters map[string]int
}func (s *Stats) Snapshot() map[string]int {s.mu.Lock()defer s.mu.Unlock()result : make(map[string]int, len(s.counters))for k, v : range s.counters {result[k] v}return result
}// snapshot 现在是一个拷贝
snapshot : stats.Snapshot()使用 defer 释放资源
使用 defer 释放资源诸如文件和锁。
BadGood
p.Lock()
if p.count 10 {p.Unlock()return p.count
}p.count
newCount : p.count
p.Unlock()return newCount// 当有多个 return 分支时很容易遗忘 unlockp.Lock()
defer p.Unlock()if p.count 10 {return p.count
}p.count
return p.count// 更可读Defer 的开销非常小只有在您可以证明函数执行时间处于纳秒级的程度时才应避免这样做。使用 defer 提升可读性是值得的因为使用它们的成本微不足道。尤其适用于那些不仅仅是简单内存访问的较大的方法在这些方法中其他计算的资源消耗远超过 defer。
Channel 的 size 要么是 1要么是无缓冲的
channel 通常 size 应为 1 或是无缓冲的。默认情况下channel 是无缓冲的其 size 为零。任何其他尺寸都必须经过严格的审查。我们需要考虑如何确定大小考虑是什么阻止了 channel 在高负载下和阻塞写时的写入以及当这种情况发生时系统逻辑有哪些变化。(翻译解释按照原文意思是需要界定通道边界竞态条件以及逻辑上下文梳理)
BadGood
// 应该足以满足任何情况
c : make(chan int, 64)// 大小1
c : make(chan int, 1) // 或者
// 无缓冲 channel大小为 0
c : make(chan int)枚举从 1 开始
在 Go 中引入枚举的标准方法是声明一个自定义类型和一个使用了 iota 的 const 组。由于变量的默认值为 0因此通常应以非零值开头枚举。
BadGood
type Operation intconst (Add Operation iotaSubtractMultiply
)// Add0, Subtract1, Multiply2type Operation intconst (Add Operation iota 1SubtractMultiply
)// Add1, Subtract2, Multiply3在某些情况下使用零值是有意义的枚举从零开始例如当零值是理想的默认行为时。
type LogOutput intconst (LogToStdout LogOutput iotaLogToFileLogToRemote
)// LogToStdout0, LogToFile1, LogToRemote2使用 time 处理时间
时间处理很复杂。关于时间的错误假设通常包括以下几点。
一天有 24 小时一小时有 60 分钟一周有七天一年 365 天还有更多
例如1 表示在一个时间点上加上 24 小时并不总是产生一个新的日历日。
因此在处理时间时始终使用 time 包因为它有助于以更安全、更准确的方式处理这些不正确的假设。
使用 time.Time 表达瞬时时间
在处理时间的瞬间时使用 time.Time在比较、添加或减去时间时使用 time.Time 中的方法。
BadGood
func isActive(now, start, stop int) bool {return start now now stop
}func isActive(now, start, stop time.Time) bool {return (start.Before(now) || start.Equal(now)) now.Before(stop)
}使用 time.Duration 表达时间段
在处理时间段时使用 time.Duration .
BadGood
func poll(delay int) {for {// ...time.Sleep(time.Duration(delay) * time.Millisecond)}
}
poll(10) // 是几秒钟还是几毫秒?func poll(delay time.Duration) {for {// ...time.Sleep(delay)}
}
poll(10*time.Second)回到第一个例子在一个时间瞬间加上 24 小时我们用于添加时间的方法取决于意图。如果我们想要下一个日历日(当前天的下一天)的同一个时间点我们应该使用 Time.AddDate。但是如果我们想保证某一时刻比前一时刻晚 24 小时我们应该使用 Time.Add。
newDay : t.AddDate(0 /* years */, 0 /* months */, 1 /* days */)
maybeNewDay : t.Add(24 * time.Hour)对外部系统使用 time.Time 和 time.Duration
尽可能在与外部系统的交互中使用 time.Duration 和 time.Time 例如 : Command-line 标志: flag 通过 time.ParseDuration 支持 time.Duration JSON: encoding/json 通过其 UnmarshalJSON method 方法支持将 time.Time 编码为 RFC 3339 字符串 SQL: database/sql 支持将 DATETIME 或 TIMESTAMP 列转换为 time.Time如果底层驱动程序支持则返回 YAML: gopkg.in/yaml.v2 支持将 time.Time 作为 RFC 3339 字符串并通过 time.ParseDuration 支持 time.Duration。
当不能在这些交互中使用 time.Duration 时请使用 int 或 float64并在字段名称中包含单位。
例如由于 encoding/json 不支持 time.Duration因此该单位包含在字段的名称中。
BadGood
// {interval: 2}
type Config struct {Interval int json:interval
}// {intervalMillis: 2000}
type Config struct {IntervalMillis int json:intervalMillis
}当在这些交互中不能使用 time.Time 时除非达成一致否则使用 string 和 RFC 3339 中定义的格式时间戳。默认情况下Time.UnmarshalText 使用此格式并可通过 time.RFC3339 在 Time.Format 和 time.Parse 中使用。
尽管这在实践中并不成问题但请记住time 包不支持解析闰秒时间戳8728也不在计算中考虑闰秒15190。如果您比较两个时间瞬间则差异将不包括这两个瞬间之间可能发生的闰秒。 错误类型
Go 中有多种声明错误Error) 的选项
errors.New 对于简单静态字符串的错误fmt.Errorf 用于格式化的错误字符串实现 Error() 方法的自定义类型用 pkg/errors.Wrap 的 Wrapped errors
返回错误时请考虑以下因素以确定最佳选择 这是一个不需要额外信息的简单错误吗如果是这样errors.New 足够了。 客户需要检测并处理此错误吗如果是这样则应使用自定义类型并实现该 Error() 方法。 您是否正在传播下游函数返回的错误如果是这样请查看本文后面有关错误包装 section on error wrapping 部分的内容。 否则 fmt.Errorf 就可以了。
如果客户端需要检测错误并且您已使用创建了一个简单的错误 errors.New请使用一个错误变量。
BadGood
// package foofunc Open() error {return errors.New(could not open)
}// package barfunc use() {if err : foo.Open(); err ! nil {if err.Error() could not open {// handle} else {panic(unknown error)}}
}// package foovar ErrCouldNotOpen errors.New(could not open)func Open() error {return ErrCouldNotOpen
}// package barif err : foo.Open(); err ! nil {if errors.Is(err, foo.ErrCouldNotOpen) {// handle} else {panic(unknown error)}
}如果您有可能需要客户端检测的错误并且想向其中添加更多信息例如它不是静态字符串则应使用自定义类型。
BadGood
func open(file string) error {return fmt.Errorf(file %q not found, file)
}func use() {if err : open(testfile.txt); err ! nil {if strings.Contains(err.Error(), not found) {// handle} else {panic(unknown error)}}
}type errNotFound struct {file string
}func (e errNotFound) Error() string {return fmt.Sprintf(file %q not found, e.file)
}func open(file string) error {return errNotFound{file: file}
}func use() {if err : open(testfile.txt); err ! nil {if _, ok : err.(errNotFound); ok {// handle} else {panic(unknown error)}}
}直接导出自定义错误类型时要小心因为它们已成为程序包公共 API 的一部分。最好公开匹配器功能以检查错误。
// package footype errNotFound struct {file string
}func (e errNotFound) Error() string {return fmt.Sprintf(file %q not found, e.file)
}func IsNotFoundError(err error) bool {_, ok : err.(errNotFound)return ok
}func Open(file string) error {return errNotFound{file: file}
}// package barif err : foo.Open(foo); err ! nil {if foo.IsNotFoundError(err) {// handle} else {panic(unknown error)}
}错误包装 (Error Wrapping)
一个函数/方法调用失败时有三种主要的错误传播方式
如果没有要添加的其他上下文并且您想要维护原始错误类型则返回原始错误。添加上下文使用 pkg/errors.Wrap 以便错误消息提供更多上下文 ,pkg/errors.Cause 可用于提取原始错误。如果调用者不需要检测或处理的特定错误情况使用 fmt.Errorf。
建议在可能的地方添加上下文以使您获得诸如“调用服务 foo连接被拒绝”之类的更有用的错误而不是诸如“连接被拒绝”之类的模糊错误。
在将上下文添加到返回的错误时请避免使用“failed to”之类的短语以保持上下文简洁这些短语会陈述明显的内容并随着错误在堆栈中的渗透而逐渐堆积
BadGood
s, err : store.New()
if err ! nil {return fmt.Errorf(failed to create new store: %v, err)
}s, err : store.New()
if err ! nil {return fmt.Errorf(new store: %v, err)
}failed to x: failed to y: failed to create new store: the errorx: y: new store: the error但是一旦将错误发送到另一个系统就应该明确消息是错误消息例如使用err标记或在日志中以”Failed”为前缀。
另请参见 Don’t just check errors, handle them gracefully. 不要只是检查错误要优雅地处理错误
处理类型断言失败
type assertion 的单个返回值形式针对不正确的类型将产生 panic。因此请始终使用“comma ok”的惯用法。
BadGood
t : i.(string)t, ok : i.(string)
if !ok {// 优雅地处理错误
}不要 panic
在生产环境中运行的代码必须避免出现 panic。panic 是 cascading failures 级联失败的主要根源 。如果发生错误该函数必须返回错误并允许调用方决定如何处理它。
BadGood
func run(args []string) {if len(args) 0 {panic(an argument is required)}// ...
}func main() {run(os.Args[1:])
}func run(args []string) error {if len(args) 0 {return errors.New(an argument is required)}// ...return nil
}func main() {if err : run(os.Args[1:]); err ! nil {fmt.Fprintln(os.Stderr, err)os.Exit(1)}
}panic/recover 不是错误处理策略。仅当发生不可恢复的事情例如nil 引用时程序才必须 panic。程序初始化是一个例外程序启动时应使程序中止的不良情况可能会引起 panic。
var _statusTemplate template.Must(template.New(name).Parse(_statusHTML))即使在测试代码中也优先使用t.Fatal或者t.FailNow而不是 panic 来确保失败被标记。
BadGood
// func TestFoo(t *testing.T)f, err : ioutil.TempFile(, test)
if err ! nil {panic(failed to set up test)
}// func TestFoo(t *testing.T)f, err : ioutil.TempFile(, test)
if err ! nil {t.Fatal(failed to set up test)
}使用 go.uber.org/atomic
使用 sync/atomic 包的原子操作对原始类型 (int32, int64等进行操作因为很容易忘记使用原子操作来读取或修改变量。
go.uber.org/atomic 通过隐藏基础类型为这些操作增加了类型安全性。此外它包括一个方便的atomic.Bool类型。
BadGood
type foo struct {running int32 // atomic
}func (f* foo) start() {if atomic.SwapInt32(f.running, 1) 1 {// already running…return}// start the Foo
}func (f *foo) isRunning() bool {return f.running 1 // race!
}type foo struct {running atomic.Bool
}func (f *foo) start() {if f.running.Swap(true) {// already running…return}// start the Foo
}func (f *foo) isRunning() bool {return f.running.Load()
}避免可变全局变量
使用选择依赖注入方式避免改变全局变量。 既适用于函数指针又适用于其他值类型
BadGood
// sign.go
var _timeNow time.Now
func sign(msg string) string {now : _timeNow()return signWithTime(msg, now)
}// sign.go
type signer struct {now func() time.Time
}
func newSigner() *signer {return signer{now: time.Now,}
}
func (s *signer) Sign(msg string) string {now : s.now()return signWithTime(msg, now)
}// sign_test.go
func TestSign(t *testing.T) {oldTimeNow : _timeNow_timeNow func() time.Time {return someFixedTime}defer func() { _timeNow oldTimeNow }()assert.Equal(t, want, sign(give))
}// sign_test.go
func TestSigner(t *testing.T) {s : newSigner()s.now func() time.Time {return someFixedTime}assert.Equal(t, want, s.Sign(give))
}避免在公共结构中嵌入类型
这些嵌入的类型泄漏实现细节、禁止类型演化和模糊的文档。
假设您使用共享的 AbstractList 实现了多种列表类型请避免在具体的列表实现中嵌入 AbstractList。 相反只需手动将方法写入具体的列表该列表将委托给抽象列表。
type AbstractList struct {}
// 添加将实体添加到列表中。
func (l *AbstractList) Add(e Entity) {// ...
}
// 移除从列表中移除实体。
func (l *AbstractList) Remove(e Entity) {// ...
}BadGood
// ConcreteList 是一个实体列表。
type ConcreteList struct {*AbstractList
}// ConcreteList 是一个实体列表。
type ConcreteList struct {list *AbstractList
}
// 添加将实体添加到列表中。
func (l *ConcreteList) Add(e Entity) {l.list.Add(e)
}
// 移除从列表中移除实体。
func (l *ConcreteList) Remove(e Entity) {l.list.Remove(e)
}Go 允许 类型嵌入 作为继承和组合之间的折衷。 外部类型获取嵌入类型的方法的隐式副本。 默认情况下这些方法委托给嵌入实例的同一方法。
结构还获得与类型同名的字段。 所以如果嵌入的类型是 public那么字段是 public。为了保持向后兼容性外部类型的每个未来版本都必须保留嵌入类型。
很少需要嵌入类型。 这是一种方便可以帮助您避免编写冗长的委托方法。
即使嵌入兼容的抽象列表 interface而不是结构体这将为开发人员提供更大的灵活性来改变未来但仍然泄露了具体列表使用抽象实现的细节。
BadGood
// AbstractList 是各种实体列表的通用实现。
type AbstractList interface {Add(Entity)Remove(Entity)
}
// ConcreteList 是一个实体列表。
type ConcreteList struct {AbstractList
}// ConcreteList 是一个实体列表。
type ConcreteList struct {list AbstractList
}
// 添加将实体添加到列表中。
func (l *ConcreteList) Add(e Entity) {l.list.Add(e)
}
// 移除从列表中移除实体。
func (l *ConcreteList) Remove(e Entity) {l.list.Remove(e)
}无论是使用嵌入式结构还是使用嵌入式接口嵌入式类型都会限制类型的演化.
向嵌入式接口添加方法是一个破坏性的改变。删除嵌入类型是一个破坏性的改变。即使使用满足相同接口的替代方法替换嵌入类型也是一个破坏性的改变。
尽管编写这些委托方法是乏味的但是额外的工作隐藏了实现细节留下了更多的更改机会还消除了在文档中发现完整列表接口的间接性操作。
避免使用内置名称
Go语言规范language specification 概述了几个内置的 不应在Go项目中使用的名称标识predeclared identifiers。
根据上下文的不同将这些标识符作为名称重复使用 将在当前作用域或任何嵌套作用域中隐藏原始标识符或者混淆代码。 在最好的情况下编译器会报错在最坏的情况下这样的代码可能会引入潜在的、难以恢复的错误。
BadGood
var error string
// error 作用域隐式覆盖// orfunc handleErrorMessage(error string) {// error 作用域隐式覆盖
}var errorMessage string
// error 指向内置的非覆盖// orfunc handleErrorMessage(msg string) {// error 指向内置的非覆盖
}type Foo struct {// 虽然这些字段在技术上不构成阴影但error或string字符串的重映射现在是不明确的。error errorstring string
}func (f Foo) Error() error {// error 和 f.error 在视觉上是相似的return f.error
}func (f Foo) String() string {// string and f.string 在视觉上是相似的return f.string
}type Foo struct {// error and string 现在是明确的。err errorstr string
}func (f Foo) Error() error {return f.err
}func (f Foo) String() string {return f.str
}注意编译器在使用预先分隔的标识符时不会生成错误 但是诸如go vet之类的工具会正确地指出这些和其他情况下的隐式问题。
避免使用 init()
尽可能避免使用init()。当init()是不可避免或可取的代码应先尝试
无论程序环境或调用如何都要完全确定。避免依赖于其他init()函数的顺序或副作用。虽然init()顺序是明确的但代码可以更改 因此init()函数之间的关系可能会使代码变得脆弱和容易出错。避免访问或操作全局或环境状态如机器信息、环境变量、工作目录、程序参数/输入等。避免I/O包括文件系统、网络和系统调用。
不能满足这些要求的代码可能属于要作为main()调用的一部分或程序生命周期中的其他地方 或者作为main()本身的一部分写入。特别是打算由其他程序使用的库应该特别注意完全确定性 而不是执行“init magic”
BadGood
type Foo struct {// ...
}
var _defaultFoo Foo
func init() {_defaultFoo Foo{// ...}
}var _defaultFoo Foo{// ...
}
// or, 为了更好的可测试性:
var _defaultFoo defaultFoo()
func defaultFoo() Foo {return Foo{// ...}
}type Config struct {// ...
}
var _config Config
func init() {// Bad: 基于当前目录cwd, _ : os.Getwd()// Bad: I/Oraw, _ : ioutil.ReadFile(path.Join(cwd, config, config.yaml),)yaml.Unmarshal(raw, _config)
}type Config struct {// ...
}
func loadConfig() Config {cwd, err : os.Getwd()// handle errraw, err : ioutil.ReadFile(path.Join(cwd, config, config.yaml),)// handle errvar config Configyaml.Unmarshal(raw, config)return config
}考虑到上述情况在某些情况下init()可能更可取或是必要的可能包括 不能表示为单个赋值的复杂表达式。 可插入的钩子如database/sql、编码类型注册表等。 对Google Cloud Functions和其他形式的确定性预计算的优化。
追加时优先指定切片容量
追加时优先指定切片容量
在尽可能的情况下在初始化要追加的切片时为make()提供一个容量值。
BadGood
for n : 0; n b.N; n {data : make([]int, 0)for k : 0; k size; k{data append(data, k)}
}for n : 0; n b.N; n {data : make([]int, 0, size)for k : 0; k size; k{data append(data, k)}
}BenchmarkBad-4 100000000 2.48sBenchmarkGood-4 100000000 0.21s主函数退出方式(Exit)
Go程序使用os.Exit 或者 log.Fatal* 立即退出 (使用panic不是退出程序的好方法请 don’t panic.)
**仅在main**中调用其中一个 os.Exit 或者 log.Fatal*。所有其他函数应将错误返回到信号失败中。
BadGood
func main() {body : readFile(path)fmt.Println(body)
}
func readFile(path string) string {f, err : os.Open(path)if err ! nil {log.Fatal(err)}b, err : ioutil.ReadAll(f)if err ! nil {log.Fatal(err)}return string(b)
}func main() {body, err : readFile(path)if err ! nil {log.Fatal(err)}fmt.Println(body)
}
func readFile(path string) (string, error) {f, err : os.Open(path)if err ! nil {return , err}b, err : ioutil.ReadAll(f)if err ! nil {return , err}return string(b), nil
}原则上退出的具有多种功能的程序存在一些问题
不明显的控制流任何函数都可以退出程序因此很难对控制流进行推理。难以测试退出程序的函数也将退出调用它的测试。这使得函数很难测试并引入了跳过 go test 尚未运行的其他测试的风险。跳过清理当函数退出程序时会跳过已经进入defer队列里的函数调用。这增加了跳过重要清理任务的风险。
一次性退出
如果可能的话你的main函数中最多一次 调用 os.Exit或者log.Fatal。如果有多个错误场景停止程序执行请将该逻辑放在单独的函数下并从中返回错误。 这会缩短 main()函数并将所有关键业务逻辑放入一个单独的、可测试的函数中。
BadGood
package main
func main() {args : os.Args[1:]if len(args) ! 1 {log.Fatal(missing file)}name : args[0]f, err : os.Open(name)if err ! nil {log.Fatal(err)}defer f.Close()// 如果我们调用log.Fatal 在这条线之后// f.Close 将会被执行.b, err : ioutil.ReadAll(f)if err ! nil {log.Fatal(err)}// ...
}package main
func main() {if err : run(); err ! nil {log.Fatal(err)}
}
func run() error {args : os.Args[1:]if len(args) ! 1 {return errors.New(missing file)}name : args[0]f, err : os.Open(name)if err ! nil {return err}defer f.Close()b, err : ioutil.ReadAll(f)if err ! nil {return err}// ...
}性能
性能方面的特定准则只适用于高频场景。
优先使用 strconv 而不是 fmt
将原语转换为字符串或从字符串转换时strconv速度比fmt快。
BadGood
for i : 0; i b.N; i {s : fmt.Sprint(rand.Int())
}for i : 0; i b.N; i {s : strconv.Itoa(rand.Int())
}BenchmarkFmtSprint-4 143 ns/op 2 allocs/opBenchmarkStrconv-4 64.2 ns/op 1 allocs/op避免字符串到字节的转换
不要反复从固定字符串创建字节 slice。相反请执行一次转换并捕获结果。
BadGood
for i : 0; i b.N; i {w.Write([]byte(Hello world))
}data : []byte(Hello world)
for i : 0; i b.N; i {w.Write(data)
}BenchmarkBad-4 50000000 22.2 ns/opBenchmarkGood-4 500000000 3.25 ns/op指定容器容量
尽可能指定容器容量以便为容器预先分配内存。这将在添加元素时最小化后续分配通过复制和调整容器大小。
指定Map容量提示
在尽可能的情况下在使用 make() 初始化的时候提供容量信息
make(map[T1]T2, hint)向make()提供容量提示会在初始化时尝试调整map的大小这将减少在将元素添加到map时为map重新分配内存。
注意与slices不同。map capacity提示并不保证完全的抢占式分配而是用于估计所需的hashmap bucket的数量。 因此在将元素添加到map时甚至在指定map容量时仍可能发生分配。
BadGood
m : make(map[string]os.FileInfo)files, _ : ioutil.ReadDir(./files)
for _, f : range files {m[f.Name()] f
}files, _ : ioutil.ReadDir(./files)m : make(map[string]os.FileInfo, len(files))
for _, f : range files {m[f.Name()] f
}m 是在没有大小提示的情况下创建的 在运行时可能会有更多分配。
m 是有大小提示创建的在运行时可能会有更少的分配。
指定切片容量
在尽可能的情况下在使用make()初始化切片时提供容量信息特别是在追加切片时。
make([]T, length, capacity)与maps不同slice capacity不是一个提示编译器将为提供给make()的slice的容量分配足够的内存 这意味着后续的append()操作将导致零分配直到slice的长度与容量匹配在此之后任何append都可能调整大小以容纳其他元素。
BadGood
for n : 0; n b.N; n {data : make([]int, 0)for k : 0; k size; k{data append(data, k)}
}for n : 0; n b.N; n {data : make([]int, 0, size)for k : 0; k size; k{data append(data, k)}
}BenchmarkBad-4 100000000 2.48sBenchmarkGood-4 100000000 0.21s规范
一致性
本文中概述的一些标准都是客观性的评估是根据场景、上下文、或者主观性的判断
但是最重要的是保持一致.
一致性的代码更容易维护、是更合理的、需要更少的学习成本、并且随着新的约定出现或者出现错误后更容易迁移、更新、修复 bug
相反在一个代码库中包含多个完全不同或冲突的代码风格会导致维护成本开销、不确定性和认知偏差。所有这些都会直接导致速度降低、代码审查痛苦、而且增加 bug 数量。
将这些标准应用于代码库时建议在 package或更大级别进行更改子包级别的应用程序通过将多个样式引入到同一代码中违反了上述关注点。
相似的声明放在一组
Go 语言支持将相似的声明放在一个组内。
BadGood
import a
import bimport (ab
)这同样适用于常量、变量和类型声明
BadGood const a 1
const b 2var a 1
var b 2type Area float64
type Volume float64const (a 1b 2
)var (a 1b 2
)type (Area float64Volume float64
)仅将相关的声明放在一组。不要将不相关的声明放在一组。
BadGood
type Operation intconst (Add Operation iota 1SubtractMultiplyEnvVar MY_ENV
)type Operation intconst (Add Operation iota 1SubtractMultiply
)const EnvVar MY_ENV分组使用的位置没有限制例如你可以在函数内部使用它们
BadGood
func f() string {var red color.New(0xff0000)var green color.New(0x00ff00)var blue color.New(0x0000ff)...
}func f() string {var (red color.New(0xff0000)green color.New(0x00ff00)blue color.New(0x0000ff))...
}import 分组
导入应该分为两组
标准库其他库
默认情况下这是 goimports 应用的分组。
BadGood
import (fmtosgo.uber.org/atomicgolang.org/x/sync/errgroup
)import (fmtosgo.uber.org/atomicgolang.org/x/sync/errgroup
)包名
当命名包时请按下面规则选择一个名称
全部小写。没有大写或下划线。大多数使用命名导入的情况下不需要重命名。简短而简洁。请记住在每个使用的地方都完整标识了该名称。不用复数。例如net/url而不是net/urls。不要用“common”“util”“shared”或“lib”。这些是不好的信息量不足的名称。
另请参阅 Package Names 和 Go 包样式指南.
函数名
我们遵循 Go 社区关于使用 MixedCaps 作为函数名 的约定。有一个例外为了对相关的测试用例进行分组函数名可能包含下划线如TestMyFunction_WhatIsBeingTested.
导入别名
如果程序包名称与导入路径的最后一个元素不匹配则必须使用导入别名。
import (net/httpclient example.com/client-gotrace example.com/trace/v2
)在所有其他情况下除非导入之间有直接冲突否则应避免导入别名。
BadGood
import (fmtosnettrace golang.net/x/trace
)import (fmtosruntime/tracenettrace golang.net/x/trace
)函数分组与顺序
函数应按粗略的调用顺序排序。同一文件中的函数应按接收者分组。
因此导出的函数应先出现在文件中放在struct, const, var定义的后面。
在定义类型之后但在接收者的其余方法之前可能会出现一个 newXYZ()/NewXYZ()
由于函数是按接收者分组的因此普通工具函数应在文件末尾出现。
BadGood
func (s *something) Cost() {return calcCost(s.weights)
}type something struct{ ... }func calcCost(n []int) int {...}func (s *something) Stop() {...}func newSomething() *something {return something{}
}type something struct{ ... }func newSomething() *something {return something{}
}func (s *something) Cost() {return calcCost(s.weights)
}func (s *something) Stop() {...}func calcCost(n []int) int {...}减少嵌套
代码应通过尽可能先处理错误情况/特殊情况并尽早返回或继续循环来减少嵌套。减少嵌套多个级别的代码的代码量。
BadGood
for _, v : range data {if v.F1 1 {v process(v)if err : v.Call(); err nil {v.Send()} else {return err}} else {log.Printf(Invalid v: %v, v)}
}for _, v : range data {if v.F1 ! 1 {log.Printf(Invalid v: %v, v)continue}v process(v)if err : v.Call(); err ! nil {return err}v.Send()
}不必要的 else
如果在 if 的两个分支中都设置了变量则可以将其替换为单个 if。
BadGood
var a int
if b {a 100
} else {a 10
}a : 10
if b {a 100
}顶层变量声明
在顶层使用标准var关键字。请勿指定类型除非它与表达式的类型不同。
BadGood
var _s string F()func F() string { return A }var _s F()
// 由于 F 已经明确了返回一个字符串类型因此我们没有必要显式指定_s 的类型
// 还是那种类型func F() string { return A }如果表达式的类型与所需的类型不完全匹配请指定类型。
type myError struct{}func (myError) Error() string { return error }func F() myError { return myError{} }var _e error F()
// F 返回一个 myError 类型的实例但是我们要 error 类型对于未导出的顶层常量和变量使用_作为前缀
在未导出的顶级vars和consts 前面加上前缀_以使它们在使用时明确表示它们是全局符号。
例外未导出的错误值应以err开头。
基本依据顶级变量和常量具有包范围作用域。使用通用名称可能很容易在其他文件中意外使用错误的值。
BadGood
// foo.goconst (defaultPort 8080defaultUser user
)// bar.gofunc Bar() {defaultPort : 9090...fmt.Println(Default port, defaultPort)// We will not see a compile error if the first line of// Bar() is deleted.
}// foo.goconst (_defaultPort 8080_defaultUser user
)结构体中的嵌入
嵌入式类型例如 mutex应位于结构体内的字段列表的顶部并且必须有一个空行将嵌入式字段与常规字段分隔开。
BadGood
type Client struct {version inthttp.Client
}type Client struct {http.Clientversion int
}内嵌应该提供切实的好处比如以语义上合适的方式添加或增强功能。 它应该在对用户不利影响的情况下完成这项工作另请参见避免在公共结构中嵌入类型Avoid Embedding Types in Public Structs。
嵌入 不应该:
纯粹是为了美观或方便。使外部类型更难构造或使用。影响外部类型的零值。如果外部类型有一个有用的零值则在嵌入内部类型之后应该仍然有一个有用的零值。作为嵌入内部类型的副作用从外部类型公开不相关的函数或字段。公开未导出的类型。影响外部类型的复制形式。更改外部类型的API或类型语义。嵌入内部类型的非规范形式。公开外部类型的实现详细信息。允许用户观察或控制类型内部。通过包装的方式改变内部函数的一般行为这种包装方式会给用户带来一些意料之外情况。
简单地说有意识地和有目的地嵌入。一种很好的测试体验是 “是否所有这些导出的内部方法/字段都将直接添加到外部类型” 如果答案是some或no不要嵌入内部类型-而是使用字段。
BadGood
type A struct {// Bad: A.Lock() and A.Unlock() 现在可用// 不提供任何功能性好处并允许用户控制有关A的内部细节。sync.Mutex
}type countingWriteCloser struct {// Good: Write() 在外层提供用于特定目的// 并且委托工作到内部类型的Write()中。io.WriteClosercount int
}
func (w *countingWriteCloser) Write(bs []byte) (int, error) {w.count len(bs)return w.WriteCloser.Write(bs)
}type Book struct {// Bad: 指针更改零值的有用性io.ReadWriter// other fields
}
// later
var b Book
b.Read(...) // panic: nil pointer
b.String() // panic: nil pointer
b.Write(...) // panic: nil pointertype Book struct {// Good: 有用的零值bytes.Buffer// other fields
}
// later
var b Book
b.Read(...) // ok
b.String() // ok
b.Write(...) // oktype Client struct {sync.Mutexsync.WaitGroupbytes.Bufferurl.URL
}type Client struct {mtx sync.Mutexwg sync.WaitGroupbuf bytes.Bufferurl url.URL
}使用字段名初始化结构体
初始化结构体时应该指定字段名称。现在由 go vet 强制执行。
BadGood
k : User{John, Doe, true}k : User{FirstName: John,LastName: Doe,Admin: true,
}例外如果有 3 个或更少的字段则可以在测试表中省略字段名称。
tests : []struct{op Operationwant string
}{{Add, add},{Subtract, subtract},
}本地变量声明
如果将变量明确设置为某个值则应使用短变量声明形式 (:)。
BadGood
var s foos : foo但是在某些情况下var 使用关键字时默认值会更清晰。例如声明空切片。
BadGood
func f(list []int) {filtered : []int{}for _, v : range list {if v 10 {filtered append(filtered, v)}}
}func f(list []int) {var filtered []intfor _, v : range list {if v 10 {filtered append(filtered, v)}}
}nil 是一个有效的 slice
nil 是一个有效的长度为 0 的 slice这意味着 您不应明确返回长度为零的切片。应该返回nil 来代替。 BadGood if x {return []int{}
}if x {return nil
}要检查切片是否为空请始终使用len(s) 0。而非 nil。 BadGood func isEmpty(s []string) bool {return s nil
}func isEmpty(s []string) bool {return len(s) 0
}零值切片用var声明的切片可立即使用无需调用make()创建。 BadGood nums : []int{}
// or, nums : make([]int)if add1 {nums append(nums, 1)
}if add2 {nums append(nums, 2)
}var nums []intif add1 {nums append(nums, 1)
}if add2 {nums append(nums, 2)
}记住虽然nil切片是有效的切片但它不等于长度为0的切片一个为nil另一个不是并且在不同的情况下例如序列化这两个切片的处理方式可能不同。
缩小变量作用域
如果有可能尽量缩小变量作用范围。除非它与 减少嵌套的规则冲突。
BadGood
err : ioutil.WriteFile(name, data, 0644)
if err ! nil {return err
}if err : ioutil.WriteFile(name, data, 0644); err ! nil {return err
}如果需要在 if 之外使用函数调用的结果则不应尝试缩小范围。
BadGood
if data, err : ioutil.ReadFile(name); err nil {err cfg.Decode(data)if err ! nil {return err}fmt.Println(cfg)return nil
} else {return err
}data, err : ioutil.ReadFile(name)
if err ! nil {return err
}if err : cfg.Decode(data); err ! nil {return err
}fmt.Println(cfg)
return nil避免参数语义不明确(Avoid Naked Parameters)
函数调用中的意义不明确的参数可能会损害可读性。当参数名称的含义不明显时请为参数添加 C 样式注释 (/* ... */)
BadGood
// func printInfo(name string, isLocal, done bool)printInfo(foo, true, true)// func printInfo(name string, isLocal, done bool)printInfo(foo, true /* isLocal */, true /* done */)对于上面的示例代码还有一种更好的处理方式是将上面的 bool 类型换成自定义类型。将来该参数可以支持不仅仅局限于两个状态true/false。
type Region intconst (UnknownRegion Region iotaLocal
)type Status intconst (StatusReady Status iota 1StatusDone// Maybe we will have a StatusInProgress in the future.
)func printInfo(name string, region Region, status Status)使用原始字符串字面值避免转义
Go 支持使用 原始字符串字面值也就是 来表示原生字符串在需要转义的场景下我们应该尽量使用这种方案来替换。
可以跨越多行并包含引号。使用这些字符串可以避免更难阅读的手工转义的字符串。
BadGood
wantError : unknown name:\test\wantError : unknown error:test初始化结构体
使用字段名初始化结构
初始化结构时几乎应该始终指定字段名。目前由go vet强制执行。
BadGood
k : User{John, Doe, true}k : User{FirstName: John,LastName: Doe,Admin: true,
}例外当有3个或更少的字段时测试表中的字段名may可以省略。
tests : []struct{op Operationwant string
}{{Add, add},{Subtract, subtract},
}省略结构中的零值字段
初始化具有字段名的结构时除非提供有意义的上下文否则忽略值为零的字段。 也就是让我们自动将这些设置为零值
BadGood
user : User{FirstName: John,LastName: Doe,MiddleName: ,Admin: false,
}user : User{FirstName: John,LastName: Doe,
}这有助于通过省略该上下文中的默认值来减少阅读的障碍。只指定有意义的值。
在字段名提供有意义上下文的地方包含零值。例如表驱动测试 中的测试用例可以受益于字段的名称即使它们是零值的。
tests : []struct{give stringwant int
}{{give: 0, want: 0},// ...
}对零值结构使用 var
如果在声明中省略了结构的所有字段请使用 var 声明结构。
BadGood
user : User{}var user User这将零值结构与那些具有类似于为[初始化 Maps]创建的,区别于非零值字段的结构区分开来 并与我们更喜欢的declare empty slices方式相匹配。
初始化 Struct 引用
在初始化结构引用时请使用T{}代替new(T)以使其与结构体初始化一致。
BadGood
sval : T{Name: foo}// inconsistent
sptr : new(T)
sptr.Name barsval : T{Name: foo}sptr : T{Name: bar}初始化 Maps
对于空 map 请使用 make(..) 初始化 并且 map 是通过编程方式填充的。 这使得 map 初始化在表现上不同于声明并且它还可以方便地在 make 后添加大小提示。
BadGood
var (// m1 读写安全;// m2 在写入时会 panicm1 map[T1]T2{}m2 map[T1]T2
)var (// m1 读写安全;// m2 在写入时会 panicm1 make(map[T1]T2)m2 map[T1]T2
)声明和初始化看起来非常相似的。
声明和初始化看起来差别非常大。
在尽可能的情况下请在初始化时提供 map 容量大小详细请看 指定Map容量提示。
另外如果 map 包含固定的元素列表则使用 map literals(map 初始化列表) 初始化映射。
BadGood
m : make(map[T1]T2, 3)
m[k1] v1
m[k2] v2
m[k3] v3m : map[T1]T2{k1: v1,k2: v2,k3: v3,
}基本准则是在初始化时使用 map 初始化列表 来添加一组固定的元素。否则使用 make (如果可以请尽量指定 map 容量)。
字符串 string format
如果你在函数外声明Printf-style 函数的格式字符串请将其设置为const常量。
这有助于go vet对格式字符串执行静态分析。
BadGood
msg : unexpected values %v, %v\n
fmt.Printf(msg, 1, 2)const msg unexpected values %v, %v\n
fmt.Printf(msg, 1, 2)命名 Printf 样式的函数
声明Printf-style 函数时请确保go vet可以检测到它并检查格式字符串。
这意味着您应尽可能使用预定义的Printf-style 函数名称。go vet将默认检查这些。有关更多信息请参见 Printf 系列。
如果不能使用预定义的名称请以 f 结束选择的名称Wrapf而不是Wrap。go vet可以要求检查特定的 Printf 样式名称但名称必须以f结尾。
$ go vet -printfuncswrapf,statusf另请参阅 go vet: Printf family check.
编程模式
表驱动测试
当测试逻辑是重复的时候通过 subtests 使用 table 驱动的方式编写 case 代码看上去会更简洁。
BadGood
// func TestSplitHostPort(t *testing.T)host, port, err : net.SplitHostPort(192.0.2.0:8000)
require.NoError(t, err)
assert.Equal(t, 192.0.2.0, host)
assert.Equal(t, 8000, port)host, port, err net.SplitHostPort(192.0.2.0:http)
require.NoError(t, err)
assert.Equal(t, 192.0.2.0, host)
assert.Equal(t, http, port)host, port, err net.SplitHostPort(:8000)
require.NoError(t, err)
assert.Equal(t, , host)
assert.Equal(t, 8000, port)host, port, err net.SplitHostPort(1:8)
require.NoError(t, err)
assert.Equal(t, 1, host)
assert.Equal(t, 8, port)// func TestSplitHostPort(t *testing.T)tests : []struct{give stringwantHost stringwantPort string
}{{give: 192.0.2.0:8000,wantHost: 192.0.2.0,wantPort: 8000,},{give: 192.0.2.0:http,wantHost: 192.0.2.0,wantPort: http,},{give: :8000,wantHost: ,wantPort: 8000,},{give: 1:8,wantHost: 1,wantPort: 8,},
}for _, tt : range tests {t.Run(tt.give, func(t *testing.T) {host, port, err : net.SplitHostPort(tt.give)require.NoError(t, err)assert.Equal(t, tt.wantHost, host)assert.Equal(t, tt.wantPort, port)})
}很明显使用 test table 的方式在代码逻辑扩展的时候比如新增 test case都会显得更加的清晰。
我们遵循这样的约定将结构体切片称为tests。 每个测试用例称为tt。此外我们鼓励使用give和want前缀说明每个测试用例的输入和输出值。
tests : []struct{give stringwantHost stringwantPort string
}{// ...
}for _, tt : range tests {// ...
}功能选项
功能选项是一种模式您可以在其中声明一个不透明 Option 类型该类型在某些内部结构中记录信息。您接受这些选项的可变编号并根据内部结构上的选项记录的全部信息采取行动。
将此模式用于您需要扩展的构造函数和其他公共 API 中的可选参数尤其是在这些功能上已经具有三个或更多参数的情况下。
BadGood
// package dbfunc Open(addr string,cache bool,logger *zap.Logger
) (*Connection, error) {// ...
}// package dbtype Option interface {// ...
}func WithCache(c bool) Option {// ...
}func WithLogger(log *zap.Logger) Option {// ...
}// Open creates a connection.
func Open(addr string,opts ...Option,
) (*Connection, error) {// ...
}必须始终提供缓存和记录器参数即使用户希望使用默认值。
db.Open(addr, db.DefaultCache, zap.NewNop())
db.Open(addr, db.DefaultCache, log)
db.Open(addr, false /* cache */, zap.NewNop())
db.Open(addr, false /* cache */, log)只有在需要时才提供选项。
db.Open(addr)
db.Open(addr, db.WithLogger(log))
db.Open(addr, db.WithCache(false))
db.Open(addr,db.WithCache(false),db.WithLogger(log),
)Our suggested way of implementing this pattern is with an Option interface that holds an unexported method, recording options on an unexported options struct.
我们建议实现此模式的方法是使用一个 Option 接口该接口保存一个未导出的方法在一个未导出的 options 结构上记录选项。
type options struct {cache boollogger *zap.Logger
}type Option interface {apply(*options)
}type cacheOption boolfunc (c cacheOption) apply(opts *options) {opts.cache bool(c)
}func WithCache(c bool) Option {return cacheOption(c)
}type loggerOption struct {Log *zap.Logger
}func (l loggerOption) apply(opts *options) {opts.logger l.Log
}func WithLogger(log *zap.Logger) Option {return loggerOption{Log: log}
}// Open creates a connection.
func Open(addr string,opts ...Option,
) (*Connection, error) {options : options{cache: defaultCache,logger: zap.NewNop(),}for _, o : range opts {o.apply(options)}// ...
}注意: 还有一种使用闭包实现这个模式的方法但是我们相信上面的模式为作者提供了更多的灵活性并且更容易对用户进行调试和测试。特别是在不可能进行比较的情况下它允许在测试和模拟中对选项进行比较。此外它还允许选项实现其他接口包括 fmt.Stringer允许用户读取选项的字符串表示形式。
还可以参考下面资料 Self-referential functions and the design of options Functional options for friendly APIs Linting
比任何 “blessed” linter 集更重要的是lint在一个代码库中始终保持一致。
我们建议至少使用以下linters因为我认为它们有助于发现最常见的问题并在不需要规定的情况下为代码质量建立一个高标准 errcheck 以确保错误得到处理 goimports 格式化代码和管理 imports golint 指出常见的文体错误 govet 分析代码中的常见错误 staticcheck 各种静态分析检查
Lint Runners
我们推荐 golangci-lint 作为go-to lint的运行程序这主要是因为它在较大的代码库中的性能以及能够同时配置和使用许多规范。这个repo有一个示例配置文件.golangci.yml和推荐的linter设置。
golangci-lint 有various-linters可供使用。建议将上述linters作为基本set我们鼓励团队添加对他们的项目有意义的任何附加linters。
Stargazers over time
