top of page

​タグ一覧

配列処理(67)

階層化フォーム(33)

ファイル操作(23)

シート・セル操作(11)

コード自動生成(10)

ユーザーフォーム(8)

図形操作(7)

GAS(5)

アニメーション(5)

技術解説(4)

副業(4)

考え方(4)

条件付き書式(4)

イミディエイトウィンドウ(3)

Enum(3)

Googleスプレッドシート(3)

ココナラ(3)

クリップボード(3)

介護(3)

開発効率化(2)

イベントプロシージャ(2)

PDF(2)

フリーランス(2)

リスキリング(2)

Excel(2)

Excel小ネタ(2)

数学(2)

Outlook(2)

文字列操作(2)

小説(2)

HTML(2)

JavaScript(2)

日報(2)

カレンダー(2)

パズル(2)

ステータスバー(1)

コード解析(1)

静的変数(1)

OneDrive(1)

バックアップ(1)

可変長引数配列(1)

ブック処理(1)

スクレイピング(1)

スプレッドシート(1)

coconala(1)

リボン登録マクロ(1)

QRコード(1)

実行予約(1)

給与計算(1)

VBA不使用(1)

リボン(1)

超勉強会(1)

六角形(1)

Excel遊び(1)

ボウリング(1)

時計(1)

スピログラフ(1)

図名描写(1)

連想配列(1)

イベント(1)

溶接ロボット(1)

VBA(1)

脱Excel(1)

Discord(1)

ECサイト(1)

CSV(1)

楽天(1)

保育士(1)

シフト表(1)

CDP(1)

楽天市場(1)

経理(1)

javascript(1)

医療(1)

文書作成(1)

LookerStudio(1)

シフト(1)

セキュリティ(1)

発注書(1)

ショートカット(1)

WebAPI(1)

色操作(1)

罫線(1)

スーパー開発ショートカット(1)

ライブラリ処理(1)

開発事例(1)

Excel VBA超勉強会 第1回「デバッグテクニック」

更新日:2024年11月25日

2024年10月25日に開催した勉強会の内容振り返りの記事です。


ree

テーマは「デバッグテクニック


Excel VBAのコーディング作業において発生したエラーを

・気づく

・原因を特定する

・解決する

の一連の作業をデバッグと定義して、この作業がどうやったら効率化できるかを学ぶ内容でした。


録画データ

録画データも公開しております。


デバッグとは

今回の勉強会では「デバッグ」とは


コードに含まれるエラーや不具合を見つけて修正する作業


と定義しております。


実際の開発作業ではこのデバッグ作業が大半を占めてしまいうます。

特に「エラーを探す」=「ものを探す」という作業になってしまった場合は日常生活と同様に無駄な時間の消費に繋がりかねません。

これも踏まえて、このデバッグ作業をどれだけ効率的に行うかが重要です。


まず開発作業の内訳は作業の流れ順に次の3点です。

①要件定義

②コーディング

③デバッグ


これらのうち、

①要件定義が甘い=事前の仕様がぐちゃぐちゃだとデバッグに時間がかかる

②コーディングが甘いとデバッグに時間がかかる

という異なり、より上流の作業がデバッグ作業の非効率化に影響してしまいます。


ですので作業全体を通して「デバッグ」に時間を要しないように工夫が必要です。


結論「デバッグを制する者はVBAを制する」


ree

エラーの種類と確認方法

デバッグ作業の効率化を説明する前に、「エラーの種類と確認方法」を整理しておきます。

エラーの種類には3つあります。

・構文エラー(コンパイルエラー)

・実行時エラー(ランタイムエラー)

・論理エラー


○構文エラー(コンパイルエラー)

実行する前からコードがおかしい場合は構文エラーとなります。

コードウィンドウでもエラーとなって赤く表示されたりすぐに目視で確認ができるものだったり、「VBAProjectのコンパイル」ですぐに見つけることができたりします。

例えば

・宣言していない変数の使用

・単純な記述ミス

などがそれにあたります。


なおこれらはモジュール冒頭に「Option Explicit」を記述してる前提ですので、「Option Explicit」は必ず記述するようにしておきましょう。


○実行時エラー

実行してみて途中で止まったりなどのエラーです。

これは実行してみないと分からないため「構文エラー」よりも気づきにくいです。

これは内容として多岐にわたりますが具体的に

・ゼロ割

・参照先のセルやシートが存在しない

・ファイルが存在しない

・オーバーフロー

などがあります。


これらは実行途中のエラーから内容が確認できます。

ですのでエラーの内容を沢山把握、経験しているほど原因特定、修正ができるようになります。

すなわち

「エラーの数だけ強くなれる」


○論理エラー

これは実行結果が意図した結果と異なる場合です。

実行時エラーと異なり、途中で止まったりせず、エラーなどは表示されずにすんなり処理は終了するのですが、処理した結果が意図した結果と異なるというエラーになります。

結論、このエラーが最も見つけるのが大変かつ、修正が難しいものです。


具体的に

・計算結果が違う

・出力先のセルが違う

・処理がなかなか終わらない

・そもそも結果が出力されない

などがあり得ます。


上記をからデバッグの難易度をまとめると


「構文エラー < 実行時エラー < 論理エラー」

となります。


ree

どうやったら速く原因を特定できるか

デバッグ作業を効率化するうえで必要な要素は2つに大別されます。

①エラーを特定しやすいコードにする

②エラー特定のテクニックを習得する


①エラーを特定しやすいコードにする

具体的なコードとして

・処理過程が分かりやすい(可読性の高い)コード

・On Error Goto ***を使用しない

などを挙げております。


可読性の高いコード」と一筋に片づけても、かなり奥の深いノウハウですので、ここでは割愛しますが、簡単に次のような心がけが必要になります。

・一貫した命名規則(変数、関数、モジュール名)

・「入力、処理、出力」のルール

・適切に処理を分割(1プロシージャが長すぎない)

・ネストは最小限

・必要な範囲でコメント(くどくなりすぎない)


On Error Goto ***を使用しない

これはOn Error Goto構文を利用するとエラーが発生した箇所から自動的に***に飛んでしまうので、エラーの発生個所が特定しにくくなります。ですので私は滅多にこの構文は利用しません。


②エラー特定のテクニックを習得する

これらは冒頭の録画データで実際のデモンストレーションをやっているので、実際にそれらを確認してみてください。


良くやるテクニック

・VBAProjectのコンパイル

・3種類のステップ実行

・ブレークポイントの設定

・呼び出し履歴

・定義へ移動、元の位置へ戻る

・ローカルウィンドウで変数の中身確認

・イミディエイトウィンドウで変数の中身確認

・黄色いやつはドラッグで移動できる


あまりやらない作業

・ウォッチウィンドウ

ree

コメント

5つ星のうち0と評価されています。
まだ評価がありません

評価を追加
Softex-Celware

​インボイス登録番号:T5810983887134

  • Facebook
  • Twitter
  • YouTube

©2023 softex-celware。Wix.com で作成されました。

bottom of page