Open1
リーダブルコード
philosophynote各章のまとめ（鍵となる考え）
１章
コードは理解しやすくなければならない
コードは他の人が最短時間で理解できるように書かなければならない
２章
名前に情報を詰め込む
- 明確な単語を選ぶ
気取った言い回しよりも明確で正確な方がいい - 汎用的な名前を避ける
変数の値を表す名前を使う - 抽象的な名前よりも具体的な名前を使う
- 接尾辞や接頭辞を使って情報を追加する
- 名前の長さを決める
- 名前のフォーマットで情報を伝える
３章
名前が「他の意味と間違えられることはないだようか？」と何度も自問自答する
- 限界値を含めるときはminとmaxを使う
- 範囲を指定するときはfirstとlastを使う
- 包括／排他的範囲にはbeginとendを使う
- ブール値の変数名は、頭にis・has・can・shouldをつけるか最後に?をつける
- ユーザの期待に合わせる
- 複数の名前を検討する
４章
見た目が美しいコードの方が使いやすい
- 改行位置は適切に
- 並び順に一貫性を持たせる
- 宣言はブロックにまとめる
- コードを段落にまとめる
５章
コメントの目的は、書き手の意図を読み手に知らせることである
- コードからすぐにわかることはコメントに書かない
- ひどい名前はコメントをつけずに名前を変える
- コードに対する考えをコメントに入れる
- コードの欠陥にコメントをつける
- 定数にコメントをつける
- 読み手の立場に立って考える
- 質問されそうなことを想像してコメントをつける
- 平均的な読み手が驚くような動作は文書化しておく
- ファイルやクラスには「全体像」のコメントを書く
- 読み手が細部に囚われないように、コードブロックにコメントをつけて概要をまとめる
６章
コメントは領域に対する情報の比率が高くなければならない
- 複数のものを指す可能性がある「それ」や「これ」といった代名詞は避ける
- 関数の動作はできるだけ正確に説明する
- コメントに含める入出力の実例を慎重に選ぶ
- コードの意図は、詳細レベルではなく、高レベルで記述する
- よくわからない引数にはインラインコメントを使う
- 多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ
７章
条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く
- 条件式の引数の並び順は次のようにする
左側：「調査対象」の式。変化する。
右側：「比較対象」の式。あまり変化しない。 - if/elseブロックの並び順
条件は否定形よりも肯定形を使う
単純な条件は先に書く
関心を引く条件や目立つ条件を先に書く - 関数から早く返す
８章
巨大な式は飲み込みやすい大きさに分割する
- 説明変数（式を表す変数）を使えばいい
- 要約変数（大きなコードの塊を小さな名前に置き換える）を利用する
- 複雑な条件式や短絡評価を書かない
９章
変数の量を減らす
- 次の変数は役に立たない可能性があるので削除を検討する
複雑な式を分割しない
変数を使わなくても意味が明確
一度しか使っていない - 中間結果は削除する
- 変数のスコープは縮める
- 変数の変更箇所はできるだけ少なくする
10章
プロジェクト固有のコードから汎用コードを分離する
- 関数やコードブロックを見て「このコードの高レベルの目標は何か？」と自問する。
- コードの各行に対して「高レベルの目標に直接的に効果があるのか？あるいは、無関係の下位問題を解決しているのか？」と自問する。
- 無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする。
- 1つのコードの中で2つ以上の問題を解決しようとしていないか？
「無関係」の下位問題があれば分割する - ユーティリティコード（汎用性が高いコード）は分割する
11章
コードは１つずつタスクを行うようにしなければならない
12章
コードは「簡単な言葉で」書くべき
- コードの動作を簡単な言葉で同僚にもわかるように説明する
- その説明の中で使っているキーワードやフレーズに注目する
- その説明に合わせてコードを書く
13章
最も読みやすいコードは、何もかかれていないコードだ
新しいコードを書くとその分だけテストや文書や保守が必要になる
新しいコードを書かないようにするには、
- 不必要な機能をプロダクトから削除する。過剰な機能は持たせない。
- 最も簡単に問題を解決できるような要求を考える。
- 定期的に全てのAPIを読んで、標準ライブラリに慣れ親しんでおく
14章
他のプログラマが安心してテストの追加や変更ができるようにテストコードを読みやすくする
- 大切ではない詳細はユーザから隠し、大切な詳細は目立つようにする
- 最小のテストを作る
- 独自の「ミニ言語」を作る
- エラーメッセージを読みやすくする
- テストの適切な入力値を選択する
- テストの機能に名前をつける
15章
実践例なので省略
解説
読みやすいコードを書くために
- 実際にやる（多分「活かす場所が全然ない」と思う）
- 他の人に読んでもらう
- 当たり前にする
- コードで伝える