適切な抽象度の道具を使って意図を明示する
コードを読む際には、意図を読み取っていかないといけない
逆に、コードを書く際には、意図を伝えていかないといけない
複数の書き方ができる場合に、闇雲に抽象度の高い道具を使っては意図が曖昧になる
JSの例だと
foreach使えば大抵のloopは書けるが、mapで済む時はmapを使いましょう
letを使えばどの種類の変数も定義できるが、定数なのであればconstを使いましょう
コード上にforeachが現れていると、
mapやfilterでできること以上のことをやっているんだな、と普通は読むmrsekut.icon
変数定義にletが使われていると、
どこかで再代入があるんだな、と普通は読むmrsekut.icon
選択肢が複数ある中で、わざわざ能力の高いものを使っているということは、それ相応の理由があるはず、と普通は読むmrsekut.icon
letを使っていた場所を修正した結果、定数で済むようになったのであればconstに書き直すべき
他の例
SQLで重複を弾く際の、DISTINCTとGROUP BY
TypeScriptの型の、'hoge'|'piyo'とstring
HTTP Request MethodのPOSTとPUT
etc.
常に制限強めに書くのが良いわけでもない
例えばHaskellにおけるパラメトリック多相した関数の定義時など
f :: Int -> Int -> Intではなく、
制限を緩めて、というかより汎用的に使えるようにするために、f :: a -> a -> aのように書くことが好まれる
常にそうしろと言っているわけではないmrsekut.icon
hsの場合、型が強いため意図が伝わりやすく、この制限の緩めによって事故が起きづらい
寧ろ嬉しいことが増える
というか「関数型指向」だから、これがかなりキレイに当てはまる
とはいえ、TSで関数定義するときに常にgenericにしろ、というノリはあまりない
し、やったとしてたぶんそこまで汎用的にならない
アドホック多相とパラメトリック多相とか、OOP的と関数型的とかの差の気もするがあまりちゃんと見えていないmrsekut.icon
結局は意図をはっきり伝わる書き方をしろ、という話だが
これも意図の話で、実装者がどこまでカバーする気があるのかの明示ってことじゃない?mrsekut.icon