リーダブルコード

本書の目的

君のコードをよくすること。

1章

コードは理解しやすくなければならない。

読みやすいコードというのは
具体的には誰かが君のコードを読んで理解する時間を最短にするということだ。
コードは短くした方がいいが、理解するまでにかかる時間を短くする方が大切

<第一部　表面上の改善>

2章

名前に情報を詰め込むということを大事にする

名前は短いコメントのようなもの

・ 明確な単語を選ぶ

・ 汎用的な名前を避ける　

・ 抽象的な名前よりも具体的な名前

・ 接尾語や接頭語を使って情報を追加する

・ 名前の長さを決める

スコープ(その名前が見えるコードの行数)が小さければ変数名前は短くてもいいとしている

・ 大文字やアンダースコアなどに意味を含める

例えば、クラスのメンバ変数にアンダースコアをつけてローカル変数と区別する

変数であっても関数であっても、クラスであっても同じ原則を当てはめることができる。

3章

前章は名前に情報を詰め込むことに触れられたが、3章では誤解される名前に気をつけるということを主張している。

・上下の限界値を決めるときはmin、maxを使用する

・範囲を指定する時、包括的範囲であればはfirst、lastを使用する

・包含・排他的範囲にはbegin、endを使用する

・ブール値ではそれがブール値だとわかるようにisやhasを使用する

・複数の名前を検討する

最善の名前とは、誤解されない名前である。つまりコードを読んでいる人が書いた人の意図を正しく理解できること。

4章

優れたソースコードは目に優しいものでなければいかない。

コードを読みやすくするための余白・配置・順序について書かれている。
3つの法則が紹介されている
1.読み手が慣れているパターンと一貫性のあるレイアウトを使用する
2.似ているコードは似ているように見せる
3.関連するコードをまとめてブロックにする

・一貫性のある簡潔な改行位置
・メソッドを使った整列
・縦の線をまっすぐにする
・一貫性と意味のある並びにする
・宣言をブロックにまとめる
・コードを段落に分割する
・個人的な好みと一貫性

特に一貫性を持つことを重要。一貫性のあるスタイルは『正しい』スタイルよりも大切である。

5章

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

コメントの目的は、書き手の意図を読み手に知らせること

1.コメントすべきでは「ない」ことを知る

コードからすぐにわかることをコメントに書かない
ひどい名前はコメントをつけずコードの名前を変える

2.コードを書いているときの自分の考えを記録する

優れたコメントというものは『考えを記録する』ためのものである
コードが汚く誰かに修正を促すようなコメントや他の書き方でなくなぜこの書き方になっているのか
・コードの欠陥にコメントをつける。
・定数にコメントをつける。なぜその値を持っているかなど

3.読み手の立場になって何が必要になるかを考える

読み手というのはプロジェクトを書き手のように熟知していない人のことである
・質問されそうなことを想像する
・ハマりそうな罠を告知する
・「全体像」のコメント　新しいメンバーにとって最もむずかしのは全体像の理解である。簡単なものでもいいので入れるべき。
・読み手が細部に捕われないように、コードブロックにコメントをつけて概要をまとめる

コメントにはWHATではなくWHYを書こうというアドバイスがあるが、コードを理解するのに役立つもの何でもいいから書こうというのが作者の主張である。

6章

どうすればコメントは正確で簡潔に書けるか

・あいまいな代名詞を避ける

複雑なものを指す可能性がある「それ」や「これ」などの代名詞を避ける

・歯切れの悪い文章を磨く

・関数の動作を正確に記述する

・入出力のコーナーケースに実例を使う

コメントに含める入出力の実例を慎重に選ぶ

・コードの意図をかく

・「名前付き引数」コメント

よくわからない引数にはインラインコメントを使用する

・情報密度の高い言葉をつかう

多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔にかく

<第二部　ループとロジックの単純化>

7章

条件やループなどの制御フローがないコードは読みやすい。

他の場所に飛んだり枝分かれしたりするのは複雑なので、コードがすぐにわかりにくくなってしまう。コードの制御フローをを読みやすくすることについて書かれている。

・条件式の引数の並び順

・if/else ブロックの並び順

条件は否定形よりも肯定形を使う。
単純な条件式を先に書く。
関心を引く条件や目立つ条件を先に書く。

・三項演算子を用いる

・do/while ループを避ける

・関数から早く返す

・ネストを浅くする

・早めに返してネストを削除する

ネストを削除するには「失敗ケース」をできるだけ早めに関数から返せばいい

・ループ内部(多重ループ)のネストを削除する

8章

巨大な式は飲み込みやすい大きさに分割する

・説明変数を用いる

式を簡単に分割するには式を表す変数を使えばいい。この変数を説明変数と呼ぶ
簡潔な名前で式を説明することでコードを文章化できる
コードの主要な概念を読み手が意識しやすくなる

・要約変数を用いる

大きなコードの塊を小さな名前に置き換えて、管理や把握を簡単にする変数のこと

・ド・モルガンの法則をつかう

「notをくくりだす」
例　not( a or b or c ) = ( not a ) and ( not b ) and ( not c )

・短絡評価の悪用

プール演算子は短絡評価を行うものが多い。

「頭がいい」コードに気をつける。あとで他人がコードを読むときに分かりにくくなる

9章

変数と読みやすさ

変数を適当に使うとプログラムが理解しにくくなる。具体的には3つの問題がある。

1.変数が多いと変数を追跡するのが難しくなる
2.変数のスコープが大きいとスコープを把握するのに時間がかかる
3.変数が頻繁に変更されると現在の値を把握するのが難しくなる
これらの問題にどう対処するか。

・変数を削除する

コードが読みやすくならない変数を削除する

・グローバル変数は避ける

グローバル変数はどこで使われているが難しく、ローカル関数と衝突する可能性がある

・変数は一度だけ書き込む

一度だけ書き込むという手法が使えないにしても、変数の変更箇所はできるだけ少なくしたほうがいい。
変数を操作する場所が増えると、現在地の判断が難しくなる。

<第三部　コードの再構成>

10章

エンジニアリングとは大きな問題を小さな問題に分割して、それぞれの解決策を組み立てることに他ならない。
10章では無関係の下位問題を積極的に見つけて抽出することについて

1.関数やコードブロックをみて「このコードの高レベルの目標は何か？」と自問する
2.コードの各行に対して「高レベルの目標に直接的に効果があるのか？あるいは、無関係の下位問題を解決しているのか？」と自問する
3.無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする

・汎用コードを作る

巨大な関数の中から、汎用的な処理を見つけ出しメソッド化していく

・プロジェクトに特化した機能

抽出する下位問題というのは、プロジェクトから完全に独立したものであるほうがいい。ただし、完全に独立していなくても、それは問題ない。下位問題をのぞくだけでも効果がある。

・既存のインターフェースを簡潔にする

・必要に応じてインターフェースを整える

本章をまとめるとプロジェクト固有のコードから凡庸コードを分離するということ。ほとんどのコードは凡庸化できる。一般的な問題を解決するライブラリやヘルパー関数を作っていけばプログラムに固有の小さな核だけが残る。

11章

コードは一つずつタスクを行うようにしければならない、一度に複数のことをするコードは理解しにくい。

一度に一つのタスクをするための手順の紹介

1.コードが行っている「タスク」をすべて列挙する。

この「タスク」という言葉はユルく使っている。「オブジェクトが妥当かどうかを確認する」のように小さなこともあれば、「ツリーのすべてのノードをイテレートする」のようにあいまいなこともある。

2.タスクをできるだけ異なる関数に分割する。少なくとも異なる領域に分割する。

12章

コードに思いを込める

コードを簡単な言葉で書くべきである。

1.コードの動作を簡単な言葉で同僚にも分かるように説明する。

2.その説明の中で使っているキーワードやフレーズに注目する

3.その説明に合わせてコードをかく

13章

短いコードを書く

最も読みやすいコードは何も書かれていないコードだ

機能を実装するときかっこいい機能のことを考へるが、プロジェクトに欠かせない機能を過剰に見積もってしまい多くの機能が、完結しないか、全く使われていないか、アプリケーションを複雑にするものになってしまう。

コードを小さく保つ
プロジェクトが成長しても、コードをできるだけ小さく軽量に維持していかなければならない。具体的に、

・凡庸的な「ユーティリティ」コードを作って、重複コードを削除する。

・未使用のコードや無用の機能を削除する

・プロジェクトをサブプロジェクトに分割する

・コードの重量を意識する。軽量で機敏にしておく。

新しいコードを書かないようにするには、

・不必要な機能をプロダクトから削除する。過剰な機能はもたせない。

・最も簡単に問題を解決できるような要求を与える。

・定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく