Excel VBA デバッグ

Excel VBA のトップに戻る
Excel VBA 目次

分かりやすいコードを書く
 ・変数は、宣言して使う
 ・変数は、全角文字を使う
 ・プロシジャーを細分する
 ・分かりやすいコメントを入れる
デバッグ
 ・実行前にデバッグを
 ・ステップ インを使う
 ・デバッグ用のコードを埋め込む
 ・ウオッチ式を使う
動作確認
 ・マクロ的な観点でチェック
 ・ミクロ的な観点でチェック

索引

 コードの書き方や、デバッグのやり方は、人によってずいぶん違うでしょう。
 ここでは、私の流儀を、紹介します。なにかのご参考になれば、幸いです。

追記:プログラムが動いたら、必ず、実データを使って、結果が正しいか確認します。
プログラムの検証方法
(1).データの「最初(特異点)」と「最後(特異点)」と「中ほど」の、3点チェックは必須←誰でもできる
(2).懸念点をチェックする。(業務知識が必要)

分かりやすいコードを書く

 プログラムを書くと、バグ(プログラムの誤り・不具合)が必ず入り込みます。
 バグを取り除いて、期待した動きになるように修正する作業は、プログラムが大きくなればなるほど、大変です。
 デバックをする前に、まず分かりやすいコードを書くことに注意しましょう。

変数は、宣言して使う

「変数の宣言を強制する」にチェック  VBEの設定で、「ツール」→「オプション」の「編集」で、「変数の宣言を強制する」にチェックを入れておくと、
Option Explicit(明示的な)
を自動挿入してくれます。変数の定義を忘れることがないので、デバッグが容易になり、コード間違いを防ぐことかできます。

ここでついでに、「自動構文チェック」のチェックを外します。
チェックが入っていると、編集中に行の途中で改行したりすると、いちいち「コンパイル・エラー」のメッセージが表示されて、うっとおしいからです。
エラー行は、「構文エラーの文字」属性で、色で判読できるし、マクロを書き上げた時点で「デバッグ」するので、いちいちコンパイル・エラーの画面を閉じる操作から開放されます。
 

変数は、全角文字を使う

 変数やプロシージャ名は、全角文字(漢字まじり)の、長めの用語を使うことを、推奨します。
 こうすると、コードの中の、予約語と変数が、視覚的に区分できるし、変数の意味が分かるので、プログラムの意図を、読み取りやすくなります。
 プログラムをキー入力するときに、半角英数の予約語(コマンドなど)と、全角を打ち分けるために、「半角/全角」の切替えを、頻繁に使います。

 このため、私は、

1.「空白」キーの左側の「無変換」キーを、「半角/全角」の切替えキーにしています。
 こうすると、左手の親指で、「無変換」を押すだけで、切り替えできるので、スムーズにコーディングできるようになります。

2.「SmartCaret」を使って、カーソル(キャレット)の点滅速度を、「半角」時は遅く、「全角」時は速くなるようにしています。こうするとこで、文字入力位置を見ているだけで、IME の on/off の状態が分かって、タイプ・ミスが防げます。


プロシジャーを細分する

 私は、プログラムを書くときに、緻密なフロー・チャートを書くことはありません。
 理由は、フロー・チャートを書くために要する時間が、無駄になるからです。

1.まじめにフロー・チャートを書こうとすると、それだけで時間がかかる。
2.フロー・チャートが書かれていても、プログラムを改修するときには、結局コードを読解しなければならない。
3.プログラムを運用した後、プログラムを改修するとき、その改修内容をフロー・チャートに反映しようとすると、多大な時間がかかる。

 分かりやすいコードを書くことに注力しておけば、フロー・チャート無しでも充分なのです。

 私は、プログラムを書くときに、全体を、いくつかの部分(サブ・プロシージャ)に分けて考えます。
 例えば、
入力部分、処理部分、出力部分
とか、 単独処理部分、単独処理を繰返しさせる部分
などです。
(Excel関数の VLOOKUP をマクロで)

 そして、各サブ・プロシージャを書いて、それぞれデバッグして完成させる。
 これを、全体のフローのメイン・プロシージャに組み込んで、結合テストして完成させる、という手順をとります。
 メインのプロシージャは、基本的に、各サブ・プロシージャを読み出す Call 文のみ、という構造にしておけば、メイン・プロシージャのコードを見れば、フロー・チャートの代替になるのです。

 プロシージャを細分化するメリットは、
1.プロシージャの目的・機能が限定されるので、コードの記述が簡単になり、検証もしやすくなります。
2.全体のプロシージャから、何度も呼ぶ部分は、一回だけ記述すればよいので、コードの重複を防げます。
3.一度作ったプロシージャは、別のプログラムのサブ・プロシージャとしても、何度も流用できるので、開発時間を短縮できます。
 私が、このサイトで紹介しているコードの多くも、私がサブ・プロシージャとして使っているものです。

 逆に、プロシジャーを細分化するときに、注意しなければならないことがあります。プロシージャ間の変数の値の授受です。

 私は、プロシージャ間で値を授受する変数は、プロシージャ内ではなく、モジュールで宣言するようにしています。
 こうすれば、簡単に変数の値を共有できます。
 モジュールを複数使う場合は、モジュール・レベルで、Public を付けて、変数を宣言します。
 プロシージャ間で、違う変数名で値を授受したい場合に限り、プロシージャの名前の後ろに、変数(パラメータ)リストをつけます。

 モジュールやプロジェクトができあがったら、変数とサブルーチンやファンクションとの関係を、プログラム開発関連の項で紹介した、VBA_VariableProcedureXref を使って出力しておくと、デバッグが容易になります。


分かりやすいコメントを入れる

 プログラムのデバッグや改修をするときに、コードを読んで理解する必要があります。
 コードの中に、的確なコメントが埋め込まれてあると、可読性が向上して、理解しやすくなります。

この種類の目次に戻る↑ 索引へ↓ トップページに戻る


デバッグ


実行前にデバッグを

 コードを書いたり、変更したりしたら、必ず、「デバッグ」→「VBAProject のコンパイル」をしましょう。
 これで、構文のエラーを、チェックしてくれます。


ステップ インを使う

 プログラムの結果が、想定と違う場合は、変数に格納されている値がどうなっているか、プログラムを動かしながら確認していきます。
 このとき、「ステップ イン(F8)」を使います。状況によっては、「継続(F5)」もしくは、「ステップ オーバ」を使います。こうして、順次実行すると、変数の値の推移が分かり、便利です。


デバッグ用のコードを埋め込む

 私は、コードの中に Stop の行を挿入して、ブレーク・ポイントにしています。
 不要になれば、コメント・アウトすればよいし、プログラムの改修などで、また必要になれば、簡単に復活できるからです。

 また、Debug オブジェクトの Print メソッドを使うと、変数の値を、イミディエイト画面に出力させることができます。
 Debug.Print 変数名

 Debug オブジェクトには、もう一つ Assert メソッドが有ります。Assert メソッドは引数の真偽値を判定し、値が偽の場合に処理を中断します。
 Debug.Assert 真偽値

 参考:内田のHP→VBA→デバッグについて
http://members.jcom.home.ne.jp/rex-uchida/vba110.htm


ウオッチ式を使う

変数の値が変化したとき自動的に止まります。  変数の内容が、想定外の動きをする場合などは、どこでそうなるのか分からないため、「ブレークポイント」を設定できないことが有ります。
 このようなときには、、ウオッチ式に登録すれば、この変数が変わった時点で、中断してくれます。
 この機能も簡単で便利です。操作は、該当する変数の所にカーソルを置いてマウス右クリックして表示されるメニューから選択して、右の画面を表示して、「ウオッチの種類」にチェックを入れます。
 

この種類の目次に戻る↑ 索引へ↓ トップページに戻る


動作確認

 VBA プログラムが、期待通り動いているか、どうやって確認していますか?
 全ての結果を個別にチェックできれば、それに越したことはありません。
 しかし、一般的には、大量のデータを処理するために VBA を使うので、全データをチェックすることは現実的ではありません。
 私は、マクロ的な観点と、ミクロ的な観点 の2面で確認することで、チェックの簡素化を図っています。

 例えば、複数のテキストファイルを、結合して、一つのファイルにする例では、以下のようにします。

マクロ的な観点でチェック

 大局的な視点で、動作結果が妥当かどうかを、できるだけ簡単に確認する方法を考えます。

 例えば、複数のテキストファイルを、結合して、一つのファイルにするプログラムでは、結合前のファイルの行数をそれぞれ数えた上で、その合計数が、結合後のファイルの行数と同じであれば、処理は正しく行われていると判断できます。

ミクロ的な観点でチェック

 サンプルデータを個別に見て、期待した結果になっているかどうかをチェックします。
 このとき、全てのデータをチェックすることは、現実的ではありません。
 特異点だけに着目すれば、効率的にチェックできます。
 データ処理では、(1).最初、(2).最後、(3).中間のしかるべき部分、の3点が特異点になります。

 例えば、複数のテキスト・ファイルを、結合して、一つのファイルに出力するプログラムででは、元のファイルと同じ内容が、結合後のファイルに出力されている必要があります。
 最初の入力ファイルの最初の数行の内容と、最後の入力ファイルの最後の数行の内容が、出力ファイルの最初と最後の行の出力内容と合致していることを確認します。
 これが、(1).最初、(2).最後、に相当します。

 中間は、この例では、結合する複数の入力ファイルのつなぎの部分です。結合対象の、ある入力ファイルの最後の数行の内容と、それに続く入力ファイルの先頭部分の内容が、結果の出力ファイルに正しく出力されているかどうか、を確認します。

 「中間のしかるべき部分」は、単純なファイル結合ではなく、データ処理の場合は、プログラム的に複雑な処理をしている該当データ部分になります。

 このように、3つの特異点だけを抽出してデータをチェックすれば、プログラムの動作を効率的に確認できるでしょう。

この種類の目次に戻る↑ 索引へ↓ トップページに戻る



ホームページのトップに戻る