---
title: golangci-lint の enable-all で コーディングルールを明確にする試み
tags: 
author: [takanakahiko](https://www.docswell.com/user/takanakahiko)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/G78NDLQVJD.jpg?width=480
description: golangci-lint の enable-all で コーディングルールを明確にする試み by takanakahiko
published: May 11, 24
canonical: https://www.docswell.com/s/takanakahiko/ZQ864X-2024-05-11-022041
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/G78NDLQVJD.jpg)

golangci-lint の enable-all で
コーディングルールを明確にする試み
なかひこくん(@takanakahiko)
@Asakusa.go #2


# Page. 2

![Page Image](https://bcdn.docswell.com/page/L7LPMLXRJR.jpg)

誰？
なかひこくん
@takanakahiko
新横浜(実は浅草の飛び地なんです！)に住んでいます


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4EM4YMLPJW.jpg)

type Runer interface {
Run()
}
さっそく
皆さんに質問
Human が Runer を実装して
いることを確認したいです。
皆さんならどっちの書き方にし
ますか？
type Human struct {
name string
}
func (h *Human) Run() {
...
}
// 上記の Human が Runer を実装していることを確認する
// 皆さんはどっちで書きますか？
var _ Runer = &amp;Human{}
// ①
var _ Runer = (*Human)(nil)
// ②


# Page. 4

![Page Image](https://bcdn.docswell.com/page/PERW9VKYJ9.jpg)

自分としては
- どっちでも問題はない(メリットやデメリットはあるが)と思う
- ただしどちらかに統一されていると必要はある(これが大事)
こういうのとても多いですよね。
補足: go.dev/doc ではポインタなら②が例示はされている
https://go.dev/doc/faq#guarantee_satisﬁes_interface


# Page. 5

![Page Image](https://bcdn.docswell.com/page/P7XPQZL4JX.jpg)

チームで書くときは？
チームではこういうのを決めて統一する必要がある
- 結局どちらに統一するのか？
-
これを決めるための何かしらの方針が欲しい
- なぜそちらの書き方で書くのか？
-
この理由を明確にしておきたい（とりあえず？明確に必然性があるから？）
- どう徹底(統一)する？
-
レビュワーが指摘する？でもそれって仕組み化したいよね
なんだかんだこういうのが大変なんですよね


# Page. 6

![Page Image](https://bcdn.docswell.com/page/37KD98LPED.jpg)

こういう時に役立つのが golangci-lint
- go向けのlinter詰め合わせセット
- サードパーティで開発されたやつを取り込んでいる形
- 利用者側は .golangci.yml で利用する linter を選択する
- 君だけの最強の .golangci.yml で勝利を勝ち取れ！


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LJ3RW234E5.jpg)

こんな感じで叱ってくれる。
色々なlinterから叱られてるのがわかると思う。


# Page. 8

![Page Image](https://bcdn.docswell.com/page/8JDYKZ45JG.jpg)

type Runer interface {
Run()
}
(再掲)
皆さんに質問
Human が Runer を実装して
いることを確認したいです。
皆さんならどっちの書き方にし
ますか？
type Human struct {
name string
}
func (h *Human) Run() {
...
}
// 上記の Human が Runer を実装していることを確認する
// 皆さんはどっちで書きますか？
var _ Runer = &amp;Human{}
// ①
var _ Runer = (*Human)(nil)
// ②


# Page. 9

![Page Image](https://bcdn.docswell.com/page/VEP6KDMD78.jpg)

# .golangci.yml
linters:
# enable-all で全てのlinterを有効化
enable-all: true
そこで
golangci-lint
enable-all を使ってみる。
すると何やら怒られる。


# Page. 10

![Page Image](https://bcdn.docswell.com/page/27V3V19GJQ.jpg)

こうやって対応を決めることができる
main.Human is missing field name (exhaustruct)
→ なるほど！① var _ Runer = &amp;Human{} だとstruct ﬁeldの設定漏れを許
容するようなソースコードになるから指摘されるんだね
→ struct ﬁeldの設定漏れは検知できる仕組みが欲しいし、それに変な
例外は作りたくなので② var _ Runer = (*Human)(nil) に統一しよう


# Page. 11

![Page Image](https://bcdn.docswell.com/page/5JG3L24DEL.jpg)

なぜ enable-all ？
- やらないことを決める方が負荷が少ない
-
やらないことの理由を挙げる方が明確にしやすい
- linterを逐次設定する方針だと「採用しない理由」がわかりづらい
-
disable-all かつ enable で逐次指定する形
-
「イケているlinterが採用されていない！」→「考慮漏れ？」「後回しになっているだ
け？」「理由があって対応していない？」と分かりづらい


# Page. 12

![Page Image](https://bcdn.docswell.com/page/47Q5YPGXEP.jpg)

この運用をするときの .golangci-lint.yml の例
# https://github.com/takanakahiko/discord-tts/blob/2195764ba46d1d6b251cea4f29b0cd9e6839d824/.golangci.yml
linters:
enable-all: true
disable:
- wsl # 余計な改行をなるべく含まないようにすることで得られる見通しの良さを重視するため
- nlreturn # 上記と同様
- gosmopolitan # 現在はi18n/l10nを検討していないため
- depguard # 規模的に依存関係の流れを厳格に管理する必要性はないため
- forbidigo # いまのところ特に禁止したい表現はないため
- gomnd # The linter &#039;gomnd&#039; is deprecated
(大袈裟だが)
- execinquery # The linter &#039;execinquery&#039; is deprecated
理由をつけて disableをする
# 続く


# Page. 13

![Page Image](https://bcdn.docswell.com/page/KE49WY52J1.jpg)

この運用をするときの .golangci-lint.yml の例(2)
# 続き
linters-settings:
varnamelen:
ignore-decls:
- v *discordgo.VoiceStateUpdate # パッケージの使用例がその命名であるため
- m *discordgo.MessageCreate # パッケージの使用例がその命名であるため
revive:
rules:
- name: unexported-return
disabled: true # ireturnへの対応を優先するため
# 続く
linterの個別設定の
カスタマイズにも理由があると嬉しい


# Page. 14

![Page Image](https://bcdn.docswell.com/page/L71KY6WKEG.jpg)

この運用をするときの .golangci-lint.yml の例(3)
# 続き
linters-settings:
funlen:
lines: 100 # デフォルトの60だと余計な関数の分割が発生するため
statements: 60 # デフォルトの40だと余計な関数の分割が発生するため
gomoddirectives:
replace-allow-list:
- github.com/jonas747/dca # 該当パッケージが壊れているので独自にパッチを当てたものを利用したいため
cyclop:
max-complexity: 24 # デフォルトの10だと余計な関数の分割が発生するため
現状このリポジトリの最大値は 23なので24を設定。(この場合は「 23になるのは仕方がないよね」という共通認識を作れているはず )
こう設定することで、 complexityの最大値を更新するような次の変更があったらそのタイミングで議論の機会が生まれる。


# Page. 15

![Page Image](https://bcdn.docswell.com/page/G7WDGW6PE2.jpg)

注意点
- .golangci.yml の編集のハードルは極力下げるように努力すべき
-
必要以上にコーディングに制約を作ることが目的ではない
-
「いまこうなっている理由」を明確にしているだけ
-
「いまこうなっている理由」より優先すべきものがあったらガンガン変更する
-
「今考えたものが最高で絶対的なルール」なんてあり得ない → 後から入る人がその人
たちにとって心地よいルールにしてくれるという信頼をチームで醸成する
- disabeの理由として「あとで対応する」もガンガン許容する
-
「あとで対応する」ことが分かっているなら目的は達成できている
-
「なぜ対応されていないのか分からない」が一番避けるべき状態


# Page. 16

![Page Image](https://bcdn.docswell.com/page/4JZGL5Y673.jpg)

デメリット(と感じられそうなもの)
- golangci-lint のアップデート時にlinterが増えるのでメンテが大変
-
だが、その時に方針をチームメンバーで話し合えるのは良いことだと思う
-
言語のバージョンをあげてから暫くして上げるのがおすすめ(linterが対応する期間
を待つ)
- 明らかに不要なlinterにも理由をつけてdisableする必要がある
-
でも「明らかに」って自分の感想でしかないので、やっぱり明文化は必要だと自分は
思います
-
言語化することでジュニアに「当たり前」の感覚を共有するのも大事


# Page. 17

![Page Image](https://bcdn.docswell.com/page/YE6YW9DLJV.jpg)

まとめ
- golangci-lint で enable-all をすると表記のブレが減らせる
- 取り上げていないlinterを理由付きで無効化することができる
- 「対応していない理由」が明確になる！
- (アップデート時の .golanci.yml のメンテナンスが少し大変)
- みんなどうやってるかハッシュタグとかで教えて欲しい〜


