開発環境の強化

コードコメンタとエラー処理ルーチン

 最後に、表18に挙げたOffice 2000 Deve-loperの開発支援ツールの中から、コードコメンタエラー処理ルーチンについて解説します。アプリケーションはExcel 2000を使用しましょう。
 まず、説明の前準備として、コードウィンドウに図13のようなマクロを用意してください。次に、[アドイン]-[アドインマネージャー]コマンドで[アドインマネージャー]ダイアログボックスを開き、[VBAコードコメンタ]を選択して[ロード/アンロード]チェックボックスをオンにします(図14)。同様に、[VBAエラー処理ルーチン]も[ロード/アンロード]チェックボックスをオンにしてください。そして、[OK]ボタンをクリックすると、[アドイン]メニューにこれらのツールが追加されます(図15)。これで準備は整いました。

図13:コードウィンドウにシンプルなマクロを用意する

図14:VBAコードコメンタをロードする

図15:VBAコードコメンタとVBAエラー処理ルーチンがアドインメニューに追加された

 VBAコードコメンタは、自動的にマクロにコメントを挿入する機能です。[アドイン]-[VBAコードコメンタ]コマンドを実行して、図16のダイアログボックスで作成者などの必要な情報を入力して[OK]ボタンをクリックすると、あらかじめ用意されたテンプレートにしたがってコメントが自動的に挿入されます(図17)。

図16:[VBAコードコメンタ]ダイアログボックス

図17:VBAコードコメンタによってマクロにコメントが挿入された

 なお、このテンプレートは、図16のダイアログボックスの[テンプレート]ボタンで開く[テンプレート]ダイアログボックスで確認することができます(図18)。ただし、このダイアログボックスでは、テンプレートの確認はできても編集することまではできません。もしこのテンプレートをカスタマイズする必要が生じたら、「\Program Files\Microsoft Office\ ODETools\V9」にある「CodeCommenter.eht」を、表19に示したコードコメンタおよびエラー処理ルーチンのテンプレート書式にしたがってメモ帳などで編集してください。図17を見るとわかりますが、デフォルトのテンプレートはコメント過多の感が否めません。そこで、筆者はメモ帳を使って図19のように編集してみました。その上でVBAコードコメンタを実行したのが図20です。デフォルトのテンプレートを使ったときと比較して、コメントが随分とすっきりしたかと思います。

図18:VBAコードコメンタの[テンプレート]ダイアログボックス

表19:コードコメンタおよびエラー処理ルーチンのテンプレート書式

 トークン

 意味

$$A作成者名
$$Bプロシージャボディ
$$D現在の日付(Windowsの短縮形式の日付)
$$Hヘッダーコメント
$$I作成者の頭文字
$$Nプロシージャ名(クラスのメンバーの場合は、クラス名も含め、正しいプロシージャ名と入れ替わる)
$$Pプロジェクト名
$$T現在の時間(Windowsの短縮形式の時間)
$$Vヘッダー変数
$$Yプロシージャの種類。適切なサブ、関数、またはプロパティ
$$SA自動を開始(挿入したエラー処理ルーチンの開始をフラグで示す)
$$EA自動を終了(挿入したエラー処理ルーチンの終了をフラグで示す)
$$SHヘッダーの文頭
$$EHヘッダーの文末

図19:メモ帳で「CodeCommenter.eht」ファイル(デフォルトのテンプレート)を編集する

図20:編集した「CodeCommenter.eht」ファイルをテンプレートにVBAコードコメンタを実行した

 今までこまめにコメントを入力してきた人はもちろんですが、コメントを入力する習慣のなかった人は、ぜひともこのツールを使って、マクロには必ずコメントを挿入するよう励行してほしいものです。作成者や日付はもちろんですが、プログラミングの世界では半年経てば自分も他人なのです……。マクロの処理内容などをマクロ作成時にコメントとして書き留めておく作業を決しておろそかにしてはいけません。
 次に、VBAエラー処理ルーチンですが、マクロのエラー処理の記述は極めて大切な工程であるにもかかわらず、今まで私たちは自己流のエラー処理を自前で用意する必要がありました。こうした開発姿勢は、そのときの気分によってまちまちのコードを書く元凶にもなってきました。
 たとえば、Openステートメントでフロッピーに保存されているファイルを開くケースを想定してみましょう。この場合、フロッピーが挿入されていない、指定した名前のファイルが存在しない、指定したファイルはすでに開かれている、などエラーが発生する要因はいろいろあります。私たちは、こうしたエラーに対処するためにOn Error GoToステートメントを使い、エラー処理ルーチンの中でエラー番号(エラーが発生した原因)を特定し、その番号に応じたエラー処理を行なうのが一般的です。ただし、このコーディングは当然手作業なので、どうしても自己流になりがちです。特に、エラー番号を調べるには、Error関数を使う方法と、ErrオブジェクトのNumberプロパティを使って「Err.Number」というステートメントを記述する方法がありますが、これではエラー処理のコードにばらつきが出る原因になります。
 しかし、VBAエラー処理ルーチンを使えば、エラー処理の記述はある程度自動化することができます。その上、前述のVBAコードコメンタ同様に、すべてのマクロのエラー処理コードに統一性をもたせることも可能となります。
 図21が示すとおり、VBAエラー処理ルーチンは、Office 97 VBAで登場したErrオブジェクトを使って「Err.Number」や「Err.Description」という理想的なステートメントを自動生成してくれています。あとは、ここに必要な処理を書き込んでゆくだけですから、これはラクな作業です。

図21:VBAエラー処理ルーチンが自動生成したエラー処理ステートメント

 VBAエラー処理ルーチンも、[テンプレート]ダイアログボックスでテンプレートの確認はできますが(図22)、カスタマイズするときには「\Program Files\Microsoft Office\ODETools\V9」の「ErrorHandler.eht」をメモ帳などで編集しなければなりません。VBAコードコメンタのデフォルトのテンプレートはいささか冗長でしたが、VBAエラー処理ルーチンのテンプレートは、おそらくデフォルトのままでも使えるでしょう。

図22:VBAエラー処理ルーチンの[テンプレート]ダイアログボックス

 ただし、最後に一言付け加えさせてください。VBAエラー処理ルーチンの登場は確かに歓迎すべきことです。しかし、それでプログラミングが雑になるようでは本末転倒です。プログラミングの理想はエラーの発生しないコードであることを忘れてはいけません。先のフロッピーに保存されているファイルを開こうとするケースのように、コードではどうしてもエラーの発生を抑止できないときに、そのエラーをいかに上手に処理すべきか。エラーの処理は、いつの時代もプログラマの技量やセンスが問われる大切な作業であることを心に留めておいてください。支援ツールは大いに使うべきですが、支援ツールに使われることがないように留意したいものです。