エンジニアの間で名著として知られる「リーダブルコード」ですが、大学生のころ、長期インターンでエンジニアしていた時に上司に進められて最初に読んだのが始まりです。
あの頃は、まだエンジニアなり立てで、読んでも全然理解できませんでしたが、やはり二回目ということもあって、あの頃と違う理解ができるようになりました！
日頃、業務をしていて「自分って成長しているのかな～」と思いますが、本を再読するとそれが実感できますね！！！
目次
リーダブルコードってなに？？
それでは、リーダブルコードを読んだことがない人のために、前置きから。
リーダブルコードとは、エンジニアの人なら読んだことないって人がいないぐらい有名な本で、技術的な話が中心ではなく、コードを読みやすくするためのコツがメインの本です！
基本的に、技術本ってこれはこうやるとかこういう書き方があるとか、そういう内容が多いと思うんですが、コードを読みやすくする本なんて中々みないですよね（笑）だから、名著として有名なのかもしれません。
少しだけ内容を紹介
第2章 名前に情報を詰め込む
明確な単語を選ぶ。
→例えば、Getではなく、状況に応じてFetchやDownloadなどを使う。
tmpやretvalなどの汎用的な名前を避ける。
→ただし、明確な理由があれば話は別だ。
具体的な名前を使って、物事を詳細に説明する。
→ServerCanStart()よりもCanListenOnPort()の方が明確だ。
変数名に大切な情報を追加する。
→ミリ秒を表す変数名には、後ろに_msをつける。これからエスケープが必要な変数名には、前にraw_をつける。
スコープの大きな変数には長い名前をつける。
→スコープが数画面に及ぶ変数に1~2文字の短い暗号めいた名前をつけてはいけない。短い名前はスコープが数行の変数につけるべきだ。
大文字やアンダースコアなどに意味を含める。
→例えば、クラスのメンバー変数にアンダースコアをつけて、ローカル変数と区別する。
第3章 誤解されない名前
君のコードを読んでいる人が、君の意図を正しく理解できるようにすること
→名前を決める前に反対意見を考えるなどして、誤解されない名前かどうかを想像してみよう。
第4章 美しさ
優れたソースコードは「目に優しい」ものでなければならない
- 読み手が慣れているパターンと一貫性のあるレイアウトを使う。
- 似ているコードは似ているように見せる。
- 関連するコードをまとめてブロックにする。
優れたコード>ひどいコード+優れたコメント
読み手の立場になって考える
→プロジェクトに誰が参加しても問題にならないようにする
ライターズブロックを乗り越える
→「やばい、これはリストに重複があったら面倒なことになる」と思った瞬間にそれをコメントとして記載しておく
第12章 コードに思いを込める
コードは簡単なことがで書くべき
- コードの動作を簡単な言葉で同僚にもわかるように説明する
- その説明のなかで使っているキーワードやフレーズに注目する
- その説明に合わせてコードを書く
第13章 短いコードを書く
最も読みやすいコードは、何も書かれていないコードだ。
- 不必要な機能をプロダクトから削除する。過剰な機能は持たせない。
- 最も簡単に問題を解決できるような要求を考える。
- 定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく。
再読後の感想は・・・
最近は本をあまり読んでいなかったので、途中で飽きないかな～と思ったのですが、1時間ぐらいで読み終わってしまいました・・・（笑）
内容が濃く、「あー確かにいまだったらこれが理解できる」「今開発中のコード直せそうだな」と思いながら読み進められたので、楽しく読めました！！
まだエンジニアなり立ての方も、熟練のエンジニアの方も、まだ読んだことがない人がいれば、ぜひ読んでみてほしいです！！
amazonの評価もめちゃ高いので、他の方がどんな評価しているかも見てみるといいかもしれません。
ではまた。
