書籍「リーダブルコード」を読みつつ自分用のメモとしてまとめたので、備忘としても残しておく。
1章 理解しやすいコード
- コードは理解しやすくなければいけない
- コードは他の人が最短時間で理解できるように書かなければいけない
- コードを理解するとは「バグを見つけられる」「変更を加えることができる」「6ヶ月後の自分も含んだ他人が上記を行える」
- 理解する時間を短くするコードのためのコメントもあり
第一部 表面上の改善
2章 名前に情報を詰め込む
- 名前に情報を詰め込む
テーマ
- 明確な単語を選ぶ
- 気取った言い回しよりも明確で正確な方がいい
- 汎用的な名前を避ける（あるいは、使う状況を選ぶ）
- tmp・it・retvalのような汎用的な名前を使うときは、それ相応の理由を用意しよう
- 抽象的な名前よりも具体的な名前を使う
- 接尾語や接頭語を使って情報を追加する
- 名前の長さを決める
- 名前のフォーマットで情報を伝える
類語辞典を活用しよう
3章 誤解されない名前
- 名前が「他の意味と間違えられることはないだろうか？」と何度も自問自答する
- 最善の名前とは誤解されない名前
- 自分が書いたプログラムが正しく他人に理解されるかどうか
4章 美しさ
- 一貫性のあるスタイルは正しいより重要だ
- 複数のコードブロックで同じようなことをしていたら、シルエットも同じようなものにする
- コードの「列」を整列すれば、概要が把握しやすくなる
- ある場所で【A・B・C】のように並んでいたものを、他の場所で【B・C・A】のように並べてはいけない。意味のある順番を選んで、常にその順番を守る
- 空行を使って大きなブロックをロン履歴な「段落」に分ける
5章 コメントすべきことを知る
- コメントの目的は、書き手の意図を読み手に知らせることである
- コードからすぐわかることをコメントに書かない
- コードを理解することに役立つものなら何でもいいから書こう
- コメントを書く作業は３つに分解できる
- 頭の中にあるコメントをとにかく書き出す
- コメントを読んで（どちらかと言えば）改善が必要なものを見つける
- 改善する
- 酷いコード＋コメントではなくコードそのものを改善すること
6章 コメントは正確で簡潔に
- コメントは領域に対する情報の比率が高くなければいけない
- 複数のものを指す可能性がある「それ」や「これ」などの代名詞を避ける
- 関数の操作はできるだけ正確に説明する
- コメントに含める入出力の実例を慎重に選ぶ
- コードの意図は、詳細レベルではなく、高レベルで記述する
- よくわからない引数にはインラインコメントを使う（例：Function ( / arg = / ...)）
- 多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ
