はじめに
いわずもがな知れている名著で、既にいろんな方がブログやQiita等でまとめています。
今更ごく普通にまとめてもということで、どうしようかと思っていたところ
マインドマップでまとめた記事が見当たらなかったので、
マインドマップにまとめました
各章もしくは見出しごとにマインドマップを貼り、それに対するコメントがあれば、付けています。
※内容を網羅しているわけではありません。自分にとって特に重要と感じた部分の抜粋なので、あしからず。
理解しやすいコード
ここにリーダブルコードの本質が書かれています。
コードは他の人が最短時間で理解できるようにすること。
これを前提として、じゃあ**こうすればみんなわかりやすいんじゃないの？**といったテクニックや考え方が展開されていきます。
名前に情報を詰め込む
わかりやすい名前
これを意識するだけで可読性が全然違ってきます。
ポイントは
・明確
・汎用的な名前は避ける
・長さ
・フォーマット
だと思います。
コメントすべきことを知る
コードから読み取れないことをコメントに書く
Howはコードから読み取れるため、Whyを書きなさい、とよく言われているあれです。
むやみ、やたらにコメントしないこともコツ。最低限のコメントで管理することと、
コメントのアップデート
忘れがちですが、必ずしないとあとで悲惨な目にあいます。
コメントは正確で簡潔に
書くなら意味のあることを残しましょう
制御フローを読みやすくする
条件式を複雑にして行数を減らすより、**「自然」**に理解できるように書くことが大事
そして、ネストは浅くね。
巨大な式を分割する
複数の条件式をくっつけすぎない
スムーズに理解できる程度におさめましょう。
変数の読みやすさ
使う直前に宣言すること。
そして、スコープ（参照される範囲）をできるだけ短くすることです。
結局そんな前に宣言された変数なんて覚えてないし、いちいち戻って確認に時間かかるから。
これは意識する基本原則で、例外の場合もあるため囚われ過ぎちゃだめ。
あと、変数の使い回しも基本的にはNG
コードに思いを込める
短いコードを書く
メソッド内の行数を減らす
そもそも、単一原則を意識したらそもそも行数はそこまで増えないはず。
SOLID
オブジェクト指向設計に関する原則の頭文字をとって「SOLID」とまとめられた原則集。
Single Responsibility Principle（単一責務の原則） 「クラスを変更する理由は１つでなければならない」
https://qiita.com/hirokidaichi/items/d6c473d8011bd9330e63
また、コメントアウトしてコードを残す派とコードを消す派の議論は絶えませんが、
個人的には、不必要なコメントアウトは消していいと思います。
いつまで残してても混乱させるだけです。
誤解されない名前
誤解されない名前をつける
もし、いい名前が思いつかないときはコメントで補足すればいいと思います。
また、接頭辞や接尾辞でそれが何を表しているか、工夫するといいです。
テストと読みやすさ
エラーメッセージを工夫しましょう
テストを前提にして、コードを設計すること。
美しさ
コードに一貫性をもたせる
知っているパターンが出てくるだけで、流れやこれからのロジックが予測できます。
それはつまり、理解のスピードが全然違ってきます。
形が似ているのに構造が違うコードを書いてはいけません。混乱します。
一度に一つのことを
所謂、単一原則です。
複数担ってきたら他に委譲しましょう。
無関係の下位問題を抽出する
改良が入ることを踏まえて設計すること
急に仕様変更や細かい変更がくることはざらです。（ほんとにもう、、ね）
基本的にはYAGNIですが、柔軟にしておくことです。
YAGNI
"You ain't gonna need it"縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。
https://ja.wikipedia.org/wiki/YAGNI
解説（まとめ）
いつ誰が見てもわかりやすいコードを書くことを意識すること。
そしてそれを実践すること、継続すること、それを当たり前にしていくこと
これらを習慣化することで、読みやすいを当たり前にしていくようにしていくことを説いています。