nazolabo

フリーランスのWebエンジニアが近況や思ったことを発信しています。

エディタが便利になりすぎた話(続・git の pre-commit hook はなるべく使わないほうがいいのでは)

nazo.hatenablog.com

書いた時点から特に意見は変わってないので Zenn ではなくこちらで書きますが、なぜかこの記事だけ反響が多いようです。

概ね肯定的な意見が多いようですが、反響が多いといろんな人が現れますね。そもそもタイトルから「なるべく使わないほうがいいのでは」なのですが…。

現代の話

前の記事を書いてたあたりからエディタ+ LSP が進化しすぎて、各言語のまともな最新環境なら保存した時点で linter が走ってオートフォーマットされる(できないのは即時にエラーが出る)のが当たり前になったので、linter やコードフォーマッタ系に関してはそもそも pre-commit hook も手動実行も必要なくなりました。VSCode + Error Lens で書きましょう。

これを書いていた当時は LSP が動かないコードを書いていたので、linter の指定を丸暗記して書いていたのですが、もうそんなことをする必要もなくなりました。もうタブ派だの2スペース派だの4スペース派だの(そんな話もうしなくない?)で争うこともありません。特に GitHub Copilot の登場により、linter で自動修正できないコードの大半もそれっぽく修正してくれるようになりました。コードの書き方に脳のリソースを割くことは大幅に減ったので、コードの内容に集中しましょう。

また、これらのエディタの進化により、より「デフォルトでルールを厳しくする」ことにデメリットが少なくなりました。むしろ自動修正がバリバリ効くほうがメリットが多いし特にデメリットもないです。もちろん不要なルールもあるので、話し合って削ったり足したりしましょう。最近の linter は書き方からもう一歩踏み込んで、速度的に難のあるコードやセキュリティ的に難のあるコードを指摘してくれたり、各々のローカルルールを簡単に作ることもできます。

「エディタがなるべく自動でどうにかしてくれる」状態にするのが現代的な開発だと思います。GitHub Copilot でコメントを先に書いてコードを生成させる、みたいなのも含まれます。人間がどうにかするのはもうやめましょう。「ルールを守りましょう」ではなく「何も考えなくてもルール通りになる」状態を目指しましょう。

LSP があまり良くない言語やバージョンで書いている方々は、大変だとは思いますが今まで通りがんばってください。

テストはちゃんと試す必要がありますが、そもそも通らないテストをコミットするほうが悪いので、ちゃんとローカルで試しましょう。テストを pre-commit hook でやるのはいくらなんでも時間がかかりすぎるので元々やらないと思います。

それはそれとして CI は最終防衛ライン

これは変わっていないのでちゃんと CI で最終確認しましょう。あくまで「最終確認」です。リポジトリに push する時は CI が一発で通るだろう、という前提で push しましょう。