「リーダブルコード」を再読してみた

エンジニアの間で名著として知られる「リーダブルコード」ですが、大学生のころ、長期インターンでエンジニアしていた時に上司に進められて最初に読んだのが始まりです。

あの頃は、まだエンジニアなり立てで、読んでも全然理解できませんでしたが、やはり二回目ということもあって、あの頃と違う理解ができるようになりました！

日頃、業務をしていて「自分って成長しているのかな～」と思いますが、本を再読するとそれが実感できますね！！！

リーダブルコードってなに？？

それでは、リーダブルコードを読んだことがない人のために、前置きから。

リーダブルコードとは、エンジニアの人なら読んだことないって人がいないぐらい有名な本で、技術的な話が中心ではなく、コードを読みやすくするためのコツがメインの本です！

基本的に、技術本ってこれはこうやるとかこういう書き方があるとか、そういう内容が多いと思うんですが、コードを読みやすくする本なんて中々みないですよね（笑）だから、名著として有名なのかもしれません。

明確な単語を選ぶ。

→例えば、Getではなく、状況に応じてFetchやDownloadなどを使う。

tmpやretvalなどの汎用的な名前を避ける。

→ただし、明確な理由があれば話は別だ。

具体的な名前を使って、物事を詳細に説明する。

→ServerCanStart()よりもCanListenOnPort()の方が明確だ。

変数名に大切な情報を追加する。

→ミリ秒を表す変数名には、後ろに_msをつける。これからエスケープが必要な変数名には、前にraw_をつける。

スコープの大きな変数には長い名前をつける。

→スコープが数画面に及ぶ変数に1~2文字の短い暗号めいた名前をつけてはいけない。短い名前はスコープが数行の変数につけるべきだ。

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

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

君のコードを読んでいる人が、君の意図を正しく理解できるようにすること

→名前を決める前に反対意見を考えるなどして、誤解されない名前かどうかを想像してみよう。

優れたソースコードは「目に優しい」ものでなければならない

優れたコード>ひどいコード+優れたコメント

読み手の立場になって考える

→プロジェクトに誰が参加しても問題にならないようにする

ライターズブロックを乗り越える

→「やばい、これはリストに重複があったら面倒なことになる」と思った瞬間にそれをコメントとして記載しておく

コードは簡単なことがで書くべき

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

最近は本をあまり読んでいなかったので、途中で飽きないかな～と思ったのですが、1時間ぐらいで読み終わってしまいました・・・（笑）

内容が濃く、「あー確かにいまだったらこれが理解できる」「今開発中のコード直せそうだな」と思いながら読み進められたので、楽しく読めました！！

まだエンジニアなり立ての方も、熟練のエンジニアの方も、まだ読んだことがない人がいれば、ぜひ読んでみてほしいです！！

amazonの評価もめちゃ高いので、他の方がどんな評価しているかも見てみるといいかもしれません。

ではまた。