uber-go/guide 的中文翻译
English
Uber Go 语言编码规范
Uber 是一家美国硅谷的科技公司,也是 Go 语言的早期 adopter。其开源了很多 golang 项目,诸如被 Gopher 圈熟知的 zap、jaeger 等。2018 年年末 Uber 将内部的 Go 风格规范 开源到 GitHub,经过一年的积累和更新,该规范已经初具规模,并受到广大 Gopher 的关注。本文是该规范的中文版本。本版本会根据原版实时更新。
版本
- 当前更新版本:2020-06-05 版本地址:commit:#93
- 如果您发现任何更新、问题或改进,请随时 fork 和 PR
- Please feel free to fork and PR if you find any updates, issues or improvement.
目录
- 2019-12-17
- 2019-11-26
- 2020-01-11
- 2020-02-03
- 2020-02-25
- 2020-06-05
- uber-go/guide 的中文翻译
- English
- Uber Go 语言编码规范
介绍
样式 (style) 是支配我们代码的惯例。术语样式
有点用词不当,因为这些约定涵盖的范围不限于由 gofmt 替我们处理的源文件格式。
本指南的目的是通过详细描述在 Uber 编写 Go 代码的注意事项来管理这种复杂性。这些规则的存在是为了使代码库易于管理,同时仍然允许工程师更有效地使用 Go 语言功能。
该指南最初由 Prashant Varanasi 和 Simon Newton 编写,目的是使一些同事能快速使用 Go。多年来,该指南已根据其他人的反馈进行了修改。
本文档记录了我们在 Uber 遵循的 Go 代码中的惯用约定。其中许多是 Go 的通用准则,而其他扩展准则依赖于下面外部的指南:
所有代码都应该通过golint
和go vet
的检查并无错误。我们建议您将编辑器设置为:
- 保存时运行
goimports
- 运行
golint
和go vet
检查错误
您可以在以下 Go 编辑器工具支持页面中找到更为详细的信息:
https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins
指导原则
指向 interface 的指针
您几乎不需要指向接口类型的指针。您应该将接口作为值进行传递,在这样的传递过程中,实质上传递的底层数据仍然可以是指针。
接口实质上在底层用两个字段表示:
- 一个指向某些特定类型信息的指针。您可以将其视为”type”。
- 数据指针。如果存储的数据是指针,则直接存储。如果存储的数据是一个值,则存储指向该值的指针。
如果希望接口方法修改基础数据,则必须使用指针传递。
Interface 合理性验证
在编译时验证接口的符合性。这包括:
- 将实现特定接口所需的导出类型作为其 API 的一部分
- 导出或未导出的类型是实现同一接口的类型集合的一部分
- 其他违反接口的情况会破坏用户。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
如果 *Handler
永远不会与 http.Handler
接口匹配,那么语句 var _ http.Handler = (*Handler)(nil)
将无法编译
赋值的右边应该是断言类型的零值。对于指针类型(如 *Handler
)、切片和映射,这是 nil
;对于结构类型,这是空结构。
1 | type LogHandler struct { |
接收器 (receiver) 与接口
使用值接收器的方法既可以通过值调用,也可以通过指针调用。
例如,
1 | type S struct { |
同样,即使该方法具有值接收器,也可以通过指针来满足接口。
1 | type F interface { |
Effective Go 中有一段关于 pointers vs. values 的精彩讲解。
零值 Mutex 是有效的
零值 sync.Mutex
和 sync.RWMutex
是有效的。所以指向 mutex 的指针基本是不必要的。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
如果你使用结构体指针,mutex 可以非指针形式作为结构体的组成字段,或者更好的方式是直接嵌入到结构体中。
如果是私有结构体类型或是要实现 Mutex 接口的类型,我们可以使用嵌入 mutex 的方法:
|
| ||||
为私有类型或需要实现互斥接口的类型嵌入。 | 对于导出的类型,请使用专用字段。 |
在边界处拷贝 Slices 和 Maps
slices 和 maps 包含了指向底层数据的指针,因此在需要复制它们时要特别注意。
接收 Slices 和 Maps
请记住,当 map 或 slice 作为函数参数传入时,如果您存储了对它们的引用,则用户可以对其进行修改。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
返回 slices 或 maps
同样,请注意用户对暴露内部状态的 map 或 slice 的修改。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
使用 defer 释放资源
使用 defer 释放资源,诸如文件和锁。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
Defer 的开销非常小,只有在您可以证明函数执行时间处于纳秒级的程度时,才应避免这样做。使用 defer 提升可读性是值得的,因为使用它们的成本微不足道。尤其适用于那些不仅仅是简单内存访问的较大的方法,在这些方法中其他计算的资源消耗远超过 defer
。
Channel 的 size 要么是 1,要么是无缓冲的
channel 通常 size 应为 1 或是无缓冲的。默认情况下,channel 是无缓冲的,其 size 为零。任何其他尺寸都必须经过严格的审查。我们需要考虑如何确定大小,考虑是什么阻止了 channel 在高负载下和阻塞写时的写入,以及当这种情况发生时系统逻辑有哪些变化。(翻译解释:按照原文意思是需要界定通道边界,竞态条件,以及逻辑上下文梳理)
Bad | Good | ||||
---|---|---|---|---|---|
|
|
枚举从 1 开始
在 Go 中引入枚举的标准方法是声明一个自定义类型和一个使用了 iota 的 const 组。由于变量的默认值为 0,因此通常应以非零值开头枚举。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
在某些情况下,使用零值是有意义的(枚举从零开始),例如,当零值是理想的默认行为时。
1 | type LogOutput int |
使用 time 处理时间
时间处理很复杂。关于时间的错误假设通常包括以下几点。
- 一天有 24 小时
- 一小时有 60 分钟
- 一周有七天
- 一年 365 天
- 还有更多
例如,1 表示在一个时间点上加上 24 小时并不总是产生一个新的日历日。
因此,在处理时间时始终使用 "time"
包,因为它有助于以更安全、更准确的方式处理这些不正确的假设。
使用 time.Time
表达瞬时时间
在处理时间的瞬间时使用 time.time
,在比较、添加或减去时间时使用 time.Time
中的方法。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
使用 time.Duration
表达时间段
在处理时间段时使用 time.Duration
.
Bad | Good | ||||
---|---|---|---|---|---|
|
|
回到第一个例子,在一个时间瞬间加上 24 小时,我们用于添加时间的方法取决于意图。如果我们想要下一个日历日(当前天的下一天)的同一个时间点,我们应该使用 Time.AddDate
。但是,如果我们想保证某一时刻比前一时刻晚 24 小时,我们应该使用 Time.Add
。
1 | newDay := t.AddDate(0 /* years */, 0, /* months */, 1 /* days */) |
对外部系统使用 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
,因此该单位包含在字段的名称中。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
当在这些交互中不能使用 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
,请使用一个错误变量。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
如果您有可能需要客户端检测的错误,并且想向其中添加更多信息(例如,它不是静态字符串),则应使用自定义类型。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
直接导出自定义错误类型时要小心,因为它们已成为程序包公共 API 的一部分。最好公开匹配器功能以检查错误。
1 | // package foo |
错误包装 (Error Wrapping)
一个(函数/方法)调用失败时,有三种主要的错误传播方式:
- 如果没有要添加的其他上下文,并且您想要维护原始错误类型,则返回原始错误。
- 添加上下文,使用
"pkg/errors".Wrap
以便错误消息提供更多上下文 ,"pkg/errors".Cause
可用于提取原始错误。 - 如果调用者不需要检测或处理的特定错误情况,使用
fmt.Errorf
。
建议在可能的地方添加上下文,以使您获得诸如“调用服务 foo:连接被拒绝”之类的更有用的错误,而不是诸如“连接被拒绝”之类的模糊错误。
在将上下文添加到返回的错误时,请避免使用“failed to”之类的短语以保持上下文简洁,这些短语会陈述明显的内容,并随着错误在堆栈中的渗透而逐渐堆积:
Bad | Good | ||||
---|---|---|---|---|---|
|
| ||||
|
|
但是,一旦将错误发送到另一个系统,就应该明确消息是错误消息(例如使用err
标记,或在日志中以”Failed”为前缀)。
另请参见 Don’t just check errors, handle them gracefully. 不要只是检查错误,要优雅地处理错误
处理类型断言失败
type assertion 的单个返回值形式针对不正确的类型将产生 panic。因此,请始终使用“comma ok”的惯用法。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
不要 panic
在生产环境中运行的代码必须避免出现 panic。panic 是 cascading failures 级联失败的主要根源 。如果发生错误,该函数必须返回错误,并允许调用方决定如何处理它。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
panic/recover 不是错误处理策略。仅当发生不可恢复的事情(例如:nil 引用)时,程序才必须 panic。程序初始化是一个例外:程序启动时应使程序中止的不良情况可能会引起 panic。
1 | var _statusTemplate = template.Must(template.New("name").Parse("_statusHTML")) |
即使在测试代码中,也优先使用t.Fatal
或者t.FailNow
而不是 panic 来确保失败被标记。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
使用 go.uber.org/atomic
使用 sync/atomic 包的原子操作对原始类型 (int32
, int64
等)进行操作,因为很容易忘记使用原子操作来读取或修改变量。
go.uber.org/atomic 通过隐藏基础类型为这些操作增加了类型安全性。此外,它包括一个方便的atomic.Bool
类型。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
避免可变全局变量
使用选择依赖注入方式避免改变全局变量。
既适用于函数指针又适用于其他值类型
Bad | Good | ||||
---|---|---|---|---|---|
|
| ||||
|
|
避免在公共结构中嵌入类型
这些嵌入的类型泄漏实现细节、禁止类型演化和模糊的文档。
假设您使用共享的 AbstractList
实现了多种列表类型,请避免在具体的列表实现中嵌入 AbstractList
。
相反,只需手动将方法写入具体的列表,该列表将委托给抽象列表。
1 | type AbstractList struct {} |
Bad | Good | ||||
---|---|---|---|---|---|
|
|
Go 允许 类型嵌入 作为继承和组合之间的折衷。
外部类型获取嵌入类型的方法的隐式副本。
默认情况下,这些方法委托给嵌入实例的同一方法。
结构还获得与类型同名的字段。
所以,如果嵌入的类型是 public,那么字段是 public。为了保持向后兼容性,外部类型的每个未来版本都必须保留嵌入类型。
很少需要嵌入类型。
这是一种方便,可以帮助您避免编写冗长的委托方法。
即使嵌入兼容的抽象列表 interface,而不是结构体,这将为开发人员提供更大的灵活性来改变未来,但仍然泄露了具体列表使用抽象实现的细节。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
无论是使用嵌入式结构还是使用嵌入式接口,嵌入式类型都会限制类型的演化.
- 向嵌入式接口添加方法是一个破坏性的改变。
- 删除嵌入类型是一个破坏性的改变。
- 即使使用满足相同接口的替代方法替换嵌入类型,也是一个破坏性的改变。
尽管编写这些委托方法是乏味的,但是额外的工作隐藏了实现细节,留下了更多的更改机会,还消除了在文档中发现完整列表接口的间接性操作。
避免使用内置名称
Go语言规范language specification 概述了几个内置的,
不应在Go项目中使用的名称标识predeclared identifiers。
根据上下文的不同,将这些标识符作为名称重复使用,
将在当前作用域(或任何嵌套作用域)中隐藏原始标识符,或者混淆代码。
在最好的情况下,编译器会报错;在最坏的情况下,这样的代码可能会引入潜在的、难以恢复的错误。
Bad | Good | ||||
---|---|---|---|---|---|
|
| ||||
|
|
注意,编译器在使用预先分隔的标识符时不会生成错误,
但是诸如go vet
之类的工具会正确地指出这些和其他情况下的隐式问题。
性能
性能方面的特定准则只适用于高频场景。
优先使用 strconv 而不是 fmt
将原语转换为字符串或从字符串转换时,strconv
速度比fmt
快。
Bad | Good | ||||
---|---|---|---|---|---|
|
| ||||
|
|
避免字符串到字节的转换
不要反复从固定字符串创建字节 slice。相反,请执行一次转换并捕获结果。
Bad | Good | ||||
---|---|---|---|---|---|
|
| ||||
|
|
尽量初始化时指定 Map 容量
在尽可能的情况下,在使用 make()
初始化的时候提供容量信息
1 | make(map[T1]T2, hint) |
为 make()
提供容量信息(hint)尝试在初始化时调整 map 大小,
这减少了在将元素添加到 map 时增长和分配的开销。
注意,map 不能保证分配 hint 个容量。因此,即使提供了容量,添加元素仍然可以进行分配。
Bad | Good | ||||
---|---|---|---|---|---|
|
| ||||
m 是在没有大小提示的情况下创建的; 在运行时可能会有更多分配。 | m 是有大小提示创建的;在运行时可能会有更少的分配。 |
规范
一致性
本文中概述的一些标准都是客观性的评估,是根据场景、上下文、或者主观性的判断;
但是最重要的是,保持一致.
一致性的代码更容易维护、是更合理的、需要更少的学习成本、并且随着新的约定出现或者出现错误后更容易迁移、更新、修复 bug
相反,一个单一的代码库会导致维护成本开销、不确定性和认知偏差。所有这些都会直接导致速度降低、
代码审查痛苦、而且增加 bug 数量
将这些标准应用于代码库时,建议在 package(或更大)级别进行更改,子包级别的应用程序通过将多个样式引入到同一代码中,违反了上述关注点。
相似的声明放在一组
Go 语言支持将相似的声明放在一个组内。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
这同样适用于常量、变量和类型声明:
Bad | Good | ||||
---|---|---|---|---|---|
|
|
仅将相关的声明放在一组。不要将不相关的声明放在一组。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
分组使用的位置没有限制,例如:你可以在函数内部使用它们:
Bad | Good | ||||
---|---|---|---|---|---|
|
|
import 分组
导入应该分为两组:
- 标准库
- 其他库
默认情况下,这是 goimports 应用的分组。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
包名
当命名包时,请按下面规则选择一个名称:
- 全部小写。没有大写或下划线。
- 大多数使用命名导入的情况下,不需要重命名。
- 简短而简洁。请记住,在每个使用的地方都完整标识了该名称。
- 不用复数。例如
net/url
,而不是net/urls
。 - 不要用“common”,“util”,“shared”或“lib”。这些是不好的,信息量不足的名称。
另请参阅 Package Names 和 Go 包样式指南.
函数名
我们遵循 Go 社区关于使用 MixedCaps 作为函数名 的约定。有一个例外,为了对相关的测试用例进行分组,函数名可能包含下划线,如:TestMyFunction_WhatIsBeingTested
.
导入别名
如果程序包名称与导入路径的最后一个元素不匹配,则必须使用导入别名。
1 | import ( |
在所有其他情况下,除非导入之间有直接冲突,否则应避免导入别名。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
函数分组与顺序
- 函数应按粗略的调用顺序排序。
- 同一文件中的函数应按接收者分组。
因此,导出的函数应先出现在文件中,放在struct
, const
, var
定义的后面。
在定义类型之后,但在接收者的其余方法之前,可能会出现一个 newXYZ()
/NewXYZ()
由于函数是按接收者分组的,因此普通工具函数应在文件末尾出现。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
减少嵌套
代码应通过尽可能先处理错误情况/特殊情况并尽早返回或继续循环来减少嵌套。减少嵌套多个级别的代码的代码量。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
不必要的 else
如果在 if 的两个分支中都设置了变量,则可以将其替换为单个 if。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
顶层变量声明
在顶层,使用标准var
关键字。请勿指定类型,除非它与表达式的类型不同。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
如果表达式的类型与所需的类型不完全匹配,请指定类型。
1 | type myError struct{} |
对于未导出的顶层常量和变量,使用_作为前缀
在未导出的顶级vars
和consts
, 前面加上前缀_,以使它们在使用时明确表示它们是全局符号。
例外:未导出的错误值,应以err
开头。
基本依据:顶级变量和常量具有包范围作用域。使用通用名称可能很容易在其他文件中意外使用错误的值。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
结构体中的嵌入
嵌入式类型(例如 mutex)应位于结构体内的字段列表的顶部,并且必须有一个空行将嵌入式字段与常规字段分隔开。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
使用字段名初始化结构体
初始化结构体时,几乎始终应该指定字段名称。现在由 go vet
强制执行。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
例外:如果有 3 个或更少的字段,则可以在测试表中省略字段名称。
1 | tests := []struct{ |
本地变量声明
如果将变量明确设置为某个值,则应使用短变量声明形式 (:=
)。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
但是,在某些情况下,var
使用关键字时默认值会更清晰。例如,声明空切片。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
nil 是一个有效的 slice
nil
是一个有效的长度为 0 的 slice,这意味着,
您不应明确返回长度为零的切片。应该返回
nil
来代替。Bad Good 1
2
3if x == "" {
return []int{}
}1
2
3if x == "" {
return nil
}要检查切片是否为空,请始终使用
len(s) == 0
。而非nil
。Bad Good 1
2
3func isEmpty(s []string) bool {
return s == nil
}1
2
3func isEmpty(s []string) bool {
return len(s) == 0
}零值切片(用
var
声明的切片)可立即使用,无需调用make()
创建。Bad Good 1
2
3
4
5
6
7
8
9
10nums := []int{}
// or, nums := make([]int)
if add1 {
nums = append(nums, 1)
}
if add2 {
nums = append(nums, 2)
}1
2
3
4
5
6
7
8
9var nums []int
if add1 {
nums = append(nums, 1)
}
if add2 {
nums = append(nums, 2)
}
记住,虽然nil切片是有效的切片,但它不等于长度为0的切片(一个为nil,另一个不是),并且在不同的情况下(例如序列化),这两个切片的处理方式可能不同。
缩小变量作用域
如果有可能,尽量缩小变量作用范围。除非它与 减少嵌套的规则冲突。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
如果需要在 if 之外使用函数调用的结果,则不应尝试缩小范围。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
避免参数语义不明确(Avoid Naked Parameters)
函数调用中的意义不明确的参数
可能会损害可读性。当参数名称的含义不明显时,请为参数添加 C 样式注释 (/* ... */
)
Bad | Good | ||||
---|---|---|---|---|---|
|
|
对于上面的示例代码,还有一种更好的处理方式是将上面的 bool
类型换成自定义类型。将来,该参数可以支持不仅仅局限于两个状态(true/false)。
1 | type Region int |
使用原始字符串字面值,避免转义
Go 支持使用 原始字符串字面值,也就是 “ ` “ 来表示原生字符串,在需要转义的场景下,我们应该尽量使用这种方案来替换。
可以跨越多行并包含引号。使用这些字符串可以避免更难阅读的手工转义的字符串。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
初始化 Struct 引用
在初始化结构引用时,请使用&T{}
代替new(T)
,以使其与结构体初始化一致。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
初始化 Maps
对于空 map 请使用 make(..)
初始化, 并且 map 是通过编程方式填充的。
这使得 map 初始化在表现上不同于声明,并且它还可以方便地在 make 后添加大小提示。
Bad | Good | ||||
---|---|---|---|---|---|
|
| ||||
声明和初始化看起来非常相似的。 | 声明和初始化看起来差别非常大。 |
在尽可能的情况下,请在初始化时提供 map 容量大小,详细请看 尽量初始化时指定 Map 容量。
另外,如果 map 包含固定的元素列表,则使用 map literals(map 初始化列表) 初始化映射。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
基本准则是:在初始化时使用 map 初始化列表 来添加一组固定的元素。否则使用 make
(如果可以,请尽量指定 map 容量)。
字符串 string format
如果你在函数外声明Printf
-style 函数的格式字符串,请将其设置为const
常量。
这有助于go vet
对格式字符串执行静态分析。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
命名 Printf 样式的函数
声明Printf
-style 函数时,请确保go vet
可以检测到它并检查格式字符串。
这意味着您应尽可能使用预定义的Printf
-style 函数名称。go vet
将默认检查这些。有关更多信息,请参见 Printf 系列。
如果不能使用预定义的名称,请以 f 结束选择的名称:Wrapf
,而不是Wrap
。go vet
可以要求检查特定的 Printf 样式名称,但名称必须以f
结尾。
1 | go vet -printfuncs=wrapf,statusf |
另请参阅 go vet: Printf family check.
编程模式
表驱动测试
当测试逻辑是重复的时候,通过 subtests 使用 table 驱动的方式编写 case 代码看上去会更简洁。
Bad | Good | ||||
---|---|---|---|---|---|
|
|
很明显,使用 test table 的方式在代码逻辑扩展的时候,比如新增 test case,都会显得更加的清晰。
我们遵循这样的约定:将结构体切片称为tests
。 每个测试用例称为tt
。此外,我们鼓励使用give
和want
前缀说明每个测试用例的输入和输出值。
1 | tests := []struct{ |
功能选项
功能选项是一种模式,您可以在其中声明一个不透明 Option 类型,该类型在某些内部结构中记录信息。您接受这些选项的可变编号,并根据内部结构上的选项记录的全部信息采取行动。
将此模式用于您需要扩展的构造函数和其他公共 API 中的可选参数,尤其是在这些功能上已经具有三个或更多参数的情况下。
Bad | Good | ||||
---|---|---|---|---|---|
|
| ||||
必须始终提供缓存和记录器参数,即使用户希望使用默认值。
| 只有在需要时才提供选项。
|
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
结构上记录选项。
1 | type options struct { |
注意: 还有一种使用闭包实现这个模式的方法,但是我们相信上面的模式为作者提供了更多的灵活性,并且更容易对用户进行调试和测试。特别是,在不可能进行比较的情况下它允许在测试和模拟中对选项进行比较。此外,它还允许选项实现其他接口,包括 fmt.Stringer
,允许用户读取选项的字符串表示形式。
还可以参考下面资料: