タオルケット体操

サツバツいんたーねっとでゲームとかガジェットのレビューとかをします

GoogleのTypeScript Style Guideについてのお気持ちスタンダード

Sponsored link

なんか話題になってて、なんかおみこしwasshoiする流れになってたのでお気持ちを書き残したくなった。

先に結論

  • こういうのを作って公開するのは誉れある組織

ですが

  • 内容的にはfor TypeScriptというよりはfor ES nextといった感じで、特に型周りに関する言及が少なめ

  • eslintのルールが用意されていないので使いたいなら人力運用になる

ゆえにGoogle社員以外がわざわざプロジェクトに導入するのはどうなんでしょうか。手間に見合う価値があるんでしょうか。
だからこれをデファクトにしよう!みんなこれ使えよな!みたいな勇み足はちょっと……

これが言いたかっただけです。

スタイルガイド自体に関するオレのKimochi

伝えたい…

率直にいってしまえばスタイルガイドは存在しているという事実そのもの、そしてそれが常にチェックされている機構に価値があって、中身はどうでもいいと極論してもいい。
つまり最低限の作法としてプロジェクト内でコードやコメントの書き方が統一されている事自体に価値があるので、例えばどこにどう改行を入れようとかに優劣はなく、それがメンバーの納得に基づいて決定されていればどうでもいいのである。

もちろんプログラミング言語にも色々あって、静的解析がしやすかったりやりにくかったり、そういう文化が発展してたりおざなりだったり……。
ECMAScriptは解析がしやすく、その文化も発展しているので、現代においてはプロジェクトごとにeslintのruleさえ用意しておけばスタイルガイドは不要だというのがオレの意見。逆にRubyみたいな言語は人数が多いプロジェクトであればスタイルガイドがあったほうがいいとはおもう(RuboCop、てめーはダメだ)。

ただし! 上は普通の規模の組織についてのお話。

Googleのように無数の社員とプロジェクトを抱えている組織においてはこういったスタイルガイドの持つ価値は変わってくるので、そのへんは色々と自分で考えていい感じにやっていくといいとおもいます。

スタイルガイドの持つベストプラクティス集という側面

しかしながらスタイルガイドについては「ベストプラクティス集」といった側面があったりする。
例えばロジックやシンタックス、そしてlint rule的にもvalidな2つの書き方の間でどちらを採用すべきか……といった問いに答えてくれるようなものだ。

GoogleのPythonやC++のスタイルガイドはかなりベストプラクティス集に近いような趣きがあった(うろ覚え)はずで、当時はかなりお世話になったおぼえがある。

(どういう経緯、どういうステータス*1で公開してあるのかわからない他社のスタイルガイドにケチつける形になるのは心苦しいんだけど)今回のガイドはTypeScriptのベストプラクティス集としてみるとちょっと弱い。
軽く例を上げると

  • 現実的なユースケースにおいてEnumはUnionで代替可能、かつ安全性で勝るので避けたほうが良い。わざわざJavaScriptとの互換性を損なってまで使う機能ではない*2

  • TypeScriptではswitch caseにdefault節を書くべき ではない パターンが存在する。
    例えばUnionおよびTagged Union Typeを評価にした場合、TypeScriptのコンパイラは網羅性をチェックしてくれる。そのため後々Unionの定義を増減させたときに条件のミスマッチをコンパイルエラーとして教えてくれる。
    defaultがあるとこれが働かない。
    逆に言うとswitch caseで評価する変数は極力Union型に落とし込んでおくべき。

  • コードの例でClassを多用しているが、Type Guardの書き方について言及がない。
    Nominal Typesな型システムを採用している言語に慣れ親しんでいる人は結構地雷を踏む箇所だとおもう*3

しつこいようだけど僕は自分が関わっていないプロダクトがどんなルールを採用してコードを書いていようがしったこっちゃないので、Googleの社内ルールに文句をつける気は一切ない。
ここで言いたいのはあのガイドで提唱されているスタイルはTypeScriptとしてあまりベストとは言い難いものが含まれていたり、逆に重要*4な箇所の言及が抜けている、ということで、それをわざわざ外部の人間が採用したり、世界に広める意味ある……?ってこと……。
デファクトのルールをTypeScriptのファウンデーションが運用してくれたらいいな、とはおもいます。

ちなみにDecoratorsは"generally want to avoid"なんてもんじゃなくて端的に避けるべきで、Decoratorsが前提となっているだけでそのフレームワークを避ける積極的な理由になる。やめておけ。

まとめ

  • コードレビューがくそめんどくさくなるし無価値な議論の火種になるので、筆者はスタイルガイドという存在があまり好きじゃない

  • 最初に作ればあとは自動で運用できるので、筆者はeslintが好き

  • よほどクオリティが酷くない限りは、スタイルガイドは存在自体に価値がある。しかし外部の人間がそれを輸入するほどの価値はないことが多い

  • 他人が決めているルールにケチをつけるつもりはないですが、我々外部の人間がわざわざ採用する必要があるかというとそういう感じにはみえないのでこれをデファクトスタンダードにすべきだ!みたいな意見にはどちらかというと大反対。

    ていうか @typescript-eslint/recommended 以上のルールをいちいち作ろうとするのって普通の人数のプロジェクトだとコスパ悪すぎるからやめたほうがいい

  • スタイルガイドはそんなに好きじゃないけどベストプラクティス集は好きだし、存在していればクオリティ次第でデファクト化する価値はあるかもしれない

  • 筆者はclassがきらいだけどたまに使わざるを得ないらしい

  • あっ、そういえばDecoratorsは積極的に避けるべき

以上です。

ちなみにtype or interfaceの議論ですが、筆者はぶっちゃけどっちでもいいです。
どっちにしろ微妙に機能が違うんで完全に統一はできないし。じゃあ共存しよ?

*1:プロトタイプ的なたたき台としてとりあえず公開した!みたいなものだったりするだろうし

*2:と僕は考えている

*3:ちなみに僕はそもそも本当に必要な局面を除いてJS/TSでclass構文は使うべきじゃないと考えているが、それはまた別のお話

*4:個人の意見です