Comparators―比べてみればわかること

最終回 実りのある比べ方

この記事を読むのに必要な時間:およそ 3.5 分

本連載ではさまざまな比べ物に精を出してきましたが,人気のある,よく話題に上る比較は意図的に遠ざけてきました。それはたとえば,コメントは書くべきか,言語は動的型付けと静的型付けのどちらが良いのか,モバイルはWebかネイティブか,といった話題です。こういった論争を生む対立軸の多くは,たいていどちらの主張もそれほどすばらしくないことが多いものです。そして長引く論争に疲れ果てたころ,どこからともなく時代の風が,新しい正しい答えを運んできたりするのです。

時代が答えてくれた論争

時代が流し去った論争は急速に忘れ去られていきます。数ある古い論争の中から,日本の片隅でくすぶっていた火種と,計算機科学史の一幕と言える大きな争いを,1つずつ振り返ってみましょう。

Malloc/Free論争は,10年以上前に日本のニュースグループで起きた論争です。プログラムを終了することがわかっている場合,malloc( )関数で確保したメモリをfree( )関数で解放すべきか否かが論点。OSが解放してくれるから自分ではしない派と,規律を守りすべき派が争いを繰り広げました。

今,この論点を気にかける人はほとんどいないと思います。同様の話題が蒸し返されることもありません。この論争が忘れ去られた大きな理由の一つは,ガベージコレクション(GC)によってメモリ管理を自動化するプログラミング言語が普及したためでしょう。GCは,プログラマ自身がメモリ管理を気にするというアイデアそのものが持つ筋の悪さを明らかにしました。

Goto害悪論の期限はさらに古く,40年以上前にさかのぼります。グラフ探索のアルゴリズムなどで知られるEdsger Dijkstraは,プログラミング言語のGoto文がソフトウェアの品質に与える悪影響を非難する論文を発表しました。論文はACM(Association for Computing Machinery:アメリカ計算機学会)の会報に掲載されました。Goto文を使わないDijkstra自身の主張は「構造化プログラミング」と呼ばれるアイデアの一部となりました。

Goto害悪論は長い時間をかけて廃れましたが,今から振り返るとプログラミング言語が「例外」のしくみを備えたことが廃絶への大きな一歩だったように見えます。結局Goto文が持つ有用性の大半はエラーの扱いに関するものであり,それはもっと抽象度の高い「例外」というアイデアでうまく扱うことができるわけです。構造化プログラミングはエラーを扱ううえで不自由過ぎ,Goto文は目的に対して乱暴過ぎました。近代的なプログラミング言語は例外機構の有用性を示しました注1)⁠

Dijkstraが起こしたこの論争は,ソフトウェアエンジニアリングに関する論争のひな型となりました。論文からブログ記事まで,何か論争をふっかけるときはDijkstraの論文「Go to statement considered harmful」をもじって「considered harmful」を題名に含めるのが暗黙の了解になっています

注1)
例外機構への批判も絶えませんが,広く受け入れられてはいないようです。
http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

答えを待っている論争

過去の論争が時代の向こうに消えていく一方,いまだにくすぶっている論争も多くあります。そうした論争もいずれ新しい選択肢によって流し去られるに違いないと,筆者は楽観しています。

現在進行形の論争を解決に導く選択肢は何なのでしょう。それがわかれば苦労しません。ただ,ある論争についてよく考えていれば何かヒントが見えてくることがあります。筆者もそんな論点を一つ持っています。コメントvs.コードです。

今でもしばしば蒸し返される論争の一つにコメント不要論があります。ソースコードには詳しいコメントを書くべきか? 筆者はその昔コメント必須派でしたが,今はどちらもいまいちという結論に落ち着いています。

コメント不要主義者は,コメントに割く労力はコードの可読性を高めるために使うべきだと説き,コメント頼みの読みにくいコードや,コードの変更に追従できず内容が古くなりがちなコメントの性質を非難します。コメント必須主義者は,コードによってとらえることのできない情報や意図があると主張し,それらをコメントとして文書化すべきだと訴えています。

コメントとコミットログ

一見すると,この論争はドキュメントを書くのを億劫がる横着なプログラマと,神経質で几帳面なプログラマのいがみ合いであるかのように映ります。

実際のところ,それはあまり正しくありません。コメント不要主義者も,ある種のドキュメントは案外丁寧に書くのです。そうしたドキュメントの一つがコミットログです。コメント不要主義のコードベースで仕事をしている筆者は,開発者が丁寧なコミットログを書く様子をたびたび目にしてきました。ドキュメントとしてのコミットログにピンと来ない読者は,WebKitのコミットログを覗いてみてください。詳しく書かれたソースコードコメントに匹敵する事細かな説明を見ることができるでしょう。

コメント嫌いの開発者たちが,コミットログの必要性は認めている。これは興味深い事実です。コメント不要主義者の多くはドキュメントを書きたくないのではなく,コメントを書きたくないのです。なぜコミットログは書くのにコメントは書かないのでしょう。コメントとコミットログの違いはどのように説明できるのでしょうか。

メディアの違い,レンズの違い

コメントは,ソースコードのある瞬間を説明しています。言ってみれば写真のようなものです。一方,コミットログはある状態から別の状態への変化をとらえた動画です。またコメントはクラスやメソッドなどの細かい単位で物事を説明するのが主流なのに対し,コミットログは変更全体を一望します。コメントはズームやマクロ撮影のようなもの,一方のコミットログは広角(ワイド)撮影です。

ドキュメントを載せるメディアの向き不向きは,開発スタイルと関係があります。反復的で漸近的な開発スタイルでは,ある瞬間のスナップショットはありがたみが大きくありません。あとに続く変化のせいですぐに古びてしまうからです。むしろその変化自体を追いかけた動画のほうが理解の助けになるでしょう。一方,前もって念入りにデザインを決めるなら,解像度の高い写真的なメディアが役に立つでしょう。

ドキュメントを写すレンズの違いはコードのデザインの影響を受けます。クラス単位の働きより複数のオブジェクトをまたぐ協調と役割分担を重視するなら,広角で景色を収めたくなります。オブジェクト同士の位置関係を一目で見渡せるからです。一方で個々のクラスの完成度を重視して丁寧に磨き上げるなら,その細部をとらえる力があるのはマクロ撮影です。

反復的な開発スタイルをとる若いプロジェクトや,部分的な再利用を気にしないアプリケーションソフトウェアほど,コメントよりコミットログを好むのが自然な成り行きに思えます。逆によく理解され成熟したソフトウェアや再利用を意図したライブラリのコードはコメントを好む傾向がありそうです。プロジェクトやデザインの違いがコメント不要論争の火種だった。そう考えることはできるかもしれません。

著者プロフィール

森田創(もりたはじめ)

平日はWebブラウザの開発,休日はWebブラウザの利用に従事。最近の趣味は/etc/hostsファイルに中毒性の高いWebサイトをリストし,127.0.0.1にリダイレクトすること。現在7サイト。スマートフォンの勉強をしなければと思いつつ/etc/hostsにアクセスできない端末を持つのが不安で躊躇している。

http://steps.dodgson.org/

コメント

コメントの記入