GO 代码规范

工具

Linter

golangci-lint工具

如何安装：golangci-lint 使用文档 go linter如何与GoLand联动

1. 安装go linter plugin

1. 将go linter的执行文件的path指定为上面下载的golangci-lint工具

1. 这样，就可以在IDE里看到lint问题

注意：lint检测应该建立在项目build成功的基础上 不然，在codebase CI的检测结果中，可能会出现一些意料之外的错误信息。一般情况下，因lint问题导致检测 GolngCI-lint检测失败的Exit Code为1。

常见问题

Lint

package命名

全部使用小写字母。若必须是多个单词组合，则直接拼接在一起，例如videopredict，而非video_predict。

全大写变量名

使用ID，而非Id；使用RPC，而非Rpc。

常量注释的有效性

常量的注释，记得带上变量名的前缀，这会提醒你只添加该常量相关的注释，或者，它会提醒你不要添加“非必要”的注释。如果要做某些常量的注释，那么在定义常量集合的时候，请这样写：

// Bean类型
const (
   //
   BeanTypeHandler   = "h"
   BeanTypeChanger   = "c"
   BeanTypeRpcClient = "r"
   BeanTypeUtil      = "u"
)

常量的命名

camel格式。不要全部大写

缩进格式化 File is not gofmt-ed with -s (gofmt) 执行下面的命令做格式化：gofmt -s -w consts/consts.go

gosimple S1034(related information): could eliminate this type assertion 对比一下这两段代码

S1005: unnecessary assignment to the blank identifier 参见GoDoc

If the last iteration variable is the blank identifier, the range clause is equivalent to the same clause without that identifier.

Bad practice

for _ = range slc {
}


x, _ = someMap[key]

_ = -ch

Recommended

for range slc {
}


x = someMap[key]

-ch

S1023: redundant return statement 方法最后的无效return，请移除。

S1033: unnecessary guard around call to delete Bad practice

func fn(m map[int]int) {
    
    if _, ok := m[0];
 ok {

        delete(m, 0)
    }

}

Recommended

func fn(m map[int]int) {

    delete(m, 0)
}
    

S1009: should omit nil check; len() for nil slices is defined as zero Bad practice

if x != nil &
    &
 len(x) != 0 {

    x[0] = 1
}

Recommended

if len(x) != 0 {

    x[0] = 1
}

S1008: should use 'return ok == nil' instead of 'if ok == nil { return true } ; return false'

S1011: should replace loop with textsList = append(textsList, ocrResult...)

方法的注释

方法的注释，请紧挨着方法体 对比一下这两种写法，在方法提示上的区别

import顺序

File is not goimports-ed (goimports) 调整import顺序，按照“块”import，不同“块”之间用空行隔开。官方库放在最前面，其他的放在后面。按照前缀做排序。特殊情况下（特殊的package名），可能需要取别名。

对比一下下面两张截图

nolint大法

如果实在没办法解决的话，比如，有已经在使用的关键词，但是关键词拼写错误了，必须要豁免lint检测，那么，可以使用//nolint注释来豁免。

对于不同的代码实体（例如，单行代码、方法、package等）nolint注释的位置也不相同。可以参照此链接。

Unit Test

Attempt to use unknown class

在mac os上，执行go test带上-race参数时，会出现此错误。看起来，是因为mac OS上执行的原因，可以看看这里，自己再判断下。真正部署到CI实例上，执行codebase CI流程时，并不会出现这样的问题。

问题

单元测试的能力边界应该控制在哪里？比如，一个执行调度的方法，对于超时导致的异常，需要使用单元测试的能力做测试覆盖吗？还是说，应该走用例测试？

参考

• https://staticcheck.io/docs/checks

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！