Home > Article > Backend Development > How to customize linter (static checking tool) in Go language
Usually we use static code checking tools to ensure code quality in business projects. Through static code checking tools we can discover some things in advance For problems such as undefined variables, type mismatches, variable scope problems, out-of-bounds array subscripts, memory leaks, etc., the tool will classify the severity of the problem according to its own rules, give different labels and prompts, and static code inspection To help us find problems as early as possible, the commonly used static code inspection tools in the Go
language include golang-lint
and golint
. Some rules have been formulated in these tools. , although it can meet most scenarios, but sometimes we will encounter the need to make some customized rules for special scenarios, so in this article we will learn how to customize linter requirements;
As we all knowGo
language is a compiled language. Compiled language is inseparable from the stages of lexical analysis, syntax analysis, semantic analysis, optimization, and compilation and linking. Those who have learned the principles of compilation Friends should be familiar with the following picture:
The compiler translates high-level language into machine language. It first performs lexical analysis on the source code. Lexical analysis is the process of converting character sequences into Token sequences. Token is generally divided into these categories: keywords, identifiers, literals (including numbers, strings), special symbols (such as plus signs, equal signs), and generates Token
sequences Finally, syntax analysis is required. After further processing, a syntax tree with expressions as nodes is generated. This syntax tree is what we often call AST
. During the process of generating the syntax tree, some For formal errors, such as missing parentheses, after the syntax analysis is completed, semantic analysis is required. Here, all static semantics that can be checked during compilation are checked. The subsequent process is intermediate code generation, target code generation and optimization, and linking. This is not the case here. Detailed description, the main purpose here is to introduce the abstract syntax tree (AST), Our static code inspection tool is to do it by analyzing the abstract syntax tree (AST) according to customized rules; then the abstract syntax tree is long What does it look like? We can use the go/ast
, go/parser
, go/token
packages provided by the standard library to print out AST
, or we can Use visualization tools: http://goast.yuroyoro.net/ View AST
, we can see the example below for what AST
looks like;
Suppose we now want to develop such a code specification in our team. The first parameter type of all functions must be Context
, no We must give a warning if it conforms to this specification; OK, now that the rules have been set, let’s find a way to implement it; first let’s take a problematic example:
// example.go package main func add(a, b int) int { return a + b }
corresponds to AST
As follows:
*ast.FuncDecl { 8 . . . Name: *ast.Ident { 9 . . . . NamePos: 3:6 10 . . . . Name: "add" 11 . . . . Obj: *ast.Object { 12 . . . . . Kind: func 13 . . . . . Name: "add" // 函数名 14 . . . . . Decl: *(obj @ 7) 15 . . . . } 16 . . . } 17 . . . Type: *ast.FuncType { 18 . . . . Func: 3:1 19 . . . . Params: *ast.FieldList { 20 . . . . . Opening: 3:9 21 . . . . . List: []*ast.Field (len = 1) { 22 . . . . . . 0: *ast.Field { 23 . . . . . . . Names: []*ast.Ident (len = 2) { 24 . . . . . . . . 0: *ast.Ident { 25 . . . . . . . . . NamePos: 3:10 26 . . . . . . . . . Name: "a" 27 . . . . . . . . . Obj: *ast.Object { 28 . . . . . . . . . . Kind: var 29 . . . . . . . . . . Name: "a" 30 . . . . . . . . . . Decl: *(obj @ 22) 31 . . . . . . . . . } 32 . . . . . . . . } 33 . . . . . . . . 1: *ast.Ident { 34 . . . . . . . . . NamePos: 3:13 35 . . . . . . . . . Name: "b" 36 . . . . . . . . . Obj: *ast.Object { 37 . . . . . . . . . . Kind: var 38 . . . . . . . . . . Name: "b" 39 . . . . . . . . . . Decl: *(obj @ 22) 40 . . . . . . . . . } 41 . . . . . . . . } 42 . . . . . . . } 43 . . . . . . . Type: *ast.Ident { 44 . . . . . . . . NamePos: 3:15 45 . . . . . . . . Name: "int" // 参数名 46 . . . . . . . } 47 . . . . . . } 48 . . . . . } 49 . . . . . Closing: 3:18 50 . . . . } 51 . . . . Results: *ast.FieldList { 52 . . . . . Opening: - 53 . . . . . List: []*ast.Field (len = 1) { 54 . . . . . . 0: *ast.Field { 55 . . . . . . . Type: *ast.Ident { 56 . . . . . . . . NamePos: 3:20 57 . . . . . . . . Name: "int" 58 . . . . . . . } 59 . . . . . . } 60 . . . . . } 61 . . . . . Closing: - 62 . . . . } 63 . . . }
Through the above AST
structure we can find where the function parameter type is Structurally, because we can write the parsing code based on this structure as follows:
package main import ( "fmt" "go/ast" "go/parser" "go/token" "log" "os" ) func main() { v := visitor{fset: token.NewFileSet()} for _, filePath := range os.Args[1:] { if filePath == "--" { // to be able to run this like "go run main.go -- input.go" continue } f, err := parser.ParseFile(v.fset, filePath, nil, 0) if err != nil { log.Fatalf("Failed to parse file %s: %s", filePath, err) } ast.Walk(&v, f) } } type visitor struct { fset *token.FileSet } func (v *visitor) Visit(node ast.Node) ast.Visitor { funcDecl, ok := node.(*ast.FuncDecl) if !ok { return v } params := funcDecl.Type.Params.List // get params // list is equal of zero that don't need to checker. if len(params) == 0 { return v } firstParamType, ok := params[0].Type.(*ast.SelectorExpr) if ok && firstParamType.Sel.Name == "Context" { return v } fmt.Printf("%s: %s function first params should be Context\n", v.fset.Position(node.Pos()), funcDecl.Name.Name) return v }
Then execute the command as follows:
$ go run ./main.go -- ./example.go ./example.go:3:1: add function first params should be Context
We can see through the output that the function add()
The first parameter must be Context; this is a simple implementation, because the structure of AST
is a bit complicated, so I won’t introduce each structure in detail here. You can see Cao An article I wrote before: golang and ast
看过上面代码的朋友肯定有点抓狂了,有很多实体存在,要开发一个linter
,我们需要搞懂好多实体,好在go/analysis
进行了封装,go/analysis
为linter
提供了统一的接口,它简化了与IDE,metalinters,代码Review等工具的集成。如,任何go/analysis
linter都可以高效的被go vet
执行,下面我们通过代码方式来介绍go/analysis
的优势;
新建一个项目代码结构如下:
. ├── firstparamcontext │ └── firstparamcontext.go ├── go.mod ├── go.sum └── testfirstparamcontext ├── example.go └── main.go
添加检查模块代码,在firstparamcontext.go
添加如下代码:
package firstparamcontext import ( "go/ast" "golang.org/x/tools/go/analysis" ) var Analyzer = &analysis.Analyzer{ Name: "firstparamcontext", Doc: "Checks that functions first param type is Context", Run: run, } func run(pass *analysis.Pass) (interface{}, error) { inspect := func(node ast.Node) bool { funcDecl, ok := node.(*ast.FuncDecl) if !ok { return true } params := funcDecl.Type.Params.List // get params // list is equal of zero that don't need to checker. if len(params) == 0 { return true } firstParamType, ok := params[0].Type.(*ast.SelectorExpr) if ok && firstParamType.Sel.Name == "Context" { return true } pass.Reportf(node.Pos(), "''%s' function first params should be Context\n", funcDecl.Name.Name) return true } for _, f := range pass.Files { ast.Inspect(f, inspect) } return nil, nil }
然后添加分析器:
package main import ( "asong.cloud/Golang_Dream/code_demo/custom_linter/firstparamcontext" "golang.org/x/tools/go/analysis/singlechecker" ) func main() { singlechecker.Main(firstparamcontext.Analyzer) }
命令行执行如下:
$ go run ./main.go -- ./example.go /Users/go/src/asong.cloud/Golang_Dream/code_demo/custom_linter/testfirstparamcontext/example.go:3:1: ''add' function first params should be Context
如果我们想添加更多的规则,使用golang.org/x/tools/go/analysis/multichecker
追加即可。
我们可以把golang-cli
的代码下载到本地,然后在pkg/golinters
下添加firstparamcontext.go
,代码如下:
import ( "golang.org/x/tools/go/analysis" "github.com/golangci/golangci-lint/pkg/golinters/goanalysis" "github.com/fisrtparamcontext" ) func NewfirstparamcontextCheck() *goanalysis.Linter { return goanalysis.NewLinter( "firstparamcontext", "Checks that functions first param type is Context", []*analysis.Analyzer{firstparamcontext.Analyzer}, nil, ).WithLoadMode(goanalysis.LoadModeSyntax) }
然后重新make
一个golang-cli
可执行文件,加到我们的项目中就可以了;
golang-cli
仓库中pkg/golinters
目录下存放了很多静态检查代码,学会一个知识点的最快办法就是抄代码,先学会怎么使用的,慢慢再把它变成我们自己的;本文没有对AST
标准库做过多的介绍,因为这部分文字描述比较难以理解,最好的办法还是自己去看官方文档、加上实践才能更快的理解。
本文所有代码已经上传:https://github.com/asong2020/Golang_Dream/tree/master/code_demo/custom_linter
The above is the detailed content of How to customize linter (static checking tool) in Go language. For more information, please follow other related articles on the PHP Chinese website!