ソースコードにコメントを記載するべきか、どの程度コメントを入れるべきか、どういった内容を書くべきかはプログラミング普遍の議題であって、永遠に解決しない問題の1つのようなところがある。よく言われるのは、短く簡潔で、他人がそのコードを読んだ時に理解を助けるように「なぜ」そのコードをそのように書いてあるのかをコメントとして入れるべきということだ。理にかなっているし、もっとも無難な方法だ。

しかし逆にコメントを書かない方がいいとする考えもある。それはコードとコメントが必ずしも一致していないことがあるからだ。また最初は一致していても、コードに変更を加えていくうちにコメントと内容が一致しなくなり、コメントとコードの不一致が作業ミスの原因になるというものだ。これも一理ある。これを突き詰めれば、コメントをまったく書かなければデベロッパは大量のコードを追って読む必要があり、初期コストは高いかもしれないが結局は内容を確実に理解していい方向へ進むというわけだ。

コメントドリブン開発ってなに

議論は尽きないし、議論する暇があるならコードを書けというのがこの分野の暗黙の了解ではあるわけだが、WebデベロッパであるJames Edwards氏が10日(米国時間)、自身のブログにおいて"Comment-Driven Development"という興味深いタイトルで記事をアップしているので紹介しておきたい。

プログラミングレベルでの開発方法論はいくつかある。もっともわかりやすい例だと、先にテストコードを書いてから本来のコードを書き始めるという「テストドリブン開発」だ。この方法もなかなか理にかなっているし、好んで採用しているデベロッパもいる。それに対して同氏は、自身が使っているプログラミング方法論として「コメントドリブン開発」を紹介している。コードを書く前にかならずコメントを書くというものだ。コメントに書くのは次の2つだ。

  • コードの目的
  • なぜそのように書くのかの理由

今ではコード1行に対してかならずコメントを書くか、だいたい2～3行のコードに対してコメントを書くようにしているという。無駄が多すぎるような気がしなくもないが、同氏の主張も的を射たもので興味深い。

同氏はコメントドリブンの利点として特に次の2点を挙げている。

  • どうやってロジックを書いたらいいかわからない状態でコメントを書き出すことは、問題を洗い出し、自分自身と対話することで考えを整理することになる。つまりコメントを書くという行為そのものを、ロジックを検討し整理するための方法として活用する
  • 逆に記述するコードは明瞭だが、コメントが書けないことがある。コードはぱっと浮かんでくるものの説明が難しいというものだ。こういった状況でコメントを考えることは、コードの目的をはっきりさせることになり、ほかのプログラマにコードを説明する際のコメントとして適切なものとなる。コードがぱっと浮かぶようなケースでは、またなぜそのように書いたかの理由もぱっと忘れてしまう

そこで同氏は、コードとコメントの極端な例をいくつか紹介している。1行1行に対してコメントを書くなんていうのは馬鹿げているように思えるし、同氏のブログにはまるで叙事詩ではないかという大作のコメントが記載されている。しかしながら、コメントを活用したプログラミングという発想にも一理あり、できれば活用したいと考えさせられるものだ。

どんなケースで適用できるか

プログラミング上のスキルとして先にコメントを書くという方法は有益だ。もちろん一歩間違えればただの負担にしかならない。洗練されたコードを記述するためのツールとして活用していなければ意味がない。

コメントを大量に書くことは、ドキュメントを読んでコードを理解するという面においては有益である。しかし、コードを保守したり書き換える段階に発生する、コメントとコードの不一致が発生しやすいという問題は無視できない。しかしこれは逆に、コメントと1行から数行のコードを1つのスニップ(使いまわせるコードの断片)とみなし、コピペして使いまわすといった使い方をするのであれば、それなりに扱いやすい方法のように見える。コードに修正を加えなければ、コメントとコードの不一致という問題を避けられる。

同氏はJavaScriptなどを活用したWebアプリケーション開発に精通しているようで、Web 2.0時代のプログラミングスタイルに慣れ親しんでいるようだから、こうした発想の方がむしろ自然なのかもしれない。コードを修正するなら1から作った方が早いというなら、コメントがきちっとしていた方がいい。コメントを読んで理解したら、それに即した新しいコメントとコードを書けばいいわけだ。興味があるWebデベロッパは一度"Comment-Driven Development"を読んでみるといいだろう。