第三者のための『リーダブルコード』

新人エンジニアにオススメの本のひとつだよねー、などと言いつつ自身は読んだことがなかったので慌てて買って読んだ。

お題「リーダブルコード」

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

なるほど当たり前のようなことでありながら短期的に意識して身につけるのは難しかったことばかりで、これがこのようにまとまった形の書籍になっていることはとてもありがたいことだと思う。規約を押しつけてるわけじゃなくて指針の集合なので、気楽さもある。

プログラム中で使用する英語動詞

本の中には「名前に情報を込める」という話があった。

非英語話者でありながらプログラミングに英語を使っている身としては、今ひとつニュアンスが分からない語がある一方、却って巷のソースコードから英語の利用例を知る割合が高くなるわけで、そうやって英語のプログラミング向けのサブセットを作ることもできそうだなと思う。

そこで現在こんな動詞をこういうニュアンスで使っていますよ、というのを雑に列挙してみる。語彙は使用するプログラミング言語やその著名なライブラリの語彙にかなり影響を受けるので、普遍的なものにはなり得ない。

英語	用途	備考
search	データベースなどからの複数のデータを取得する。	なんで select じゃないのかは不思議
find	データベースなどから条件にしたがってデータをひとつ取得する。
insert	データベースへデータを挿入する。	SQLからの連想
delete	データベースからデータを削除する。	SQLからの連想。データ構造からのデータの削除にも使う
update	データベースのデータを更新する。	SQLからの連想
load	外部リソースをメモリ上のモデルへ展開する。	load したものは save する
new	（これは動詞ではないが）インスタンスを生成する。	言語の機能になってることが多い
make	データ構造を作成する。
generate	IOをともなわずに値を生成する。
fetch	HTTPなど比較的重いIOによってデータを取得する。
request	HTTPリクエストを送信する。
require	データ構造のある部分を要求する。存在しなかったら例外を投げる。
ensure	データ構造のある部分が存在しなければ作成する。

addとかremoveとかもっといろいろあるやん……と思ったけどキリがないのでやめておく。

これらは低レイヤの処理として使われたときにこういう名前を使いますという類のもので、より抽象度の高いレイヤにおいてはもっと自由に名づけられると思う。こうやって読んでみるとどんなリソースにアクセスするのか、を意識してるな。

ちなみに自分は ensure を上記のように考えていたんだけど、require のように使う、という意見もあった。たしかにプログラムの次の行に到達したときに、求める状況になっていることを確実にできるという点では同じであるなあと思う。

コメント中の意見に署名する

TODOなんて書かれたコメントは放置されるものだ。というか、放置されたものだけが生き残るわけなので、他人に見られるのは放置されたものばかりになるのだといえる。そして生まれてすぐの早いうちに誰も対処しなかったTODOは、やがて消して良いのかどうかの判断もできなくなってコード中の定位置を確保する。

そこで最近はTODOやらFIXMEといったコメントを書くとき、# TODO(motemen): 処理を切り出す というように、自分の名前を入れるようになった。これはGoを書いているうちに知ったものだけど、まあ源流がどこかにあるんだろう。この署名を加えることで、例えば手を付けられないままそのTODOが生き残り誰かの目に触れたとしても、ははあこれはあいつに訊けばよいのだなとなって、まったく判断できないということは避けられる。その他同様に、コメントにコードを補足する事実でなく意見を書くときには、誰が書いたかを明らかにする。

プロジェクトによっては人名だけでは足りないとして、詳しい情報をつけ加えるようにしているところもある模様。

ソースコードの第三者

……というようなことを考えながら読んだ。その他にもコードの役割を細かく、とか制御構造を読みやすく、という話題があったけど、それらはコードに向き合っているうちに自ずと実現されるように思う。

10年前の自分は知らなかったことだけど、プログラミングにおいてコードを書く際には、書き手の自分とそれを受けとるコンピュータのほかに、第三者としてソースコードの読み手が存在する。昔の自分も当然その存在を知ってはいたものの、ちゃんと認識できてはいなかった。プログラマは読み手として多くの時間を過ごすものだと気づけたのは、実際にそれだけの時間を費やしてからだった。いや、それよりも自分が過去に書いたコードを他人に読まれるようになったからかな……。

人間が書いたプログラムの意味（何をするべきか）をコンピュータは解釈して間違いなく書かれたとおりに実行するけれど、ソースコードがそのまま人間の意図（何をしたいか）や書かれた文脈（何故そうするのか）を表現しているとは限らない。最悪、意図と意味が異なっていることだってある。第三者がコードを読むとき、コンピュータのために書かれた意味から意図を取りだすことは簡単だとは限らない。書き手のほうはもちろん意図を実現するものとしてコードを書いているから、この差に気がつかないと、後から読んだときに読み手が困るようなコードが出来上がることになりがち。

もちろん、デザインパターンとか、名前のついたアルゴリズム、フレームワークなど人間のあいだの共通言語を強化することでソースコードの意図を分かりやすくすることはできる。また、抽象度を高めることで、書かれたコードと意図とのあいだの距離を縮めようとするって手もある。その場合も抽象化を受け持つ層のことが人びとによく共有されていないと結局動きを把握するためにコードを潜るはめになって、却って苦労が増すことになる。このあたりは業界の潮流とかプログラミングのパラダイムにも大きく影響を受けそうなところ。

---

なんか、若い人のほうがこういうところきっちりできる印象なので（冒頭に書いた言葉とはうらはらに）、むしろ自分の身につまされる本だった。プログラムって人間とコンピュータのあいだの言葉であるのと同じくらい、人間と人間のあいだの言葉でもあるなと思った。

この記事は次の酒を飲んでいる最中に書かれました：

キリン ザ サシングルトン グレンオード 12年 40度 700ml