この記事を読むのに必要な時間:およそ 1 分
はじめに
「プログラミングに関する雑多な事柄」がテーマの本連載,第5回の今回はソースコードを読むこと,「コードリーディング」について取り上げたいと思います。
なぜコードリーディング?
他人のコードを読む場面には,いくつかのパターンがあると考えられます。
- チームで開発しているときに,ほかのメンバーが書いたコードをレビューしたり,理解するために読む
- ライブラリの動作のしくみや設計などのテクニックを勉強するために読む
- 「こういう処理をするにはどうすれば良いんだろう?」と参考にするために,類似のプロジェクトのコードを読む
- オープンソースのライブラリを使おうと思ったらドキュメントがないのでソースコードを読む
- オープンソースのプログラムを使っていたらバグっていたのでデバッグのためにコードを読む
上の3つは,コードを読んで理解しよう,勉強しよう,参考にしようといった,積極的なコードリーディングであるのに対し,下の2つは,どちらかというとしかたなしに,という消極的なコードリーディングと言えそうです。個人的には下の2つのような場面を「強制コードリーディングモード」と呼んでいます。
コードリーディングのメリット
コードリーディングには,さまざまなメリットがあります。
優れたコードからテクニックやベストプラクティスを学ぶ
これは代表的なメリットです。たとえば,ある種のお約束的な事柄はほかのプロジェクトを真似するのが一番の早道です。PerlモジュールのパッケージングやGNU autoconfの使い方などは,文書を読むより実際の例を見たほうが参考になります。
良いコードと悪いコードの違いを見分ける
すべてのコードがよく書かれているわけではないので,たくさんのコードを目にすることにより,良いコードと悪いコードの違いがだんだん見分けられるようになってきます。これによって,自分のコードが世の中のレベルと比べてどうなのか,なんとなく感覚がつかめます。
実際のところ,普及しているオープンソースプログラムの中には,「こ,これは」と首をかしげたくなるようなコードなものも割と多く,広く使われるためには必ずしもきれいなコードである必要はない,などということも発見できます。
コードリーディングは敷居が高い?
他人のコードを読むには,ちょっとした意気込みが必要です。まず第一に,ソースコードをとってきて読む,というのは手間ですし,「読んでも難しくて理解できないんじゃないか」という不安もあります。
私の見るところ,この辺は慣れの問題です。いきなり手ごわいコードに挑戦すれば挫折してしまうかもしれませんが,自分がある程度詳しい分野のコードであれば,読んで理解するのはそう難しくありません。身近なところから始めてだんだん慣れてくると,コードを読むことへの抵抗感は減っていきます。
コードリーディングの方法については,本誌Vol.35(注1)で取り上げられています。また,そのものずばり『Code Reading』(注2)という本が出版されています。青木峰郎さんによるサイト『ソースコードを読むための技術』は,コードを読む際の戦略やツールについての情報が充実しています。
スクリプト言語とコンパイル言語
敷居の高さについて触れましたが,実はこの辺の感覚は,スクリプト言語とコンパイル言語ではずいぶん違いそうです。
スクリプト言語の場合,その言語で書かれたライブラリは/usr/lib/rubyなどの特定のディレクトリにテキストファイルのまま保存されているため,いつでも読める状態になっています。ドキュメントがない場合はソースコードを読んで使い方を理解する,といったことは日常茶飯事です。
一方,コンパイル言語,たとえばC言語では,ライブラリは/usr/libなどのディレクトリにバイナリ形式で保存されています。ソースを読むには別途,ソースコードを取ってこないといけません。
man読め…

個人的には,スクリプト言語でプログラミングを始めたほうが,コンパイル言語で始めるより上達が速いと考えているのですが,ライブラリのコードへのアクセスのしやすさも,その理由の1つかもしれません。
まとめ
今回はコードリーディングについて書きました。コードリーディングはプログラミングを学ぶ上で,あるいは,問題解決を行う上で欠かせないプラクティスのひとつです。