IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20210810/20210810103304.png
リーダブルコード 第1部を読みました
名著と名高い、リーダブルコードの第1部を読み終えたので気になった部分をまとめてみました✍️
https://www.amazon.co.jp/dp/4873115655/ref=cm_sw_em_r_mt_dp_CKCCTS6RS380FVEWK26K
プログラミングの時間のほとんどはコードを読む時間
プログラミングの時間のほとんどはコードを読む時間なのだっ！— p.43
第1部では「表面上の改善」と題して、名前やコメントのあるべき姿を述べています。
本書全体を通して、「理解しやすい」コードを書くためのTipsが散りばめられていますが、なぜ理解しやすいコードが必要なのでしょうか。
本文の中にもいろいろと書いてあるのですが、個人的に一番ビビッと来たのは冒頭に引用した言葉です。
SIerで初めてJavaを触った時、プロダクトのコードが全く理解できなくて、既存のコードをずーっと読み続けている時期がありました。読んでいくと次第に法則性がわかるようになってきて、法則性がわかると自分でも書けるようになっていきました。これが私がプログラミングの面白さに触れた原体験の部分であるため、「読む」という部分には強く共感しました。
コードは読むもの→求められるのは論理性・国語力
プログラミングというと、どうしても「このメソッドを使うとより短く書ける」「この記法を使うと$1で書ける」といった部分を想起しがちですが、本書第1部で述べられているのはそういった$1なところではなく、もっと$1的な、教科で言えば「国語」的なアプローチです。
例えば「3章 誤解されない名前」には次のような一節があります。
名前が「他の意味と間違えられることはないだろうか」と何度も自問自答する— p.30
本書では、filter メソッド名は抽出結果が曖昧である（取り除く対象なのか、取り除かれたものなのか）という例があげられています。
この問い、つまり「他の意味と間違えられることはないだろうか」について、もう少しどういう考え方が必要か自分なりに考えてみると、「そのメソッドのインプットとアウトプットが、メソッド名で正しく紐づくか」という観点が重要なのではと思いました。
A→(method)の結果がBに特定できるのであればいいけれど、B以外のCが検討できたり、そもそもBに紐づかないことはNG。A→（method）→Bとなるように因果関係を正しく構築できているかを確認することで、わかりやすいメソッドにできるのではないでしょうか。
これはちょうど学生時代に国語の問題で因果関係が正しくなるように線で結ぶ問題と同じようなものです。プログラミングは論理的思考が求められるといいますが、それはプログラムの流れだけではなくて、名前にも適用されるのかもな〜なんて考えました🤔
情報密度の高い言葉を使う
一応コンサルみたいなことやっているので、日常的にカタカナ言葉にさらされているのですが、基本的によく意味を理解せず横文字を連発する人は嫌いです。
それはさておき、英単語と日本語では厳密なイコールにならないため、英語一単語で複数の日本語を言い表せることもあります。概念的な言葉であれば尚のことです。
本書ではコメントを圧縮して見やすいものにするために、これらを使うことを提案しています。
- どこまでが一般認知とされているか
- 対応する単語はどれか、別の捉え方にならないか
といった部分を考慮しないといけないので、簡単そうに見えて意外と難しそうなテクニックです。
これも言葉の言い換えスキルなので、国語力が求められるといっていいのかなと感じました。
おわりに
プログラミングといえば、$1や$1力などが重要なイメージですが、本書 第1部ではそれよりも論理力・国語力が重要である印象を受けました。
私は文系かつ就職してからプログラミングに出会った人間なので、いわゆるプログラミング的な素養は乏しいですが、これまで経済・経営（社会科学）に向き合うことで培ってきた姿勢を生かして、リーダブルなコードを書けるように精進していきたいと思います。
