読書感想文 - リーダブルコード

概要

名著としてよく知られている。コード改善のノウハウ本。四章十五章から構成されており、パフォーマンス改善といったアプリの挙動には一切触れない チーム開発をするときにどのようにコードを書けば同僚・第三者に読みやすく、開発しやすく、改善しやすいコードが書けるかを具体的な例を交えながら解説されている。

備忘録代わりにざっくりと何が書かれていたのかを自分用に噛み砕く。

一部 表面上の改善

• 変数はひと目でわかり易い名前にしろ
  • 多少長くても意味が第三者にわかる変数をつけろ
  • tmpとか汎用的な名前はやめろ
• 誤解されそうな前はつけなように第三者にレビューしながら慎重に決めろ
• レイアウト・フォーマットは絶対揃えろ。
• イコールの位置だったり、関数宣言を意味のある塊に分けたり
• 今だったらlintにここは任せても良いかも[IMO]
• コメントは書け
• コードから読み取れることは書くな。
• 理由があってこういった実装したみたいな、背景とかならどんどんかけ
• とはいえど下手な文章でコメント書くな
  • 引数にコメントもかけるよ
  • 入出力の実例も複雑になりそうなら書いとけ。エッジケースを含んでると良いぞ

二部 ロジックの整理・単純化

• 条件式は否定より肯定を使え
• 関数からはできるだけ早く戻り値を返せ
• ネストはなるたけ浅くなるように
• 論理式はわかりやすのを使え
  • ド・モルガンとか有効
• 不要な変数(一時変数や中間結果を保存しているような変数、フローを制御するような変数{flagとか?})は削除せよ
• 変数のスコープは短いほうが良い
• constは積極的に使え
  • 一度しか書き込まない変数は理解しやすい

三部 コードの再構成

• 共通化できそうな汎用的な関数は抽出しろ
  • やりすぎると見通しが悪くなるので要注意
• 一つの塊で一つのタスクを行う
• たまにでいいのでライブラリのドキュメントを見ること
• コードが何をやっているか言葉で説明できるようにしろ
  • 言葉にできないのであればやりたいことが明確になっていない
• コードは小さい/短いほうが見通しが良い。
• 問題に対して過剰な機能を利用して解決する必要はない
• YAGNIの法則かな.(IMO)

  四部 選抜テーマ

• 今までの原則をテストコードや実際のコードに適用してみよう。
• テストのために実際のコードを犠牲にするのはちょっとまって
• カバレッジ100%はつらいぞ
• テストがプロダクト開発の邪魔になるのは本末転倒
• エラーメッセージは第三者が見てわかるように書け

一つひとつの事柄は基本的なことで、難しくなくともなかなか全部満たしているコードは見つけられない。 ぜひこれらのことを意識して今後コードを書いていきたい。

個人的に15章の難易度が他に比べてドチャクソ上がったのが気になった。 15章ぐらいの難易度の設計をぱっと思いつくくらいにはなりたい。忘れそうならその都度読み返して見ようと思う。