はじめに

これまでに幾つかの「コンパイルできない現象」を記事としてまとめてきましたが、今回新たなパターンを見つけたので記事としてまとめてみました。

「コンパイルできない現象」の例
【ExcelVBA】DictionaryのItemにユーザー定義型を指定できない
【ExcelVBA】「定数式が必要です」でコンパイルできない
【ExcelVBA】「修飾子が不正です」でコンパイルできない

現象

自作した関数（Function）をコピペして、その関数を若干修正した時に「変数が定義されていません」というエラーが発生しました。
コピー元の関数ではコンパイルエラーは発生しませんでした。
関数を定義した標準モジュールの先頭にはOption Explicitステートメントが書かれており、変数の宣言が強制された状態でした。
関数のコード量は10行程度で、変数や定数は全て定義されていました。
Option Explicitステートメントを外すとコンパイルエラーは出なくなるものの、関数の結果が想定しているものとは異なるものになりました。
以下のサンプルコードの場合、戻り値の型（Long）の変数の初期値である0が返されます。

原因

コンパイルエラーの原因は「関数名（CalcTaxIncluded）と戻り値の変数名（CalcTaxInclude）が異なっている」ことが原因でした。
コンパイルエラーのメッセージとは異なり、「変数が定義されていない」ことが原因ではありませんでした...

サンプルコード

Option Explicit

' 消費税率
Const TAX_RATE As Integer = 10

'--------------------------------------------------------------------------------
' 消費税の税込み価格を返す。
'
' taxExcluded：税抜き価格。
' return：消費税の税込み価格。
'--------------------------------------------------------------------------------
Function CalcTaxIncluded(taxExcluded As Long) As Long
    CalcTaxInclude = taxExcluded / 100 * (100 + TAX_RATE)    ' "CalcTaxIncluded"ではなく"CalcTaxInclude"になっている！
End Function

まとめ

VBAのコンパイルエラーのメッセージは、直接的な原因が分かりづらいケースが多くて困ります...
本来はシンタックスエラーになるべきなのに、Option Explicitステートメントを外すとコンパイル出来てしまうのが恐ろしい...
おまけに中途半端に関数を実行できてしまうので、これが思わぬ副作用を生む可能性がありそうです。
サブプロシージャや関数の粒度を小さく保つことで、コードの可読性を高めるだけでなく、今回のようなケースで原因を追求しやすくなる（＝保守性が高まる）ということを身をもって学びました。
この点については、JavaやC#など他の言語でも全く同じですね。