ソースコードの自動生成が効果的なこともある：プログラマーはものぐさな人が向いているとも言える

昨日、「何とかする力」で書いた仕事ですが、昨晩のうちにプログラミングをだいぶ進めることができました。

今回の処理は、「テキストのコマンド行を受信し、その内容に応じた処理を行う」というもので、それ自体は難易度としては低いのですが、数が多く、全部で167種類のコマンドがあります。

一般的に、テキストベースのコマンド行の処理は次のような感じで行います。

受信→トークン分割→トークンを解析し、対応する処理を実行

167個もコマンドの種類があると、if文やswitch-case文だとかなりソースが長くなってしまい、書くのも大変ですし、後で管理するのも大変です。

こういう場合は、構造体の配列に167個のコマンドを共通型で保持し、ループしながら一致するコマンドを探し、そのコマンドに応じた関数を呼び出す、という感じにするとソースがシンプルになります。

それでも、167個ものデータを構造体の初期値として定義したり、あるいは設定ファイルとして打ち込むのは、結構な手間がかかりますし、入力ミスも心配です。

そこで、仕様書（PDF）をコピペしてExcelに貼り付け、CSV形式でファイルに書き出し、そのデータをソースファイルに変換するプログラムを先に作ることにしました。

PDFからExcelに綺麗にコピペするのが多少手間でしたが、後は何度でも変換してソースを確認し、気に入るまで変換プログラムを調整して、167個の定義や関数のスタブが一気に完成です。きちんと変換プログラムでエラーチェックもするように作ったので、PDFがそもそも間違えている箇所もすぐに発見でき、修正も簡単です。自動生成したソースの行数は実に2876行！キー入力が高速でも、そう簡単には入力できません。

「ソースはエディタで入力するもの」という固定観念にとらわれてしまうと、こういうケースでは、ひたすらキーパンチャーとしての作業に時間を取られることになり、しかも入力ミスも心配になるのですが、自動生成すれば時間短縮と共に入力ミスも減らすことができます。

私がなぜ自動生成を最初から思いついたかというと、社会人になった頃から開発していたCADシステムのGUIを作る際、GUI構築ツールを使っていたのですが、ソースのスタブはGUI構築ツールが自動生成するのは当たり前でした。GUI開発の場合にも、ボタンがクリックされたらどの処理を呼び出す、という感じで、画面の複雑さに応じた膨大なコールバック関数を作ることになるのですが、それを全てエディタで入力するのは大変ですし、そもそも共通化もしやすいので、自動生成だったのです。

まあ、まだ処理の実体を書いていないので、まだまだやることはあるのですが、こうやって頭を使って効率良く進めるのも「何とかする力」の一つです。昔から「プログラマーはものぐさな人が向いている」というのは一理あり、ものぐさな人ほど、「どうすれば共通化できるか」「どうすればシンプルにできるか」を考えて手を抜くので、良いソースができる、というものです。マメで面倒なこともコツコツやるタイプが活躍する分野ももちろんありますが、ものぐさがいかに手を抜くかで価値があることも結構あるのです。