数年ぶりに「リーダブルコード」を読むとやっぱりイイ

はじめに

数年ぶりにエンジニアなら読むべきと言われている「リーダブルコード」を読みました。
前に読んだのは少なくとも学生のときなので、がっつり仕事をやり始めてからは初めて読みました。

バイブルと呼ばれている通り、「エンジニア 読むべき」でググると上位10件中7件で、★5だったりオススメ1位だったりでリーダブルコードが紹介されていました。

リーダブルコード

概要

副題にもあるように、より良いコードを書くために必要なことが載っています。
命名、コメント、変数や関数、テストなどについて、章立てされていて、それぞれが独立しているので掻い摘んで読んでも構わないような構成になっています。*1

感想

学生当時は「ふーん」という感じで読んでいたイメージがあります。
が、改めて読んでみるとやはりイイなと感じました。

良いコードは何かと言われれば難しいですが、読みやすいコードは何かと言われればリーダブルコードに沿ったコードと答えても問題なさそうです。
実際、副題には「より良いコードを書くための」となっていますが、はじめにの章では「本書の目的は、読みやすいコードを書くことである。」という一節があります。
そして、その次で述べられている以下のような内容が、本書の全てを体現している気がします。

読みやすいコードを書く → コードは理解しやすいものであるべき → コードを読んで理解する時間を最短にする

良いコードの定義は難しいですが、今後は読んで理解する時間が最短であるようなコードの書き方を目指したいと思います。

特筆すべき感想はあまり無いのですが、命名やコメントに関しては、基本的にそのとおりだと思うことばかりでした。
やはりコーディングする人全員に読んでもらって共通言語として意思統一が図れれば最高だなという思いです。

疑問

そんな中、今になっていくつか疑問も出てきました。

1つ目は、「4章 美しさ」で紹介されている視覚的な手すりのためのコードの整列です。
例えば、以下のようなものです。

details  = request.POST.get('details')
location = request.POST.get('location')
phone    = request.POST.get('phone')
email    = request.POST.get('email')
url      = request.POST.get('url')

個人的には、これは嫌いで、本文にもあるように「差分」が増えるからです。
上記ならまだしも、以下はもっと嫌いです。

checkFullName("Doug Adams"  , "Mr. Douglas Adams" , "");
checkFullName(" Jake Brown ", "Mr. Jake Brown III", "");
checkFullName("No Such Guy" , ""                  , "no match found");
checkFullName("John"        , ""                  , "more than one result");

ここまでやる必要があるのか?と思ってしまいます。
嫌いな理由として、ずっとPythonをやっていて、PythonではPEP8で悪い例としてあげられていて悪いものだという認識が強いからかもしれません。
もちろん、見やすくなる場合もあるので、コードを書く人にはせめてコミットをわけてほしいと思う次第です。

2つ目は、「14章 テストと読みやすさ」で紹介されている独自のミニ言語を実装するという点です。
確かにある程度はメソッド分割して、場合によっては独自のミニ言語のようなものを作り読みやすくすることも必要だと思います。
ですが、ミニ言語レベルのロジックがテストコードに入ってしまうと、テストコードのためのテストが欲しくなってしまいます。
極論、独自のassertを定義し、その中で常にtrueになるようなassertの呼び出し方をしてしまうと、テストコードの意味がなくなります。
命名やコメントに関してもそうですが、「良い塩梅」というのが大切なのでしょうか。

おわりに

疑問もあげましたが、バイブルと呼ばれるだけあって今でも勉強になる部分は多々ありました。
共通言語として使っていきたいので、みんなに読んでほしいです。

2週連続で本の話になってしまいました...

*1:「本書の読み方」参照