ベストを尽くすことの難しさ(話は軽い)

今に始まったことではないのだが、自分が書いたプログラムのソースコードを後から読むと、なんともな気分になるものだ。まずコードが汚い、スタイルとして美しくない。その次に論理的に練り上げられていない。続いて考えが甘い。もっとスマートで計算量の少ない短いコードがあるはずだ。読み返しながら書き換えてしまいたくなることは少なくないのだ。

さて、ではそのときに真剣に仕事をしていなかったのか?たぶんそんなことはない。そのときに最良と思える方法でコードを書いていたはずだ。そのときなりに論理設計もやっていたはずだ。ここが難しい。

最近珍しくまとまったコードを書いている。昨日書いたコードを今日書き直したくなることもある。今朝の作業を、その後の作業をふまえて午後には書き直したくなることもある。むろん今朝はそれがベストだと思っているわけだ。書き直したところで機能的にはなんにも変化しないわけなのだが、単純に論理の問題なのだから。

たぶん、常にベストを尽くしていれば、1年前のベストと今のベストは変化するだろう。これが伸び続けている間はおそらく大丈夫。ちゃんとベストが尽くせているのかな。

技術的なことに興味がある方は続きをどうぞ。

閏年かどうかを判定することを考えてみよう。この話は数年前に私の友人たちに聞いてみた題目だ。

まず、閏年とはどういうものか。正確に定義する。

  • まず、グレゴリオ暦を使うことを前提とする(要するに普通の暦)
  • 1. 西暦年が4で割り切れる年は閏年
  • ただし、西暦年が100で割り切れる年は平年
  • ただし、西暦年が400で割り切れる年は閏年

つまり、2008年は閏年、1900年は閏年ではない、2000年は閏年、となる。

問題は、「与えられた西暦が閏年かどうかを判定するプログラムを書きなさい」だ。5人くらいに書いてもらったのだが、これが千差万別でとってもおもしろかった。かいた人の性格が表れるからまたおもしろい。

こんな小さな問題でもいろんな計算ができるのだ。上に上げた定義を順番に計算する人もいる。いきなり400で割ってみて、割り切れるならば後は計算する必要すらないことに気がつく人もいる。平均的に同じ計算量になるようにする人もいる。ここがプログラマの腕だろうか。

ちなみにそのとき最もエレガントなプログラムをくれた人は、おそらくこのブログの読者だ。覚えてるかな?そこのあなた!

みなさんも電車の中で暇つぶしにでも考えてみよう。