0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

[読書メモ] リーダブルコード

Posted at

リーダブルコード

  • 著者: Dustin Boswell, Trevor Foucher
  • 出版社: オライリー
  • 出版年: 2012
  • 読書期間: 2024/09/21 ~ 2024/09/26

1. 概要

書籍の大まかな内容を簡潔にまとめます。全体のテーマや重要なトピックを記述しましょう。


2. 目次

  • 第1章: 理解しやすいコード
  • 第2章: 名前に情報を詰め込む
  • 第3章: 誤解されない名前
  • 第4章: 美しさ
  • 第5章: コメントすべきことを知る
  • 第6章: コメントは正確で簡潔に
  • 第7章: 制御フローを読みやすくする
  • 第8章: 巨大な式を分割する
  • 第9章: 変数と読みやすさ
  • 第10章: 無関係の下位問題を抽出する
  • 第11章: 一度に一つのことを
  • 第12章: コードに想いを込める
  • 第13章: 短いコードを書く
  • 第14章: テストと読みやすさ
  • 第15章: 「分・時間カウンタ」を設計・実装する

3. 重要そうなポイント

フォーマット:項目 - (例)

第1章: 理解しやすいコード

  • 読みやすさの基本定理「コードは他の人が最短時間で理解できるように書かなければならない」

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

  • 鍵となる考え「名前に情報を詰め込む」
  • 明確な単語を選ぶ - Get→Fetch, downloadなどGet先に応じて抽象度を落とす
  • 汎用的な名前を避ける - 慣習化しているものなどで例外あり
  • 変数名に大切な情報を付加する - 単位
  • スコープの大きい変数には長い名前をつける

第3章: 誤解されない名前

  • 鍵となる考え「名前が他の意味と間違えられる事はないかと何度も自問自答する」
  • 解釈の揺れを減らす命名 - lengthだとなんの長さかわからん→max_chars
  • 適切な上下の限界値を選ぶ - 最後も含むならfirst-last, 最後を含まないならbegin-end
  • 単語に対するユーザの期待にも注意 - getから始まるメソッドには、多くのプログラマが軽量なアクセサを期待するから計算コストの大きい処理を書かない

第4章: 美しさ

  • 鍵となる考え「」
  • 複数のコードブロックにわたり類似の構造が生じた場合シルエットも揃える
  • 一貫性のあるスタイルで整列 - メンバ変数の順番、メソッドを論理グループ毎に段落化

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

  • 鍵となる考え「コメントの目的は、書き手の意図を読み手に知らせることである」
  • 要らないもの - コードからすぐに抽出できること、ひどいコードを補完するもの(コード自体を修正すべき)
  • 要るもの - なぜ他のやり方ではないのか、定数にまつわる背景、コードブロック単位での概観コメント

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

  • 鍵となる考え「コメントは領域に対する情報の比率が高くなければならない」
  • コメントの意図を書く - 🙅‍♀️:「listをイテレートする」🙆‍♀️:「価格昇順に並び替える」
  • インラインコメントによる名前付き引数 - Connect(/* timeout_ms = */ 10)

第7章: 制御フローを読みやすくする

  • 鍵となる考え「制御フローはできるだけ自然にする」
  • 比較演算は変化する値→安定な値の順に左から書く - while(bytes_recieved > butes_expected)
  • if/elseは適切に並び替える - 肯定系、単純、目立つものを先に書く

第8章: 巨大な式を分割する

  • 鍵となる考え「巨大な式は飲み込みやすい大きさに分割する」
  • ドモルガンの法則、余事象の利用

第9章: 変数と読みやすさ

  • 鍵となる考え「変数を操作する箇所が増えると、現在の状態を管理することが難しくなる」
  • 中間結果を保存するためだけの変数は削除 - found フラッグなど、trueになるときに処理をすることで済むのならその方がいい

第10章: 無関係の下位問題を抽出する

  • 鍵となる考え「無関係の下位問題を積極的に見つけ出し、抽出すること」
  • モジュールが果たすべき本来の目的から見て、副次的な処理は別のコードとして抽出する - フォーマットやファイルの読み書き
  • わずかに読みにくさが生じるからそれを相殺できる範囲で抽出を行う

第11章: 一度に一つのことを

  • 鍵となる考え「コードは一つずつタスクを行うように」
  • そのモジュールが行なっているタスクを全て列挙する→できるだけ異なる関数、少なくとも異なる領域に分割

第12章: コードに想いを込める

  • ボトムアップで処理を積み上げていくのではなく、一度処理の流れをわかりやすく言語化してカラコードに落とし込む

第13章: 短いコードを書く

  • 鍵となる考え「最も読みやすいコードは、何も書かれていないコードだ」
  • 過剰な機能は持たせない
  • 最も簡単に解決できるような要求を考える
  • 定期的にAPIを読んで標準ライブラリに親しんでおく

第14章: テストと読みやすさ

  • 鍵となる考え「大切で無い詳細はユーザーから隠蔽し、大切な詳細だけ見せる」
  • テストのトップレベルは簡潔に - 入出力チェックは1行でかけるのが望ましい
  • エラーメッセージの工夫
  • 入力値を単純で有効なものに

第15章: 「分・時間カウンタ」を設計・実装する

  • ユーザーフレンドリーなコードを書くために、外部の視点を得ることが重要

4. 要約

  • 読みやすさとは「他の人が最短時間で理解できるように書かれていること」であること。
  • 読みやすさの実現のためには1:表面的なもの 2:構成的なものの2点から考える必要があること。
  • 1については主に1~9章に書かれており、2についてはそれ以降に書かれている
  • 1→単一モジュールを対象範囲として、視覚的に、意味的に理解しやすいコードを書くやり方を説明している
  • 主な改善対象としては、変数名、レイアウト、コメント、制御構造
  • 2→モジュール間の統合・分割について。方針は以下
  • モジュールのトップレベルから見て大切では無い詳細は抽象化して切り離す。
  • 処理を言語化してからコード化する

7. その他メモ

関連書籍:『文芸的プログラミング』


0
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?