Source Code Documentation

Haddock, Doxygen, RDocといったツールはソース内の定義と、コメント中のマークアップからドキュメントを生成する。そのためそれらのツールは対象とする言語を少なくともパースできなければならない。しかし、コンパイラが持っているパーサをまた作るのは本来無駄な作業である。また、言語仕様がかわればツールにも修正が必要になる。実際HaddockはGADTを使ったソースがパースできない。ghcの主要開発者の一人であるSimon Marlow氏が作っているにもかかわらずである*1
畢竟ソースコードドキュメンテーションツールは必要なのだ。これからは言語そのものがドキュメンテーションのための仕様を含むべきであろう*2

パーサは言語毎に作らなければならないものだから、どのツールにもサポートしていない言語が存在する*3
ある言語が既存のどのツールでもサポートされていなかったとき、その言語のドキュメンテーションツールを作ろうとする者には、二つの選択枝がある。

  1. 既存のツールに追加という形でとりいれてもらう
    • pros
      1. すでに実装されている機能を流用できる
      2. ユーザーがいる
      3. マークアップ等の仕様を考えなくてよい
    • con
      1. どんなツールにも不満点がある
  2. 新しく自分のプロジェクトを立ち上げる
    • pros
      1. 好きなように開発でき、既存ツールの不満点も解消できる
      2. 名前が売れる
    • con
      1. 車輪の最発明

ユーザーの立場から言えば、一般には、ほとんど同じようなツールの使いかたを新たに覚えるのは面倒なので、1のほうが望ましい。
しかしオープンソースである場合には、作者にとって、2の魅力は非常に強いものなのではないか。
ドキュメンテーションツールには潜在的ユーザーが言語使用者と同じくらいいるのである。一番乗りして、それなりの品質を達成できていれば、相当な数のユーザーを*4得ることができる。現在では様々な分野のソフトウェアが高度に発展するとともにデファクトスタンダードができている。ドキュメンテーションツールというのは、比較的少ない労力で使われるソフトウェアを作ることができる数少ない分野の一つであるといえるだろう。

*1:GADTはSimon PJの仕事だけれど

*2:Pythonには原始的で不十分ではあるがDocumentation Stringというものがある

*3:意味論的な違いが問題になることもある。例えばHaskellのドキュメントをDoxygenで作るのには無理がある

*4:言語に人気があれば