初めに

この記事はWanoグループ Advent Calendar 2020 の6日目の記事になります。

golangci-lintって？

Go言語には非常に多くのコード解析ツールがあります。例えば gofmt や goimports, govet などはgolangを書いている人なら知ってる人も多いと思います。
golangci-lintはGo言語のコード解析ツールを一つに集約したようなすごいやつです。

コードレビューをする時にまずこれを実行すると、機械的にまず直しておいたほうが良さそうな部分がわかって治安がよくなるかもしれないということですね。
そして解析結果はXMLだったりで出力することが出来るのでそこからさらにプログラムで使うのも簡単です。

インストールの方法などは上記リンクに記述してあるのでカットさせていただきます。

configファイルを晒してみる

golangci-lintではconfigファイルを用いて

どの解析ツールを使うか
解析ツールの条件(変数の出現回数など)

などを設定することが出来ます。

自分が実際に使っているものを晒してみたいと思います(結構適当に設定してますが)。


run :
  issues-exit-code: 0

issues:
  max-issues-per-linter: 1000
  max-same-issues: 1000

output :
  format : checkstyle

linters:
  disable-all: true
  enable:
    - deadcode
    - errcheck
    - gosimple
    - govet
    - ineffassign
    - staticcheck
    - structcheck
    - typecheck
    - unused
    - varcheck
    - bodyclose
    - depguard
    - dogsled
    - gochecknoglobals
    - gochecknoinits
    # - goconst
    - gocritic
    - gofmt
    - goimports
    # - golint
    - gosec
    - interfacer
    - misspell
    - nakedret
    - prealloc
    - scopelint
    # - stylecheck
    - unconvert
    - unparam
    # - whitespace
    # - wsl

linters-settings:
  errcheck:
    ignore: '[rR]ead|[w|W]rite|[c|C]lose|[c|C]ommit|[r|R]ollback|[p|P]rintln'

  goconst:
    min-len : 5

  golint:
    min-confidence : 1.0

使い方としては

まずgolangci-lint自体の設定を記述。
使うlinterを選ぶ。
各linterの設定を追加。

configファイルを呼んで解析する場合は

golangci-lint run -c .golang_review_config.yml <適当なpath>

とすれば良い感じに。なんでもかんでもぶち込むと「厳しすぎない？」となるので使うlinter類は各プロジェクトや開発者で選ぶと良いと思います。ちなみにymlファイルなのでコメントアウトも出来ます。

おすすめ

個人的に入れとくと良いやつを紹介してみます。
各linterの細かいconfigはカットです。

govet

これに関しては言うこともない気がします...が。
簡単に言うと「バグる可能性が高い部分を検知してくれる」やつです。なのでgovetでエラーが出る場合は「アウト」の認識だと良いと思います。例えばですが

type A struct {
	Num  int
	Text string
}

a := A{
    1,
    "aaa",
}

では「構造体を使う時に変数だけしか書いてない」ということで怒られます。

type A struct {
	Num  int
	Text string
}

a:=A{
    Num : 1,
    Text : "aaa",
}

こうしろということですね。

errcheck

個人的にgovetと並ぶと思っている強いやつです。エラーハンドリングし忘れたやつを教えてくれるので、これに引っかかる場合もアウトにして良いかもしれません(ただしデフォルトで Close() などでも引っかかる)。

func (db DB)insert(<hogehoge>)error

func main() {
	DB.insert(<hogehoge>) // エラー
	_ = DB.insert(<hogehoge>) // 明示するとlinterがスルーしてくれる
}

例えば「エラーを返す関数だけど確認してないよ！」というときに教えてくれます。もし確認する必要がなければ明示的に _ で受けるとlinterが確認しなくなります(こういうことは開発ルールとして明記したほうが良いのかも)。

他にも...

unconvert : 不要なキャストを知らせる
unparam : 不要な関数の引数を知らせる
unused : 使っていない変数を教えてくれる(自分の中でunparamと混じってるかも)

他にも不要な○○を教えてくれる、書き方が変または簡単に書ける(省略できる)、など色々なことを教えてくれます。

まとめ

色々なlinterを使って開発者ごとのブレを少なく出来るといいですね()。
書き方などはともかく、バグになる可能性がある解析ツールをONにしてコミットやpushするときに解析すると事前に確認が出来て良いと思います。