リーダブルコード読了後の備忘録
リーダブルコードを読み終わったので自分用におさらい
列挙次項に気をつけてコーディングしつつ、「あれ、どうやって実践するんだっけ？」ってなったら読み直す、ってのを習慣化したい
（注意）自分の解釈が混じってます
名前に情報を詰め込む
- 明確な単語を選ぶ
- tmpやretvalなどの汎用的な名前を避ける
- 具体的な名前を使って、物事を詳細に説明する
- 変数名に単位、状態などを追加する
- スコープの大きな変数に長い名前を
- 大文字やアンダースコアに意味を込める
誤解されない名前
- 曖昧な英語表現を使わない(ex: length, filter, limit)
- 限界値にはmin, max
- 包含的範囲にはfirst, last
- 包含/排他的範囲にはbegin, end
- ブール値にisなどを
- 否定形を避ける
- getやsizeは軽量アクセッサに限る
美しさ
- 複数のコードブロックで同じことをするならシルエットも同じに
- コードの列を整理
- 順番は規則正しく
- 空行を使って大きなブロックを論理的に「段落」に分ける
コメント内容
- コードからすぐ抽出できることは書かない
- 補助的なコメントは書かない（コードを補うコメント書くくらいならコード修正しろ！）
- なぜ他のやり方でないのかを書く
- コードの欠陥をTODO:やXXX:で表す
- 定数の値にまつわる背景を書く
- 読み手が疑問に思いそうなところを書いておく
- 平均的な読み手が驚く動作は文書化する
- ファイルやクラスには「全体像」のコメントを書く
- コードブロックにコメントを付けて概要をまとめる
コメントは正確で簡潔に
- 「それ」などの代名詞を避ける
- 関数の動作はできるだけ正確に説明
- コードの意図は詳細レベルでなく、高レベルで記述
- よくわからない引数にインラインコメントを使う
- 情報密度の高い言葉を使う
制御フローを読みやすく
- 比較では変化する値を左に、より安定した値を右に配置
- if/elseのブロックは、肯定形・単純・目立つものの順に処理する
- 三項演算子、do/whileループ、gotoなどは避ける
- 深いネストを避ける
- 関数上部で単純な条件を先に処理するガード節を使う
巨大な式を分割する
- 説明変数を導入する
- if文の条件式が長くなるなら条件の否定を考えてみる
変数と読みやすさ
- 中韓結果を格納する変数など、邪魔な変数を削除する
- 変数のスコープをできるだけ小さく
- 一度だけ書き込む変数を使う
- プロジェクト固有のコードから汎用コードを分離する
一度に一つのことを行う
- タスクを全て列挙して別の関数に分割できないか検討する
- 言葉で説明して見ることが重要
短いコードを書く
- 不必要な機能をプロダクトから削除する
- 最も簡単に問題を解決できるような要求を考える
- 定期的に全てのAPIを読み込んで標準ライブラリに慣れ親しんでおく
- 質問と要求を分割する、あらゆる入力をうまく処理する必要はない
テスト
- テストのトップレベルはできるだけ簡潔にする
- テストが失敗したらバグの発見や修正がしやすそうなエラーメッセージを表示する
- テストに有効な最も単純な値を入力につかう
- テスト関数に説明的な名前をつけて、何をテストしているのかを明らかにする
