リーダブルコードを読んだ
気になった記述や考え方のメモ。
1章「理解しやすいコード」
- 読みやすさの基本定理…優れたコード=他人が理解するのに要する時間が最短のコード
- カッコいいコードを書こうとしてテクニックに走り、読みづらいコードにならないように。
2章「名前に情報を詰め込む」
- 正確かつ明確な名前・表現を探す。GetよりもDownloadやFetchが適切かもしれない。
- 変数名の長さとスコープを反比例させる。数行の間しか使われない変数に長い名前は必要ない。
- アンダースコア(_)やダッシュ(-)、大文字小文字を使って情報を表現する。
- CamelCaseとsnake_caseを混在させるのは微妙に感じる。大規模なコードでは有用なんだろうか。
3章「誤解されない名前を使う」
- 範囲を指定するときは境界値を含むのかを明らかにする。
- 名前は肯定形を使うとよい。(disable_ssl→use_ssl)
- 軽い処理であることが期待されやすい名前に注意する。(ex. get,size)
4章「美しさ」
- 改行や空白を揃えて、同じような処理は同じような見た目にする。
- 最後は個人の好みの問題…正しさよりも、一貫性
5章「コメントすべきことを知る」
- 優れたコード > 悪いコード+優れたコメント。コードのクオリティを上げるのが先。
- コードそのものの説明はしない。自分の考えやコードの根拠をコメントに残す。
6章「コメントは正確で簡潔に」
- あいまいな表現をしない。「優先度を変える」は「高くする or 低くする」として明確に。
- 動作のわかりにくいコードには実例を示す。
- 可能であれば、関数呼び出しの際に引数に名前を付ける。
7章「制御フローを読みやすくする」
- 条件式を書くときは、変化する値を左、安定した値を右に書く。
- 分岐(if)や繰り返し(for,while)では単純なもの、目立つものを先に片づける。
8章「巨大な式を分割する」
- 式が長くなったら、変数を作って概念レベルで意味を持つ単位に分割する。
- より簡単な条件で目的を達成する方法はないか考える。条件を逆にしたら簡単にならないか？
9章「変数と読みやすさ」
- 1度しか使われていなかったり、中間結果を保持している変数は削除する。
- 後で何度も使うだろうと思って変数にして、結局1回しか使わないパターンに注意する。
- 変数のスコープは短く、書き換える場所は少ないほうがよい。
- ES6の
letやconstはこの考え方を実現するのによさそう。
- ES6の
10章「無関係の下位問題を抽出する」
- 純粋な計算やユーティリティのコードを別の関数に分離することで、本来の問題に集中しやすくなる。
- 汚いインターフェースを使うために長いコードを書くくらいなら、その労力でラッパーを作ってインターフェースをきれいにする。
11章「1度に1つのことを」
- コード中で複数のタスクを行ったり来たりしない。タスクと値を洗い出して、1つずつ片付ける。
12章「コードに思いを込める」
- 実装したい処理について他人に説明するならどう話すかを考え、出てきたキーワードを元にコードを書く。
- その説明でおばあちゃんは理解できるか？
13章「短いコードを書く」
- 「コードを書かずに済ませる」ことも手段の一つ。コードが少なければ付随する仕事も少なくて済む。
- 要求にあったレベルの実装で終わらせる。新しい機能は必要になるまでつけない。
- 標準ライブラリやAPIの一覧に目を通しておき、「その機能、どこかにあったような…」と思えるとよい。
14章「テストと読みやすさ」
- あるユニットに対するテストは、「状態Aにおける入力xに対して、動作Bと結果yが得られる」という1行で説明できることが多い。
- テストに用いる値は可能な限り単純なものにする。1回のテストで複数の状況をチェックしようとしない。
15章「分／時間カウンタを設計・実装する」
- 処理の計算量・メモリ使用量を意識し、可能であればO(1)で実行できるように実装する。
- 「最大要素数が設定可能なキュー」のような汎用に使えるものなら、既存のライブラリを探してみる。
- クラスを分割することになっても、外部に公開されるのは1つだけならば問題ない。
まとめ
自分が書いたコードのことを忘れてもいいように、読みやすいコード、適切なコメントを書く。
雑感
どんなコードを書いたとしても、普通はコンパイル時に最適化が入る。 定数への置き換えやループの展開が行われて、コードとバイナリは必ずしも一致しない。 (組み込み系などの特殊な場合を除いて)限られたリソースをやりくりする時代でもないことを思えば、 他人にとってわかりやすいコードを書くことの優先順位が高くなることに不思議はない。
