这篇想和大家聊一聊golang的常用代码写法。在golang中,如果大家不断在一线写代码,一定多多少少会有一些些代码的套路和经验。这些经验是代表你对一些问题,或者一类问题的思考和解决。处理一个问题的方法有很多,如果频繁遇到同样的场景和问题,我们会自己思考有没有更好的方式来解决,所以也就有了一些代码套路了。这里,我想和大家分享一下我个人在开发过程中看到和使用到的一些常用的代码写法。

文章中总结了四个golang中常用的写法

  • 使用pkg/error而不是官方error库
  • 在初始化slice的时候尽量补全cap
  • 初始化一个类的时候,如果类的构造参数较多,尽量使用Option写法
  • 巧用大括号控制变量作用域

使用pkg/error而不是官方error库

其实我们可以思考一下,我们在一个项目中使用错误机制,最核心的几个需求是什么?
1 附加信息:我们希望错误出现的时候能附带一些描述性的错误信息,甚至于这些信息是可以嵌套的。
2 附加堆栈:我们希望错误不仅仅打印出错误信息,也能打印出这个错误的堆栈信息,让我们可以知道错误的信息。
在Go的语言演进过程中,error传递的信息太少一直是被诟病的一点。我推荐在应用层使用 github.com/pkg/errors 来替换官方的error库。
假设我们有一个项目叫errdemo,他有sub1,sub2两个子包。sub1和sub2两个包都有Diff和IoDiff两个函数。
Golang中常用的代码优化点 - 图1

  1. // sub2.go
  2. package sub2
  3. import (
  4. "errors"
  5. "io/ioutil"
  6. )
  7. func Diff(foo int, bar int) error {
  8. return errors.New("diff error")
  9. }
  10. // sub1.go
  11. package sub1
  12. import (
  13. "errdemo/sub1/sub2"
  14. "fmt"
  15. "errors"
  16. )
  17. func Diff(foo int, bar int) error {
  18. if foo < 0 {
  19. return errors.New("diff error")
  20. }
  21. if err := sub2.Diff(foo, bar); err != nil {
  22. return err
  23. }
  24. return nil
  25. }
  26. // main.go
  27. package main
  28. import (
  29. "errdemo/sub1"
  30. "fmt"
  31. )
  32. func main() {
  33. err := sub1.Diff(1, 2)
  34. fmt.Println(err)
  35. }

在上述三段代码中,我们很不幸地将sub1.go中的Diff返回的error和sub2.go中Diff返回的error都定义为同样的字符串“diff error”。这个时候,在main.go中,我们返回的error,是无论如何也判断不出这个error是从sub1 还是 sub2 中抛出的。调试的时候会带来很大的困扰。
Golang中常用的代码优化点 - 图2
image-20211219171226288
而使用 github.com/pkg/errors ,我们所有的代码都不需要进行修改,只需要将import地方进行对应的修改即可。
在main.go中使用fmt.Printf(“%+v”, err) 就能除了打印error的信息,也能将堆栈打印出来了。

  1. // sub2.go
  2. package sub2
  3. import (
  4. "github.com/pkg/errors"
  5. "io/ioutil"
  6. )
  7. func Diff(foo int, bar int) error {
  8. return errors.New("diff error")
  9. }
  10. // sub1.go
  11. package sub1
  12. import (
  13. "errdemo/sub1/sub2"
  14. "fmt"
  15. "github.com/pkg/errors"
  16. )
  17. func Diff(foo int, bar int) error {
  18. if foo < 0 {
  19. return errors.New("diff error")
  20. }
  21. if err := sub2.Diff(foo, bar); err != nil {
  22. return err
  23. }
  24. return nil
  25. }
  26. // main.go
  27. package main
  28. import (
  29. "errdemo/sub1"
  30. "fmt"
  31. )
  32. func main() {
  33. err := sub1.Diff(1, 2)
  34. fmt.Printf("%+v", err)
  35. }

Golang中常用的代码优化点 - 图3

看到,除了”diff error” 的错误信息之外,还将堆栈大衣拿出来了,我们能明确看到是sub2.go中第7行抛出的错误。
其实 github.com/pkg/errors 的原理也是非常简单,它利用了fmt包的一个特性:
其中在打印error之前会判断当前打印的对象是否实现了Formatter接口,这个formatter接口只有一个format方法
Golang中常用的代码优化点 - 图4

所以在 github.com/pkg/errors 中提供的各种初始化error方法(包括errors.New)就是封装了一个fundamental 结构,这个结构中带着error的信息和堆栈信息
Golang中常用的代码优化点 - 图5

它实现了Format方法。
Golang中常用的代码优化点 - 图6

在初始化slice的时候尽量补全cap

当我们要创建一个slice结构,并且往slice中append元素的时候,我们可能有两种写法来初始化这个slice。
方法1:

  1. package main
  2. import "fmt"
  3. func main() {
  4. arr := []int{}
  5. arr = append(arr, 1,2,3,4, 5)
  6. fmt.Println(arr)
  7. }

方法2:

  1. package main
  2. import "fmt"
  3. func main() {
  4. arr := make([]int, 0, 5)
  5. arr = append(arr, 1,2,3,4, 5)
  6. fmt.Println(arr)
  7. }

方法2相较于方法1,就只有一个区别:在初始化[]int slice的时候在make中设置了cap的长度,就是slice的大小。
这两种方法对应的功能和输出结果是没有任何差别的,但是实际运行的时候,方法2会比少运行了一个growslice的命令。
这个我们可以通过打印汇编码进行查看:
方法1:
Golang中常用的代码优化点 - 图7

方法2:
Golang中常用的代码优化点 - 图8
image-20211219174112164
我们看到方法1中使用了growsslice方法,而方法2中是没有调用这个方法的。
这个growslice的作用就是扩充slice的容量大小。就好比是原先我们没有定制容量,系统给了我们一个能装两个鞋子的盒子,但是当我们装到第三个鞋子的时候,这个盒子就不够了,我们就要换一个盒子,而换这个盒子,我们势必还需要将原先的盒子里面的鞋子也拿出来放到新的盒子里面。所以这个growsslice的操作是一个比较复杂的操作,它的表现和复杂度会高于最基本的初始化make方法。对追求性能的程序来说,应该能避免尽量避免。
具体对growsslice函数具体实现同学有兴趣的可以参考源码src的 runtime/slice.go 。
当然,我们并不是每次都能在slice初始化的时候就能准确预估到最终的使用容量的。所以这里使用了一个“尽量”。明白是否设置slice容量的区别,我们在能预估容量的时候,请尽量使用方法2那种预估容量后的slice初始化方式。

初始化一个类的时候,如果类的构造参数较多,尽量使用Option写法

我们一定遇到需要初始化一个类的时候,大部分的时候,初始化一个类我们会使用类似下列的New方法。

  1. package newdemo
  2. type Foo struct {
  3. name string
  4. id int
  5. age int
  6. db interface{}
  7. }
  8. func NewFoo(name string, id int, age int, db interface{}) *Foo {
  9. return &Foo{
  10. name: name,
  11. id: id,
  12. age: age,
  13. db: db,
  14. }
  15. }

我们定义一个NewFoo方法,其中存放初始化Foo结构所需要的各种字段属性。
这个写法乍看之下是没啥问题的,但是一旦Foo结构内部的字段进行了变化,增加或者减少了,那么这个初始化函数NewFoo就怎么看怎么别扭了。参数继续增加?那么所有调用方的地方也都需要进行修改了,且按照代码整洁的逻辑,参数多于5个,这个函数就很难使用了。而且,如果这5个参数都是可有可无的参数,就是有的参数可以允许不填写,有默认值,比如age这个字段,如果不填写,在后续的业务逻辑中可能没有很多影响,那么我在实际调用NewFoo的时候,age这个字段还需要传递0值。
foo := NewFoo(“jianfengye”, 1, 0, nil)

这种语意逻辑就不对了。
这里其实有一种更好的写法:使用Option写法来进行改造。Option写法顾命思议,将所有可选的参数作为一个可选方式,一般我们会一定一个“函数类型”来代表这个Option,然后配套将所有可选字段设计一个这个函数类型的具体实现。而在具体的使用的时候,使用可变字段的方式来控制有多少个函数类型会被执行。比如上述的代码,我们会改造为:

  1. type Foo struct {
  2. name string
  3. id int
  4. age int
  5. db interface{}
  6. }
  7. // FooOption 代表可选参数
  8. type FooOption func(foo *Foo)
  9. // WithName 代表Name为可选参数
  10. func WithName(name string) FooOption {
  11. return func(foo *Foo) {
  12. foo.name = name
  13. }
  14. }
  15. // WithAge 代表age为可选参数
  16. func WithAge(age int) FooOption {
  17. return func(foo *Foo) {
  18. foo.age = age
  19. }
  20. }
  21. // WithDB 代表db为可选参数
  22. func WithDB(db interface{}) FooOption {
  23. return func(foo *Foo) {
  24. foo.db = db
  25. }
  26. }
  27. // NewFoo 代表初始化
  28. func NewFoo(id int, options ...FooOption) *Foo {
  29. foo := &Foo{
  30. name: "default",
  31. id: id,
  32. age: 10,
  33. db: nil,
  34. }
  35. for _, option := range options {
  36. option(foo)
  37. }
  38. return foo
  39. }

解释下上面的这段代码,我们创建了一个FooOption的函数类型,这个函数类型代表的函数结构是 func(foo *Foo) ,很简单,将foo指针传递进去,能让内部函数进行修改。
然后我们定义了三个返回了FooOption的函数:

  • WithName
  • WithAge
  • WithDB

以WithName为例,这个函数参数为string,返回值为FooOption。在返回值的FooOption中,根据参数修改了Foo指针。

  1. // WithName 代表Name为可选参数
  2. func WithName(name string) FooOption {
  3. return func(foo *Foo) {
  4. foo.name = name
  5. }
  6. }

顺便说一下,这种函数我们一般都以With开头,表示我这次初始化“带着”这个字段。
而最后NewFoo函数,参数我们就改造为两个部分,一个部分是“非Option”字段,就是必填字段,假设我们的Foo结构实际上只有一个必填字段id,而其他字段皆是选填的。而其他所有选填字段,我们使用一个可变参数 options 替换。

  1. NewFoo(id int, options ...FooOption)

在具体的实现中,也变化成2个步骤:

  • 按照默认值初始化一个foo对象
  • 遍历options改造这个foo对象

按照这样改造之后,我们具体使用Foo结构的函数就变为如下样子:

  1. // 具体使用NewFoo的函数
  2. func Bar() {
  3. foo := NewFoo(1, WithAge(15), WithName("foo"))
  4. fmt.Println(foo)
  5. }

可读性是否高了很多?New一个Foo结构,id为1,并且带着指定age为15,指定name为“foo”。
后续如果Foo多了一个可变属性,那么只需要多一个WithXXX的方法,而NewFoo函数不需要任何变化,调用方只有需要指定这个可变属性的地方增加WithXXX即可。扩展性非常好。
这种Option的写法在很多著名的库中都有使用到,gorm, go-redis等。所以我们要把这种方式熟悉起来,一旦我们在需要对一个比较复杂的类进行初始化的时候,这种方法应该是最优的方式了。

巧用大括号控制变量作用域

在golang写的过程中,你一定有过为 := 和 = 烦恼的时刻。一个变量,到写的时候,我还要记得前面是否已经定义过了,如果没有定义过,使用 := ,如果已经定义过,使用 =。
当然很多时候可能你不会犯这种错误,变量命名的比较好的话,我们是很容易记得是否前面有定义过的。但是更多时候,对于err这种通用的变量名字,你可能就不一定记得了。
这个时候,巧妙使用大括号,就能很好避免这个问题。
我举一个我之前写一个命令行工具的例子,大家知道写命令行工具,对传递的参数的解析是需要有一些逻辑的,“如果参数中有某个字段,那么解析并存储到变量中,如果没有,记录error”,这里我就使用了大括号,将每个参数的解析和处理错误的逻辑都封装起来。
代码大致如下:

  1. var name string
  2. var folder string
  3. var mod string
  4. ...
  5. {
  6. prompt := &survey.Input{
  7. Message: "请输入目录名称:",
  8. }
  9. err := survey.AskOne(prompt, &name)
  10. if err != nil {
  11. return err
  12. }
  13. ...
  14. }
  15. {
  16. prompt := &survey.Input{
  17. Message: "请输入模块名称(go.mod中的module, 默认为文件夹名称):",
  18. }
  19. err := survey.AskOne(prompt, &mod)
  20. if err != nil {
  21. return err
  22. }
  23. ...
  24. }
  25. {
  26. // 获取hade的版本
  27. client := github.NewClient(nil)
  28. prompt := &survey.Input{
  29. Message: "请输入版本名称(参考 https://github.com/gohade/hade/releases,默认为最新版本):",
  30. }
  31. err := survey.AskOne(prompt, &version)
  32. if err != nil {
  33. return err
  34. }
  35. ...
  36. }

首先我将最终解析出来的最终变量在最开始做定义,然后使用三个大括号,分别将 name, mod, version 三个变量的解析逻辑封装在里面。而在每个大括号里面,err变量的作用域就完全局限在括号中了,每次都可以直接使用 := 来创建一个新的 err并处理它,不需要额外思考这个err 变量是否前面已经创建过了。
如果你自己观察,大括号在代码语义上还有一个好处,就是归类和展示。归类的意思是,这个大括号里面的变量和逻辑是一个完整的部分,他们内部创建的变量不会泄漏到外部。这个等于等于告诉后续的阅读者,你在阅读的时候,如果对这个逻辑不感兴趣,不阅读里面的内容,而如果你感兴趣的话,可以进入里面进行阅读。基本上所有IDE都支持对大括号封装的内容进行压缩,我使用Goland,压缩后,我的命令行的主体逻辑就更清晰了。
Golang中常用的代码优化点 - 图9
image-20211220095540148
所以使用大括号,结合IDE,你的代码的可读性能得到很大的提升。

总结

文章中总结了四个golang中常用的写法

  • 使用pkg/error而不是官方error库
  • 在初始化slice的时候尽量补全cap
  • 初始化一个类的时候,如果类的构造参数较多,尽量使用Option写法
  • 巧用大括号控制变量作用域

这几种写法和注意事项是在工作过程和阅读开源项目中的一些总结和经验,每个经验都是对应为了解决不同的问题。
虽然说golang已经对代码做了不少的规范和优化,但是好的代码和不那么好的代码是有一些差距的,这些写法优化点就是其中一部分。本文列出的只是四个点,当然还有很多类似的golang写法优化点,相信大家在工作生活中也能遇到不少,只要大家平时能多思考多总结多动手,也能积攒出属于自己的一本小小的优化手册的。