リーダブルコードをマインドマップでまとめる


# はじめに

いわずもがな知れている名著で、既にいろんな方がブログやQiita等でまとめています。

今更ごく普通にまとめてもということで、どうしようかと思っていたところ

マインドマップでまとめた記事が見当たらなかったので、

### マインドマップにまとめました


各章もしくは見出しごとにマインドマップを貼り、それに対するコメントがあれば、付けています。

※内容を網羅しているわけではありません。自分にとって特に重要と感じた部分の抜粋なので、あしからず。

***

## 理解しやすいコード
![リーダブルコード_1.png](https://qiita-image-store.s3.amazonaws.com/0/295868/2c4a1600-572c-5595-18f7-e6cac90b4ec0.png)


ここにリーダブルコードの本質が書かれています。

コードは**他の人が最短時間で理解できるようにする**こと。

これを前提として、じゃあ**こうすればみんなわかりやすいんじゃないの？**といったテクニックや考え方が展開されていきます。 

## 名前に情報を詰め込む
![リーダブルコード_2.png](https://qiita-image-store.s3.amazonaws.com/0/295868/701ea9e7-bf13-756e-6880-4c0f488d28f0.png)

**わかりやすい名前**
これを意識するだけで**可読性**が全然違ってきます。

ポイントは

**・明確**
**・汎用的な名前は避ける**
**・長さ**
**・フォーマット**

 だと思います。

## コメントすべきことを知る
![リーダブルコード_3.png](https://qiita-image-store.s3.amazonaws.com/0/295868/2c0f8d37-7633-edd7-96e3-a1f5f94ba4cb.png)

**コードから読み取れないことをコメントに書く**

**How**はコードから読み取れるため、**Why**を書きなさい、とよく言われているあれです。
むやみ、やたらにコメントしないこともコツ。**最低限のコメントで管理すること**と、

**コメントのアップデート**

忘れがちですが、必ずしないとあとで悲惨な目にあいます。

## コメントは正確で簡潔に
![リーダブルコード_4.png](https://qiita-image-store.s3.amazonaws.com/0/295868/2de77e98-49f0-159a-68be-e800ca804572.png)
**書くなら意味のあることを残しましょう**

## 制御フローを読みやすくする
![リーダブルコード_5.png](https://qiita-image-store.s3.amazonaws.com/0/295868/a4f1fbfa-03b8-c7c1-8adc-1bf85c246329.png)

条件式を複雑にして行数を減らすより、**「自然」**に理解できるように書くことが大事

そして、**ネストは浅く**ね。

## 巨大な式を分割する
![リーダブルコード_6.png](https://qiita-image-store.s3.amazonaws.com/0/295868/93dc5861-be52-0af4-57bc-3b1637499d09.png)

**複数の条件式をくっつけすぎない**

スムーズに理解できる程度におさめましょう。

## 変数の読みやすさ
![リーダブルコード_7.png](https://qiita-image-store.s3.amazonaws.com/0/295868/16bcc6a3-3327-fce4-f61a-87fa9cc6441c.png)

**使う直前に宣言すること。**

そして、**スコープ**（参照される範囲）をできるだけ短くすることです。

結局そんな前に宣言された変数なんて覚えてないし、いちいち戻って確認に時間かかるから。

これは意識する基本原則で、例外の場合もあるため囚われ過ぎちゃだめ。

あと、変数の使い回しも基本的にはNG

## コードに思いを込める
![リーダブルコード_8.png](https://qiita-image-store.s3.amazonaws.com/0/295868/208c5258-1014-0355-e0ec-63905e015f16.png)


## 短いコードを書く
![リーダブルコード_9.png](https://qiita-image-store.s3.amazonaws.com/0/295868/8f81a4e6-4112-a6a7-d5d5-457504d29acf.png)
**メソッド内の行数を減らす**

そもそも、**単一原則**を意識したらそもそも行数はそこまで増えないはず。


> SOLID
> オブジェクト指向設計に関する原則の頭文字をとって「SOLID」とまとめられた原則集。
> Single Responsibility Principle（単一責務の原則） 「クラスを変更する理由は１つでなければならない」 
> https://qiita.com/hirokidaichi/items/d6c473d8011bd9330e63


また、コメントアウトしてコードを残す派とコードを消す派の議論は絶えませんが、

個人的には、**不必要なコメントアウトは消していい**と思います。

いつまで残してても混乱させるだけです。

## 誤解されない名前
![リーダブルコード_10.png](https://qiita-image-store.s3.amazonaws.com/0/295868/1af6d04b-c639-febb-8ecc-9f92dffdcd4d.png)
**誤解されない名前をつける**

もし、いい名前が思いつかないときはコメントで補足すればいいと思います。

また、接頭辞や接尾辞でそれが何を表しているか、工夫するといいです。

## テストと読みやすさ
![リーダブルコード_11.png](https://qiita-image-store.s3.amazonaws.com/0/295868/986ca987-dd74-9794-b64f-125d0fc886d0.png)

**エラーメッセージを工夫しましょう**

テストを前提にして、コードを設計すること。

## 美しさ
![リーダブルコード_13.png](https://qiita-image-store.s3.amazonaws.com/0/295868/ce61d108-de8b-601a-c6ac-2eb3842ac696.png)

**コードに一貫性をもたせる**

**知っているパターン**が出てくるだけで、流れやこれからのロジックが予測できます。

それはつまり、**理解のスピード**が全然違ってきます。

**形が似ているのに構造が違うコード**を書いてはいけません。混乱します。

## 一度に一つのことを
![リーダブルコード_14.png](https://qiita-image-store.s3.amazonaws.com/0/295868/c1b2f211-c459-46df-db0d-958177c1fe69.png)
所謂、単一原則です。

複数担ってきたら他に**委譲**しましょう。

## 無関係の下位問題を抽出する
![リーダブルコード_15.png](https://qiita-image-store.s3.amazonaws.com/0/295868/33be5ae0-9fc9-1b4b-a96f-8b366cc3f54a.png)
**改良が入ることを踏まえて設計すること**

急に仕様変更や細かい変更がくることはざらです。（ほんとにもう、、ね）

基本的にはYAGNIですが、柔軟にしておくことです。

> YAGNI
> "You ain't gonna need it"縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。
> https://ja.wikipedia.org/wiki/YAGNI

## 解説（まとめ）
![リーダブルコード_12.png](https://qiita-image-store.s3.amazonaws.com/0/295868/d8cb4ad4-f0cc-4255-6b50-cf55b20a6303.png)

いつ誰が見てもわかりやすいコードを書くことを意識すること。

そしてそれを実践すること、継続すること、それを当たり前にしていくこと

これらを習慣化することで、読みやすいを当たり前にしていくようにしていくことを説いています。