How to customize linter (static checking tool) in Go language

Preface

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;

How is static checking implemented in Go language?

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;

Develop linter rules

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 ASTAs 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  .  .  .  }

Method 1: Standard library implements custom linter

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

方式二：go/analysis

看过上面代码的朋友肯定有点抓狂了，有很多实体存在，要开发一个linter，我们需要搞懂好多实体，好在go/analysis进行了封装，go/analysis为linter 提供了统一的接口，它简化了与IDE,metalinters，代码Review等工具的集成。如，任何go/analysislinter都可以高效的被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

我们可以把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!