Go 语言高质量编程｜青训营Go 高质量编程简介什么是高质量代码？编写的代码能够达到正确可靠、简介清晰的目

Go 高质量编程

简介

什么是高质量代码？

编写的代码能够达到正确可靠、简介清晰的目标称之为高质量代码

各种边界条件是否考虑完整
异常情况处理，稳定性保护
易读易维护，注释要详细

编程原则

实际应用场景千变万化，各种语言的特性和语法各不相同，但是高质量代码的原则是相通的

简单性

消除“多余的复杂性”，以简洁清晰的逻辑编写代码
无法理解的代码没办法改进

可读性

代码是写给人看的，保证自己和别人能够看懂自己的代码
编写可维护代码的第一步是确保代码可读性

生产力

注意团队工作效率
不要搞个人英雄主义

编码规范

编写高质量的 Go 代码的一些建议和规范

代码格式

推荐使用 gofmt 自动格式化代码

gofmt 是 Golang 官方提供的工具，能够自动格式化 Go 语言为官方统一风格

goimports 也是 Go 语言官方提供的工具，实际等于 gofmt 加上依赖包管理，可以自动增删依赖的包引用、将依赖包按字母排序并分类

GoLand 配置 gofmt、goimport

代码注释

代码中注释的主要作业有以下几点：

解释代码的作用
解释代码如何做
解释代码实现原因
解释代码什么时候会出错
好的代码有很多注释，坏的代码需要很多注释

公共符号始终要注释

包声明中的每个公共符号：变量、常量、函数以及结构体都要加注释
既不明显也不简短的公共功能必须予以注释
无论长度或复杂度如何，对库中的任何函数都必须注释
有一个例外，不要注释实现接口的方法

小结

代码是最好的注释
注释应该提供代码未表达出的上下文信息

命名规范

好的命名就像一个好笑话，如果你必须解释它，那就不好笑了

variable 简洁胜于冗长

// Bad
for index := 0; index < len(s); index++ {
    // do something    
}

// Good 
for i := 0; i < len(s); i++ {
    // do something
}

缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写

-  例如使用 ServeHTTP 而不是 ServeHttp
-   使用 XMLHTTPRequest 或者 xmlHTTPRequest

变量距离其被使用的地方越远，则越需要携带更多的上下文信息

-   全局变量在其名字中需要更多的上下文信息，使得在不同的地方可以轻易辨认含义 

 // Good
func (c *Client) send(req *Request, deadline time.Time)

// Bad
func (c *Client) send(req *Request, t time.Time)

// deadline 比 t 语义化更强

function

函数名不携带包名的上下文信息，因为包名和函数名总是成对出现
函数名尽量简短
当名为 foo 的包某个函数返回类型为 Foo 时，可以省略类型信息而不导致歧义
当名为 foo 的包某个函数返回类型为 T 时，可以在函数名中加入类型信息

package

只由小写字母组成，不包含大写字母和下划线字符等
简短并包含一定的上下文信息。例如 schema、task等
不要与标准库同名。例如不要使用 sync 或者 string 等
不使用常用变量名作为包名。
使用单数而不是复数。例如使用 encoding 而不是 encodings
谨慎使用缩写。例如使用 fmt 在不破坏理解的基础上比 fomat 更简短

小结

核心目标是降低代码阅读成本
重点考虑代码上下文信息，设计简洁清晰的名称

控制流程

避免嵌套，保证正常流程清晰

// Bad
if foo {
    return x
} else {
    return nil
}

// Good
if foo {
    return x
}
return nil

尽量保持正常代码路径为最小缩进

// Bad
func OneFunc() {
    err := doSomething()
    if err == nil {
        err := doAnotherThing()
        if err == nil {
            return nil
        }
        return err
    }
    return err
}

// Good
func OneFunc() error {
    if err := doSomething(); err != nil {
        return err
    }
    if err := doAnotherThing(); err != nil {
        return err
    }
    return nil
}

小结

线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
正常流程代码沿着屏幕向下移动
提升代码可维护性和可读性
故障问题大多出现在复杂的条件语句和循环语句中

错误和异常处理

简单错误

仅出现一次的错误，在其他地方不需要捕获该错误
优先使用 errors.New 来创建匿名变量来直接表示简单错误
如果有格式化需求，使用 fmt.Errorf

func defaultCheckRedirect(req * Request, via []*Request) error { if len(via) >= 10 { return errors.New("stopped after 10 redirects") } return nil }

错误的 Wrap 和 Unwrap

错误的 wrap 实际上是提供了一个 error 嵌套另一个 error 的能力，从而生成一个 error 的跟踪链

在 fmt.Errorf 中使用：%w 关键字来将一个错误关联至错误链中

list, _, err := c.GetBytes(cache.Subkey{a.actionID,"srcfiles"})
if err != nil {
    return fmt.Errorf("reading srcfiles list:%w",err)
}

错误判断

判断一个错误是否为特定错误，使用 error.is 不同于使用 ==，使用该方法可以判定错误链上的所有错误是否含有特定的错误

data, err = lockedfile.Read(targ)
if errors.Is(err, fs.ErrNotExist) {
    return []byte{}, nil
}
return data,err

在错误链上获取特定种类的错误，使用 error.As

if, _, err := os.Open("non-existing"); err != nil {
    var pathError *fs.PathError
    if errors.As(err,&pathError) {
        fmt.Println("Failed at path:", pathError)
    }
}

panic

不建议在业务代码中使用 panic
调用函数不包含 recover 会造成程序崩溃
若问题可以被屏蔽或解决，建议使用 error 替代 panic
当程序启动阶段发生不可逆转错误时，可以在 init 或 main 函数中使用 panic

recover

recover 只能在被 defer 的函数中使用
嵌套无法生效
只在当前 goroutine 生效
defer 的语句是后进先出
如果需要更多的上下文信息，可以在 recover 后在 log 中记录当前的调用栈

小结

error 尽可能提供简明的上下文信息链，方便定位问题
panic 用于真正异常的情况
recover 生效范围，在当前 goroutine 的被 defer 的函数中生效

Go 语言高质量编程 ｜ 青训营