『リーダブルコード』を言語教師が読み解いてみた

## はじめに
　勤務校は、外国人エンジニアを育成するというコンセプトで運営している日本語学校ですが、授業の一環として、[**『リーダブルコード』**](https://www.oreilly.co.jp/books/9784873115658/)を半年かけて、学生たちと一緒に輪読しました。『リーダブルコード』の副題には、**「より良いコードを書くためのシンプルで実践的なテクニック」** と書かれており、「プログラマ」のための実用書という位置付けです。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286949/1bc45139-7d35-e965-9f6a-e2ed3c7379a1.png" width=30%>

　しかし、このプログラマのためのバイブル『リーダブルコード』
　言語教師が読んでも、非常に深い内容だったので、今回は、あえて「言語教師」視点で、本書を読み解いてみたいと思います。（ちなみに私は「コード」は書けません）


　まず、前提として、私が考える「言語感」について触れておきたいと思います。（「言語」という表現が「プログラミング言語」「自然言語」のどちらなのかわかりにくいため、ここでは、「自然言語」を指す用語として「ことば」を使います）

　**「ことば」**には、いろいろな役割があります。「コミュニケーションの手段」としてだけでなく、「表現する」「記録する」などにおいても「ことば」を使います。このような「ことば」の役割の中でも、私は特に**「思考する」**という役割を大切に考えています。なぜなら「コミュニケーション」や「表現」「記録」などは、「ことば」でなくても、絵や図式、パフォーマンス、写真、映像などで代替することもできます。しかし、**「思考する」**ことは、「ことば」以外の手段で代替することができないと考えるからです。この点が、私が『リーダブルコード』に惹きつけられた理由の一つになるので、回りくどいと思いましたが、はじめに説明してみました。

　ということで、早速、『リーダブルコード』を読み解いていきたいと思います。


## 「コード」は思考のプロセスを記述したもの
　私が『リーダブルコード』に非常に興味を持ったのは、プログラマが書く「コード」は、実は、**プログラマの思考のプロセスを記述したもの**ではないかと感じたからです。

　『リーダブルコード』は、日本語だと「読みやすいコード」という意味になりますが、「読みやすさ」とはなんでしょうか。『リーダブルコード』では、「読みやすさの基本定理」として、

> コードは他の人が短時間で理解できるように書かなければいけない

とあります。そして、「理解しやすいコードとは何か」について徹底的に解説をしていきます。この「理解しやすさ」の解説が、本当におもしろい。自然言語に通じる部分がたくさんあります。
　
　普通、**「思考する」**というと、思考する本人が一人で行うというイメージがあります。しかし、プログラマが「思考する」とき、そこには、常に「コンピュータ」の存在があります。つまり、プログラマの「思考」は、一人で行うのではなく、**「コンピュータ」と対話しながら「思考」している**のだと捉えています。その際、「コンピュータ」が「理解できる」言語を書かなければならないというのが大前提となります。
（ちなみに「ことば」による思考も、思考する本人だけではできないと私は考えています）
　
　しかし、『リーダブルコード』でいう「理解しやすさ」の対象は、「コンピュータ」ではありません。**コードを書いた本人以外の「人」が理解できるコード**を目指します。（数ヶ月後の自分である場合も想定しているようですが）「思考のプロセスを他者が理解しやすいように記録する」これは、考えただけでも、結構ハードルが高そうです。


## 「思考」の結果を理解しやすく表現する
『リーダブルコード』では、まず、「表面上の改善」を提案しています。「表面上」というのは、「思考」の結果を記述したものになるのではないかと思います。「表面上の改善」では、以下のような項目が上がっています。

- 2章　名前に情報を詰め込む
- 3章　誤解されない名前
- 4章　美しさ
- 5章　コメントすべきことを知る
- 6章　コメントは正確で簡潔に

これらは、簡単に3つのカテゴリーに分けることができると思います。**「名前の付け方」「見た目の美しさ」「コメントの書き方」**です。

### 名前の付け方
　まず、「名前の付け方」です。コードを書くとき、「関数」や「変数」には、自分で名前をつけなければなりません。この「名前をつける」という行為を、私は**「語彙を選ぶ」**と変換して読みました。

　**「語彙を選ぶ」**とき何よりも気をつけなければならないのは、**誤解をできる限り少なくする**ことです。対コンピュータであれば、どんな名前でも宣言してしまえば、問題ないのかもしれませんが、読み手を「人」と想定したとき、当然、「人が理解できるもの」である必要性が出てきます。そうなると、これは、「ことば」と同じ発想になります。
　『リーダブルコード』では、次のような注意点が説明されています。（p.10）

- 明確な単語を選ぶ
- 汎用的な名前を避ける
- 抽象的な名前よりも具体的な名前を使う
- 接尾辞や接頭辞を使って大切な情報を追加する
- 名前の長さを決める
- 名前のフォーマットで情報を伝える

「ことば」による対人のコミュニケーションで議論が噛み合わないときというのは、大抵上記のルールが引っかかっていることが多いです。例えば、「教育」「デザイン」「AI」など、抽象的な「ことば」ほど、各々がイメージするものが異なります。各々が持つイメージだけを前提に話をしていると、だいたい議論は噛み合いません。そんなとき、**自分が使った語彙から、相手が何を思い描いているのかを想像する**ことが必要です。コードで名前をつけるときも同じことが言えそうです。
　自分がつけた名前から読み手が何を想像するのか、どのように理解するのかを考えようという姿勢が貫かれ、具体的に解説がされています。「名前」大切です。


### 見た目の美しさ
「人が読むためのもの」と考えると、見た目の美しさも重要です。
　これは、「ことば」でも同じことが言えると思います。手書きで文字を書くことはすっかり少なくなりましたが、美しい文字で書かれている手紙は、やはり心が躍ります。手書きでない場合も、フォントやインデント、行間など、一貫性があると読みやすくなります。句読点の打ち方や改行の仕方、さらに、一文の長さなど、「ことば」の教育では、このへんの「見た目の美しさ」については、軽視されがちですが、やはり、読み手を考えると、「見た目」大切です。
（と言いつつ、文字ばかりの記事ですみません）

### コメントの書き方
　読書会で「コメント」の話題になったとき、学生にコメントを書くかどうか聞いてみたのですが、積極的にコメントを書くという人は少なかったです。しかし、「コードは思考のプロセスを記述したもの」と考えると、コメントはとても大切なんじゃないかと思えてきます。
　では、どんなコメントを書けばいいのでしょうか？
　6章に記載されているアイデアは、「シンプルでわかりやすい文章」の書き方そのものです。その一部を抜き出します。

- 6.1 コメントを簡潔にしておく
- 6.2 あいまいな代名詞を避ける
- 6.3 歯切れの悪い文章を磨く
- 6.8 情報密度の高い言葉を使う

これ、そのまま文章講座ですね。

ここでも、「読み手」の立場に立ったコメントの書き方が「鍵」となります。大まかにまとめると以下のようになります。

- なぜコードが他のやり方でなくこうなっているのか、自分の考えを記録する
- コードを読んだ人が「えっ？」と思うところを予想してコメントをつける
- （細部しか読む機会がないであろう読み手を想定して）「全体像」がわかるコメントを書く
- 読み手が細部に捕らわれないように、コードブロックにコメントをつけて概要をまとめる

最後の「概要をまとめる」は「小見出し」をつける作業と同じですね。

さらに、書くのが苦手という人に対して、次のような節もあります。

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

ここでは、コメントを書く手順を、具体的に説明しています。

- 頭のなかにあるコメントをとにかく書き出す。
- コメントを読んで（どちらかと言えば）改善が必要なものを見つける
- 改善する

　これが「コード」の書き方の本なのか、とびっくりします。これらの解説をまとめると、良いコメントとは、**「余計な情報がなく、なおかつ必要十分な情報が記述された文章」**ということになります。そして、このようなコメントを書くときに大切な姿勢は、**「読み手」を意識すること**と言えそうです。

　学校教育で行われる「作文教育」って、「表現する」ことに重きが置かれ、「読み手」を意識した教育というのは、軽視されがちです。しかし、本書で書かれているように、常に「読み手」を意識することによって、コードだけでなく、「語彙の選び方」「見た目の美しさ」「シンプルでわかりやすい文章」といった「ことば」のセンスも磨かれていくのではないかと思います。

と、ここまでが、第1部です。

## 「思考」のプロセスを理解しやすく記述する
　第2部からは、「思考の方法」＝「頭の中身」の話になります。

　実を言うと、この後は、具体的なコードの書き方の話になるため、私には、よく理解できません。ただ、第1部から通じている「鍵」となる考え方は、「読み手を意識してコードを書く」。この1点です。
そして、第2部全体を通して言えるのは、**「思考のプロセスを読み手が追体験できるようにしよう」**なのではないかと思います。

　そのためには、一度に思考する範囲を細かく分け、一つのブロックで一つの思考というように、思考のプロセスを分割して記述することを、様々な観点から解説している、と私は読み取りました。
（本当に、ザックリですみません）


## まとめ
　いろいろ書いてきましたが、『リーダブルコード』を読んで、私が考えたことを簡単にまとめると以下のようになります。

- コードは、プログラマの思考のプロセスを記述したもの
- 常に「読み手」を意識しながらコードを書く
- 「思考の結果」を記述するときには、名前の付け方、見た目、コメントに留意する
- 「思考のプロセス」を記述するときには、一度に思考する範囲を細かく分けて記述する
- 「読み手」が「思考のプロセス」を追体験できるようにする

「コード」を、文章、作文、論文と置き換えることもできそうです。


## おわりに
　私は、思いっきり文系脳の人間なので、これまで「コードを書く」という行為が、自分には理解できない別世界のことのように感じていました。Qiitaの投稿を読んでも、思考のプロセスが理路整然と説明されていて、「理系人間、なんかすごいなー」と思っていました。文章を書きながら思考するタイプの文系人間から見ると、どうやったらこんなふうに論理的に説明できるのかと、とっても不思議だったのです。
　しかし、『リーダブルコード』を、プログラマと一緒に読みながら、ものすごく親しみを覚えました。今は「書きながら思考する」という点において、プログラマも同じことをしているのではないかと思っています。

　最後までお読みいただき、ありがとうございました！