「良いコード」って何?
参考書籍
短く言うと「わかりやすいコードを書け」と言うのを永遠と書いている本。
「どう書いたらわかりやすいか」のテクニックがあらゆる方向から書かれている。
この本を読んで自分のコーディングに対する概念が覆されたので
その中でも印象に残ったものを備忘録として綴っておこうと思う。
「わかりやすいコード」は正義である
まず、そもそも何で「他の人でもわかりやすいコード」が正解なんだろうか。
なぜならコードは多くの場合メンテナンスが必要だから。
なるほど。確かに。
「他の人」というのは、自分のコードに身に覚えのない6ヶ月後の自分かもしれない。
この一文、沁みる。
「短いコード」が正義だとおもっていた自分は、「えぇ?短いコードの方が読む時間も減るし短い方がいいやん」とか思ってたが次のページでしっかり論破される。
でも、短ければいいってもんじゃない!
このような一行のコードは、以下のような二行のコードを理解するよりも時間がかかることが多い。
耳が痛すぎる。
一行に情報を詰め込むべし。無意味に名を決めるべからず。
そうだよな。
意味もなくとりあえずtmpとかつけちゃってたりするわ。
なるべくその命名を見て情報が頭に入ってくる様に。
明確な単語で。
その精神でいつも命名が呪文の様になっている自分もいるが。
ただ長すぎるのもいけなくて、スコープの小さい場合は短く簡潔が良いし臨機応変で。
誤解を回避せよ。二通りの意味を成す単語は使わぬが吉
例1でfilterが出てきた。
下手すると一週間に一回は名前に「filter」が入った可哀想な変数を量産してる気がする。
この文を書く前に一度読んでいるにも関わらず。
完全に忘れていた。
なぜ「filter」がいけないかと言うと「除外する」のか「選択する」のか明確でないからだ。
直すなら「選択する」は「select」、「除外する」は「exclude」にすると良いらしい。
今回全て列挙はしないが、この本には同じ様な具体例がいくつも挙げられており非常に参考になる。
美しくあれ
言わずもがな、永遠の課題。
どこを美しさの基準として説くかになってくるが、ここではビジュアル的なことが書かれていた。
コードブロックを揃える。
列を整列する。
並び順に気を配る。
空行を使って整える。
ここは人間見落としもあるとおもう。
今のプロジェクトではPrettierを活用しているのを教えてもらい「良いな」とおもった。
好みもあるよね。