エンジニアの登竜本（？）であるリーダブルコードを読んだので、自分の言葉でまとめてみました。
対象者
- 自分
- リーダブルコードを未読で、ざっくり内容だけ把握したい方
読んだ経緯
- 多くのエンジニアが読了していて薦めているので、「可読性」の指標になっていると考えた。
- その為この本に則ったコードを書けば大体の人が読みやすいと感じるコードを書けると思った。
- 今後の自身の開発や人のコードを読む際の意識点として取り入れるため。
表面上の改善点
理解しやすいコードとは
- 優れたコードとは「理解しやすいもの」、「他の人が見て最短時間で理解できるもの」。
（理解の定義：コードに変更を加えたり、バグを発見できる。他コードとの連携方法が理解できる）
ポイント コードを理解するまでの時間の短さ＞コードの短さ
名前に情報を詰め込む
- 名前は短いコメント。
見ただけで情報が読み取れる名前をつける。（変数の目的や値を表す） - 明確な単語選択。
- 具体的な名前をつける。
- 接尾辞、接頭辞を使い情報を追加。（inputByUser)
- あらかじめ長さを決めておく。
- 値の単位を入れる（start_ms など）
- プロジェクト内で一貫性を持たせる。
- 新しくプロジェクトに参画した人が意味を理解できるのか？
ポイント 意味の明確さ＞短さ
読み手に疑問を抱かせない
- 他の意味にとられる名前をつけない。
NG例
filter（選択するとも除外するとも受け取れる）
⭕️選択する→select 除外する→exclude
- 限界値の設定（max,min）は名前の前につける。
- 範囲の指定（first~last)(begin~end)
見た目を揃える
- 一貫性のあるレイアウト（改行位置を揃える・重複排除）
- 似ているコードはレイアウトを揃える
- 関連するコードはまとめて１ブロックにする
- 見た目が美しいほうが当たり前に読みやすい。
- また、見た目が揃えば表面上だけでなく構造の改善にもつながる。
例：列を整列（縦のラインを揃える）→概要が把握しやすくなる。
コードを段落ごとに分割し段落ごとに概要コメント追加。
ポイント （場合によっては）一貫性＞正しいスタイル
コメントの目的を理解する
- コメントの目的は書き手の意図を読み手に知らせること。
- 全体像のコメントと機能要約コメントをする。
- 価値のないコメント…コードを見たらすぐにわかる内容。
- 価値のあるコメント…自分の考えの記録。（なぜこのやり方にしたのか、定数の値にまつわる背景 など）
- コメントの先頭で意味がわかるようにする。
| 例 | コメント内容 |
|---|---|
| TODO: | あとで手を付ける |
| FIXME: | 既知の不具合があるコード |
| HACK: | あまり綺麗ではない解決策をしている |
| XXX: | 危険！大きな問題あり |
コメントの正確性と簡潔さ
- 曖昧な代名詞を避ける。（それ、これ、ここ など）
- 関数の動作を正確に記述する。
ループとロジックの単純化
制御フローを読みやすくする
- 条件式の書き方。
ポイント
左側：調査対象の式。変化する。
右側：比較対象の式。あまり変化しない。
- 条件は否定形よりも肯定形を使う。
ポイント
⭕️ if(a == b)
❌ if(a != b)
- 単純な条件を先に書く。
- ネストを浅くする。
（早めに返してネストを削除。失敗ケースをできるだけ早めに関数から返す。）
巨大な式を分割する
- コードの式が大きくなればなるほど理解が難しくなる。
- 説明変数を使って巨大な式を分割。
簡潔な名前で式を説明することでコードを文書化できる。 - 要約変数を使う。
（大きなコードの塊を小さな名前に変える）
変数
- 変数が多いと追跡が困難になるので、むやみに増やさない。
- スコープを小さくする。
（スコープが大きいと把握に時間がかかる） - メソッドをできるだけstaticにする。
（メンバ変数と関係ないことがすぐわかる為）
コードの再構成
無関係の下位問題を抽出する
- 関数やコードブロックをみて「コードの高レベルの目標が何か」を考える。
- 関数は小さく独立していれば機能追加がしやすい
１度にひとつのことを
- タスクが個別に完結しているコードのほうが理解しやすい。
- タスクをできるだけ異なる関数に分割する。
- コードをリファクタリング。
①そこで行われているタスクを列挙。
②別の関数やクラスに分割できるタスクを見つける。
コードに思いをこめる
- 自分より知識が少ない人でも理解できる簡単な言葉で説明する能力が必要。
- 簡単な言葉でロジックを明確に説明できるようになる。
- 問題や設計をうまく言語化できない場合→自分の中で詳細が明確になっていない。
短いコードを書く
- できるだけコードを書かない。
- 過剰に機能を実装しようとしていないか？を見直す。
- コードをできるだけ小さく軽量に。
（重複コードの削除、未使用のコードや無用機能の削除、プロジェクトをサブプロジェクトに分割、コードの重量を意識する） - ライブラリを有効活用する。
（どんなことができそうかを感じ取れる程度の認識でOK。）
選択テーマ
テストと読みやすさ
- テストコードの可読性と保守性をあげる。
- エラーメッセージを読みやすくする。
- 適切な入力値を選択。入力値の単純化。
- １つの機能に対して複数のテスト。
（別々の方向からバグを見つける） - テスト機能にもテスト内容を表した名前をつけるべき。
（テストするクラス、関数、状況やバグがすぐに理解できるとよい） - やりすぎない。
（あくまで本物のコードの読みやすさが第一優先）
実践が大事
- 実際にやってみる。
- 他の人に読んでもらう。
- 当たり前にできるようにする。
- 続けることが大事。
他人にも自分にも優しいコードをかけるよう実践します。