リーダブルコードを読んで、自分にとって必要な箇所（全部ですが）のメモ。
書籍の中でも鍵となる考え方として書かれています。
読みやすさの基本定理
- コードは理解しやすくなければならない
- コードは他人が最短時間で理解できるように書かなければいけない
表面上の改善
- 変数、関数名に情報を詰め込む
- 明確な単語を選ぶ
- 気取った言い回しよりも明確で正確なほうがいい
- 汎用的な名前を避ける（あるいは、使う状況を選ぶ）
- tmp,it,retval のような汎用的な名前を使うときはそれ相応の理由を！
- 抽象的な名前よりも具体的な名前を使う
- 例) × ServerCanStart() → ○ CanListenOnPort()
- 接尾辞や接頭辞を使って情報を追加する
- 例) ミリ秒を表す変数名 〇〇_ms
これからエスケープが必要な変数名 raw_〇〇
- 例) ミリ秒を表す変数名 〇〇_ms
- 名前の長さを決める
- スコープの大きな変数には長い名前をつける
短い名前はスコープが数行の変数に
- スコープの大きな変数には長い名前をつける
- 名前のフォーマットで情報を伝える
- 大文字やアンダースコアなどに意味をもたせる
- 例) クラスのメンバ変数にアンダースコアをつけてローカル変数と区別する
- 大文字やアンダースコアなどに意味をもたせる
- 明確な単語を選ぶ
誤解されない名前
- 名前が「他の意味と間違えられることはないだろうか？」と何度も自問自答する
- 限界値を含める時は max_〇〇 や min_〇〇 とする
- 範囲を指定する時は first と last を使う
- ブール値の変数名には is, has, can, should などの単語を使う
- disable_ssl のような否定形は避ける
- 単語に対するユーザーの期待にも注意する
美しさと設計
- 一貫性のあるスタイルは正しいスタイルよりも大切
- 複数のコードブロックで同じようなことをしていたら、シルエットも同じようなものにする
- コードの列を整列すれば、概要が把握しやすくなる
- 意味のある順番を選んで、常にその順番を守る
- 空行を使って大きなブロックを論理的な「段落」に分ける
コメントすべきことを知る
- コメントの目的は書き手の意図を読み手に知らせることである
- コメントをするべきではないこと
- コードからすぐにわかることを書かない
- ひどいコードを補う補助的なコメント
コメントを書くのではなくコードを修正する
- コードを書いているときの自分の考えを記録する
- なぜコードがこうなっているのか
- コードの欠陥を示す
- 定数の値にまつわる背景
- 読み手の立場になって何が必要になるかを考える
- 読み手の解読が難しそうなコード、動作を予想してコメントをつける
- ファイルやクラスには全体像のコメントを書く
- 読み手が細部に捕われないように、コードブロックにコメントをつけて概要をまとめる
- コメントをするべきではないこと
コメントは正確で簡潔に
- 複数のものを指す可能性がある「それ」「これ」等の代名詞を避ける
- 関数の動作はできるだけ正確に説明する
- コメントに含める入出力の実例を慎重に選ぶ
- コードの意図は詳細レベルではなく、高レベルで記述する
- よくわからない引数にはインラインコメントを
- 多くの意味が詰め込まれた言葉や表現を使ってコメントを簡潔に保つ
変数と読みやすさ
- 変数のスコープをできるだけ小さくする
- 一度だけ書き込む変数（const, finalなど）を使う
コードの再構成
- プログラムの主目的と関係のない無関係の下位問題を抽出する
- コードを再構成して、一度に1つのことをやるようにする
- 最初にコードを言葉で説明する。その説明を元にキレイな解決策を作る
読みやすいコードを書くために
- 本書で学んだことを実践する
- 習慣化する
- コードで伝える
Qiita の中にもリーダブルコードに関する記事がたくさんあったので、参考にしていきたい。