1月17日Day3 Go语言编码规范｜青训营笔记

邵晨sc
74 阅读5分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 3 天

Go 语言编码规范

简介

良好的编码规范要求我们：

  • 正确性：是否考虑各种边界条件，错误的调用是否能够处理
  • 可靠性：异常情况或者错误的处理策略是否明确，依赖的服务出现异常是否能够处理
  • 简洁：逻辑是否简单，后续调整功能或新增功能是否能够快速支持
编程原则：各种语言的语法和特性各不相同，但是高质量编程遵循的原则是相通的。
简单性
  • 消除多余的复杂性，以简单清晰的逻辑编写代码
  • 不理解的代码无法修复改进
可读性
  • 代码是写给人看的，而不是机器
  • 编写可维护代码的第一步是确保代码可读
生产力
  • 团队整体工作效率非常重要

代码格式

  • 首先是推荐使用 gofmt 自动格式化代码，保证所有的 Go 代码与官方推荐格式保持一致，而且可以很方便的进行配置，像 Goland 内置了相关功能，直接开启即可在保存文件的时候自动格式化。

截屏2023-01-18 20.18.49.png

  • 另外可以考虑 goimports ,会对依赖包进行管理，自动增删依赖的包引用，按字母序排序分类，具体可以根据团队实际情况配置使用

注释

  • 注释应该解释代码作用
    • 适合注释公共符号
// Returns true if the table cannot hold any more entries
func IsTableFull() bool
  • 注释应该解释代码如何做的
    • 适合注释实现过程
// Add the Referer header from the most recent
// request URL to the new one, if it's not https->http:
if ref := refererForURL(reqs[len(reqs)-1].URL, req.URL); ref != "" {
    req.Header.Set("Referer", ref)
}
  • 注释应该解释代码实现的原因
    • 适合解释代码的外部因素
    • 提供额外上下文
switch resp.StatusCode {
// ···
case 307, 308:
    redirectMethod = reqMethod
    shouldRedirect = true
    includeBody = true
    if ireq.GetBody == nil && ireq.outgoingLength()!= 0 {
        // We had a request body, and 307/308 require
        // re-sending it, but GetBody is not defined. So just
        // return this response to the user instead of an
        // error, like we did in Go 1.7 and earlier.
        shouldRedirect = false
    }
}
  • 注释应该解释一下代码什么情况会出错
    • 适合解释代码的限制条件
// parseTimeZone parses a time zone string and returns its length. Time zones
// are human-generated and unpredictable. We can't do precise error checking
// On the other hand, for a correct parse there must be a time zone at the
// beginning of the string, so it's almost always true that there's one
// there. We look at the beginning of the string for a run of upper-case letters.
// If there are more than 5, it's an error.
// If there are 4 or 5 and the last is a T, it's a time zone.
// If there are 3, it's a time zone.
// Otherwise, other than special cases, it's not a time zone.
// GMT is special because it can have an hour offset.
func parseTimeZone(value string) (length int, ok bool)
  • 公共符号始终要注释
    • 包中声明的每个公共的符号：变量、常量、函数以及结构都需要添加注释
    • 任何既不明显也不简短的公共功能必须予以注释
    • 无论长度或复杂程度如何，对库中的任何函数都必须进行注释
    • 有一个例外，不需要注释实现接口的方法。

具体不要像下面这样做:

// Read implements the o.Reader interface
func (r *FileReader) Read(buf []byte) (int, error)
小结：代码是最好的注释，注释应该提供代码未表达出的上下文信息。

命名规范

variable
  • 简洁胜于冗长
  • 缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写
    • 例如使用 ServeHTTP 而不是 ServeHttp
    • 使用 XMLHTTPRequest 或者 xmlHTTPRequest
  • 变量距离其被使用的地方越远，则需要携带越多的上下文信息
    • 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义
  1. 例如 i 和 index 的作用域范围仅限 for 循环内部时, index 的额外冗长几乎没有增加对于程序的理解.
// Bad
for index := 0; index < len(s); index++ {
    // do something
}

// Good
for i : = 0; i < len(s); it+ {
    // do something
}
  1. 例如将 deadline 替换成 t 降低了变量名的信息量, t 常代指任意时间, deadline 指截止时间, 有特定的含义.
// Good
func (c *Client) send(req *Request, deadline time.Time)

// Bad
func (c *Client) send(reg *Request, t time.Time)
function
  • 函数名不携带包名的上下文信息，因为包名和西数名总是成对出现的
  • 函数名尽量简短
  • 当名为 foo 的包某个函数返回类型 Foo 时，可以省略类型信息而不导致歧义
  • 当名为 foo 的包某个函数返回类型 T 时，可以在函数名中加入类型信息
  1. 例如 http 包中创建服务的函数应该不携带包名
// Good
func Serve(I net.Listener, handler Handler) error

// Bad
func ServeHTTP(I net.Listener, handler Handler) error
package
  • 只由小写字母组成。不包含大写字母和下划线等字符
  • 简短并包含一定的上下文信息。例如 schema、task 等
  • 不要与标准库同名。例如不要使用 sync 或者 strings

以下规则尽量满足，以标准库包名为例

  • 不使用常用变量名作为包名。例如使用 bufio 而不是buf
  • 使用单数而不是复数。例如使用 encoding 而不是encodings
  • 谨慎地使用缩写。例如使用 fmt 在不破坏上下文的情况下比 format 更加简短
小结：核心目标是降低阅读理解代码的成本，重点考虑上下文信息，设计简洁清晰的名称

控制流程

  • 避免嵌套，保持正常流程清晰
  1. 例如如果两个分支中都包含return语句，则可以去除冗余的else
// Bad
if foo {
    return x
} else {
    return nil
}

// Good
if foo {
    return x
}
return nil
  • 尽量保持正常代码路径为最小缩进
    • 优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套
  1. 例如最常见的正常流程的路径被嵌套在两个 if 条件内, 成功的退出条件是 return nil，必须仔细匹配大括号来发现, 函数最后一行返回一个错误，需要追溯到匹配的左括号，才能了解何时会触发错误 如果后续正常流程需要增加一步操作，调用新的函数，则又会增加一层嵌套
// Bad
func OneFunc() error {
    err := doSomething()
    if err == nil {
        err := doAnotherThing()
        if err == nil {
            return nil // normal case
        }
        return err
    }
    return err
}

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

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

错误和异常处理

简单错误
  • 简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
  • 优先使用 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, "srefiles"))
if err != nil {
    return fmt.Errorf( "reading srcfiles list: %w", err)
}
错误判定
  • 判定一个错误是否为特定错误，使用 errors.ls
  • 不同于使用 == ，使用该方法可以判定错误链上的所有错误是否含有特定的错误
data, err := lockedfile.Read(targ)
if errors. Is(err, fs.ErrNotExist) {
    // Treat non-existent as empty, to bootstrap the
    // the first time we connect to a given database
    return []byte{}, nil
}
return data, err
  • 在错误链上获取特定种类的错误，使用 errors.As
if _, err := os.Open("non-existing"); err != nil {
    var pathError *fs.PathError
    if errors.As(err, &pathError) {
        fmt.Println("Failed at path:", pathError.Path)
    } else {
        fmt.Println(err)
    }
}
panic
  • 不建议在业务代码中使用 panic
  • 调用函数不包含 recover 会造成程序崩溃
  • 若问题可以被屏蔽或解决，建议使用 error 代替 panic
  • 当程序启动阶段发生不可逆转的错误时，可以在 init 或 main 函数中使用 panic
recover
  • recover 只能在被 defer 的函数中使用
  • 嵌套无法生效
  • 只在当前 goroutine 生效
  • defer 的语句是后进先出
  • 如果需要更多的上下文信息，可以 recover 后在 log 中记录当前的调用栈
小结
  1. error 尽可能提供简明的上下文信息链，方便定位问题
  2. panic 用于真正异常的情况
  3. recover 生效范围，在当前 goroutine 的被 defer 的函数中生效
avatar
文章
阅读
粉丝