「リーダブルコード」を読んだ感想 🎷

はじめに 👋

この記事は、個人的な学習の記録です。

https://amzn.asia/d/1kOQxW0

得た知識一覧　 🍣

✅ 良い名前とは
✅ 美しさの定義
✅ コメントすべき内容の基準
✅ なぜ三項演算子は、否定されがちなのか　 👈 これ一番疑問に思っていたこと
✅ コードを書く上での細かな「なぜ？」の解消

まとめ　 🍵

まず、今回この本で一番記憶に残ったのは、以下３箇所

🔹① 三項演算子を IF で書いた方がいい場合の解説　（P88）

まず、前提として

「行数を短くするよりも、他の人が理解するのにかかる時間を短くする。」

という考えを持った上で読み手にとって一番良いコードとは何かと考えた時

三項演算子が簡潔で読み易い例

if (hour >= 12 ) {
   time_str = "pm"
} else {
   time_str = "am"
}

↓

// hour が 12 以上なら "pm" を、そうでなければ "am" を
// time_str の末尾に足して代入する
time_str += (hour >= 12) ? "pm" : "am";

となり簡潔ではある。

しかし、デバッカーでステップ実行しにくいみたいな見方もあったりもするので賛否両論ではある。

特に三項演算子ではなく、IF 文で書いた方がいい例を挙げると以下のようなコードがある

// exponent が 0 以上なら mantissa を 2^exponent 倍にする
// exponent が負なら mantissa を 2^|exponent| で割る
// return=mantissa×2exponent ←式的には、これ
return exponent >= 0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);

↓

if (exponent >= 0) {
  return mantissa * (1 << exponent);
} else {
  return mantissa * (1 << -exponent);
}

補足：
exponent = 指数
mantissa = 仮数　（例：0.423 = 4.23 × 10⁻¹ の 4.23 が仮数で、-1 が指数）

♦️② 美しさ (P42)

▪️ 読み手が慣れているパターンと一貫性のあるレイアウトを使う。
▪️ 似ているコードは、似ているように見せる。
▪️ 関連するコードをまとめてブロックにする。
▪️「見た目が美しいコードの方が使いやすいのは、明らかだ。」
▪️「考えてみれば、プログラミングの時間のほとんどはコードの読む時間なのだ！」
というのが面白かった。

🔹③ 短いコードを書く(P168)

・「最も読み易いコードは、何も書かれていないコードだ」
・「プログラマが学ぶべき最も大切な技能というのは、コードを書かないときを知ることなのかもしれない」
・「その機能の実装について悩まないでーーーきっと必要ないから」
など、よく聞くやつが書いてあった
要は、本当に必要なことを把握して、いかに本当に必要な機能のみに絞り実装するかというのが重要というわけだ。

以上 3 点が特に学びになったとは、感じる。

その他で学びとなったものといえば ❓

✅P91：関数は、早く返す　 ← 急に筆者の口が悪くなる
✅P93：ネストを浅くする　
✅P158：「おばあちゃんがわかるように説明できなければ、本当に理解したとは言えない。」 -アルバート・アインシュタイン-
✅P175： 冒険、興奮、ジェダイは、そんなもの求めておらん。 -ヨーダ-
・最も簡単に問題を解決できるような要求を考える。
・不必要な機能をプロダクトから削除する。過剰な機能は、持たせない。
・定期的に全ての API を読んで、標準ライブラリに慣れ親しんでおく。
✅P9：名前に情報を詰め込む
✅P115：グローバル変数を避ける
✅P89：行数を短くするよりも、他の人が理解するのにかかる時間を短くする
✅P70：コメントすべきことを知る
読み手の立場になって考える
・コードを読んだ人が「えっ？」と思うところを予想してコメントをつける
・屁金的な読み手が驚くような動作は、文章化しておく
・ファイルやクラスには、「全体像」のコメントを書く
・読み手が細部にとらわれないように、コードブロックにコメントをつけて概要をまとめる
✅P56：鍵となる考え
・コメントの目的は、書き手の意図を読み手に知らせることである
・コメントすべきでは「ない」ことを知る
・コードを書いている時の自分の考えを記録する
・読み手の立場に立ってなにが必要になるかを考える
・コメントすべきではないことととして、「コードからすぐ読み取れることは、コメントに書かない」
✅P115：「グローバル変数は避ける」とかいうかの有名なアドバイスも紹介されていた
まぁそりゃプログラム全体からアクセスできる変数使ってその変数をどこからでも書き変えられるとしたらバグの原因追いずらいってのは、あるが決まりきった定数などを変数に格納して使い回すとかなら便利と言えば、便利か
まぁしかし、できる限り、見える範囲で管理した方がコードで的には読み易いので基本使わない方がいいというのは理解できる。

感想　 🌤️

本書を読んで感じたこととしては、結局「読み手にとって読みやすい」というのが良いコードというごくごく当たり前で少し考えればすぐわかるようなことではあるが最も重要なことでもあるというかなり基本的な内容だと感じた。

しかし、その概念は理解できていたとしてもそもそも「読み手にとって読みやすい」とは、なんだろうか？
また、その「読み易い」を実現するにはどうすれば良いか？、を具体的な例を交えて解説してくれていて読まないより読んでおいた方がいいという内容だとは感じた。

まさに、プログラマにとっての北極星的なものだと感じた。

特に、よく言われる「三項演算子を使うな」みたいなアドバイスがどういう場合において適切なのかや、「名前とは、短いコメントのようなものだ。」など、よく聞くことではあるが本書では、その「なぜ？」が書かれていたので良かった。

だが、読み進めている内に、そもそもなんで「読み易い」というのが正義とされているかと疑問に感じることがあったのだが、本書では、その答えが書かれていて、そもそも「プログラミングの時間のほとんどはコードを読む時間なのだ！」という言葉、これでかなり腑に落ちた。

というわけで、一応読み終えたわけだが、ところどころまだ出会ったことのない事象や課題について書かれていたりすることが多かったので理解するのに時間がかかったが読まないより読んでおいた方がいいと言える本ではあったのは確かなので、次は、本書に書いてあるような事象に出会した時、再度部分的に読み直そうと思う。

その時に、本書の本領が発揮されるだろうと感じる。

情報の豆粒 ☕️

🫘 ハンガリアン記法とかいう(P21)変数の前に接頭語としてのその変数の方を頭文字だけ書くやり方とかあるらしい