リーダブルコード 備忘録

「リーダブルコード　より良いコードを書くためのシンプルで実践的なテクニック」という本を読んで、備忘録としてのまとめ。個人的に大切かなと思ったことをまとめるので、全てを網羅していないので気をつけて欲しい。
まだ、初学者なので、一気には頭に入らないよ！
それぞれに鍵となる考えがあるため、それをメインにまとめる。

概要

• １章
• 理解しやすいコード
• 1部(2章〜6章)
  • 命名規則やコメントについて
• 2部(7章〜9章)
  • if,forや関数の分割について
• 3部（１０章〜１３章）
  • コードの再編成
• 4部　comming soon..

１章　理解しやすいコード

鍵となる考え：「コードは理解しやすくなければいけない」

この考えは、この本において基本的な考えになる。
ここでいう理解というのは、他人が最短時間で理解できることである。例えば、

assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied());

と

bucket = FindBucket(key);
if(bucket != NULL)assert(!bucket->IsOccupied());

では、上よりも下の方が理解しやすい。コード量は長くなるが、短ければいいというわけではなく、最短で理解出来る＝良いコードとなる。

1部(2章〜6章)

鍵となる考え：「名前に情報を詰め込む」

一眼見て、その単語から何を意味しているかをわかりやすくするためには…

• 明確な単語を選び、具体的な名前を選ぶ
• tmpなどの汎用的な名前を避ける
• スコープの大きな変数には長い名前をつける
• 大文字や_などに意味を含める

例えば、Get○○のように関数名をつけたとしても、どこからデータを受け取るのかわからない。インターネットから撮ってくるならDownloadを使うなどする。そうした方が理解の齟齬が生まれない。
スコープが大きい変数は、定義した場所から離れることが多いので、その名前を見ただけでも理解出来るように長い名前をつけた方がいい。逆に数行で使用する変数なら、その前後のコードから理解をできるため、短くても良い。
クラスのメンバ変数に_をつけてローカル変数と区別するなどすると、わかりやすい。この辺りはプロジェクトやメンバーとの共通認識が大切なので決めることになる。

鍵となる考え：「名前が「他の意味と間違えられることはないだろうか？」と何度も自問自答する」

コードは理解しやすくなければいけない、という考えのもと、ニュアンスが曖昧や受け取り方で変わるのうな単語は使用せず、明確で記述者の意図がわかるようにする。最善の名前とは、誤解されない名前である。
英単語には意味が曖昧なもの（filter,length,limitなど)が多いので注意。

鍵となる考え：「一貫性のあるスタイルは「正しい」スタイルよりも大切だ」

この章では、コードの美しさに言及されている。各々が適当に自分の好きな順番やコメントをしてしまうと、他人から見ても見辛いものとなる。コードブロックで同じようなことをしていたら、シルエットも同じようにする・縦の列を揃える・段落にわけるなどして、コード全体に一貫性を持たせる。
この辺りは、チームでformatterを使うことで、統一できることが多いので、その恩恵は素晴らしいのだと再認識。

鍵となる考え：「コメントの目的は、書き手の意図を読み手に知らせることである」

コメントの書き方は３ステップ。

• 頭の中のコメントをとにかく書き出す。　「ヤバイ、これはリストに重複があったら面倒なことになる」
• コメントを読んで改善が必要なものを見つける。
• 改善する。　「注意：このコードはリストの重複を処理できません。実装が難しいので。」

誰でもわかるコメントは書かず、書き手の意図を書いていけば良い。なぜ、その関数なのか・変数の意味・読み手が疑問に思うことの補助など。コメントを読むとコードを理解することが格段にしやすくなる。
ただ、大切なのは　「優れたコード　＞　酷いコード　＋　優れたコメント」　コードを直す方が大切。

鍵となる考え：「コメントは領域に対する情報の比率が高くなければいけない」

コメントは理解を促す上で大切だが、画面の占領してしまう。なので、短い分で多くの情報が入ったコメントをする必要がある。そのためには、曖昧な表現は避け、明確な説明をする。１単語で多くの情報を持つ語があればそちらに置き換える。ことを行う。

2部(7章〜9章)

鍵となる考え：「条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く」

鍵となる考え：「行数を短くするよりも、他の人が理解するのにかかる時間を短くする」

コードの制御フローを読みやすくするために、ifの条件分では、左側：変化する対象　右側：あまり変化しない対象　とする。これは読み手が無意識に意識していることである。　例）if ( length >= 10)
また、条件式内は否定系よりも肯定系を使い、３項演算子を無理に使わない。コードは長くなるかもしれないが、読み手が理解しやすいかどうかが大切。
自然にするために、ネストはできるだけ少なくし、関数から早く返した方が読み手もいちいち前に戻る必要がなく理解しやすくなる。

鍵となる考え：「巨大な式は飲み込みやすい大きさに分割する」

コードを読みやすくするための分割する方法

• 説明変数：式をそのまま使わず、変数（数式の意味を表したもの）に格納する。使うときに理解しやすく、何度も使う場合は変更しやすい。
• 要約変数：長い式や多くの変数が含まれている時も、それを意味する変数に格納する。

変数の命名方法は1部で習ったので、それをもとに式に意味を持たす。

鍵となる考え：「「頭がいい」コードに気を付ける。あとで他の人がコードを読むときにわかりにくくなる」

自分ではわかるように省略契やいろいろな別の書き方をしたとしても、他人が見ても読むことが難しければ意味がない。一旦、他の人のコードを見たらと言うように考えて、無理にカッコよく書く必要はない。

巨大な文（ifやforが数多くネストしていたり、同じ記述を繰り返したり）は、読み手に対して大きな負担となる。そう言うぶんを分割することは、記述ミスを減らし、読み手も理解しやすい。そのために、説明変数やようやく変数などのテクニックを使うことで、文自体の概念も理解できるため、全体として良いコードとなる。

鍵となる考え：「変数のことが見えるコード行数をできるだけ減らす」

上では変数をわかりやすく名付けたり、コードの分割のために変数を使うことを学んだ。しかし、変数をいろんなところで使用しすぎると理解し辛いコードとなる。
ここでは、不要な変数を減らしてコードの可読性をあげる。気をつけることは

• 変数はできるだけスコープを縮めて使う。
• 不要な１次変数・中間結果を削除する。

鍵となる考え：「変数を操作する場所が増えると、現在値の判断が難しくなる」

変数を削除することも必要だが、その変数の値が至る所で変更されることも理解し辛くしてしまう。逆に１度だけ書き込む変数を使用した方が可読性が高くなり、理解しやすくなる。

3部（１０章〜１３章）

鍵となる考え：「10章　無関係の下位問題を抽出する」

エンジニアリングとは、大きな問題を小さな問題に分割して、それぞれの解決策を組み立てること
今、行おうとしている処理の核となる部分に付随する下位の処理は関数などで分解する。しかもそれが他の部分で再利用できる汎用的なコードならばなを使いやすくなる。
しかし、分解できるからといってしすぎると反対に理解しづらくなってしまう。やりすぎは良くない。

鍵となる考え：「コードは１つずつタスクを行うようにしなければいけない」

様々な処理を同時にしてしまうと、値や処理が飛び飛びとなり理解しずらいコードとなる。タスクは小さくして、１度に一つのタスクを行うように変更すれば読みやすくなる。これは、関数以外にも適応することができる。

4部（１4章〜１5章）

この章はテストの書き方や分・時間カウンタの実装について、今までの考え方を実際に当てはめて解説しているので、省略

まとめ

多くの考えを知った。１番の核は「他人が読んでも理解できるようなコード」が良いコードということがが、上流から下流に至るまでの様々な部分で気をつけなければいけないが、綺麗なコードを書きたいと思っていたため、いろいろな部分で参考にして行きたい。