読者です 読者をやめる 読者になる 読者になる

うろ覚えの雑感

何でも適当に書いていくブログ

リーダブルコード 第一部

リーダブルコード 読書

書籍「リーダブルコード」を読みつつ自分用のメモとしてまとめたので、備忘としても残しておく。

1章 理解しやすいコード

  • コードは理解しやすくなければいけない
  • コードは他の人が最短時間で理解できるように書かなければいけない
    • コードを理解するとは「バグを見つけられる」「変更を加えることができる」「6ヶ月後の自分も含んだ他人が上記を行える」
  • 理解する時間を短くするコードのためのコメントもあり

第一部 表面上の改善

2章 名前に情報を詰め込む

  • 名前に情報を詰め込む

テーマ

  • 明確な単語を選ぶ
    • 気取った言い回しよりも明確で正確な方がいい
  • 汎用的な名前を避ける(あるいは、使う状況を選ぶ)
    • tmp・it・retvalのような汎用的な名前を使うときは、それ相応の理由を用意しよう
  • 抽象的な名前よりも具体的な名前を使う
  • 接尾語や接頭語を使って情報を追加する
  • 名前の長さを決める
  • 名前のフォーマットで情報を伝える

類語辞典を活用しよう

3章 誤解されない名前

  • 名前が「他の意味と間違えられることはないだろうか?」と何度も自問自答する
  • 最善の名前とは誤解されない名前
  • 自分が書いたプログラムが正しく他人に理解されるかどうか

4章 美しさ

  • 一貫性のあるスタイルは正しいより重要だ
  • 複数のコードブロックで同じようなことをしていたら、シルエットも同じようなものにする
  • コードの「列」を整列すれば、概要が把握しやすくなる
  • ある場所で【A・B・C】のように並んでいたものを、他の場所で【B・C・A】のように並べてはいけない。意味のある順番を選んで、常にその順番を守る
  • 空行を使って大きなブロックをロン履歴な「段落」に分ける

5章 コメントすべきことを知る

  • コメントの目的は、書き手の意図を読み手に知らせることである
  • コードからすぐわかることをコメントに書かない
  • コードを理解することに役立つものなら何でもいいから書こう
  • コメントを書く作業は3つに分解できる
    • 頭の中にあるコメントをとにかく書き出す
    • コメントを読んで(どちらかと言えば)改善が必要なものを見つける
    • 改善する
  • 酷いコード+コメントではなくコードそのものを改善すること

6章 コメントは正確で簡潔に

  • コメントは領域に対する情報の比率が高くなければいけない
  • 複数のものを指す可能性がある「それ」や「これ」などの代名詞を避ける
  • 関数の操作はできるだけ正確に説明する
  • コメントに含める入出力の実例を慎重に選ぶ
  • コードの意図は、詳細レベルではなく、高レベルで記述する
  • よくわからない引数にはインラインコメントを使う(例:Function ( / arg = / ...))
  • 多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ