命名規則の深淵：VBAにおける「意味ある記法」の再定義
VBAを「初心者向けのおもちゃ」と侮る者は、メモリ管理の泥沼で溺れることになる。
私は数十年にわたり、数百万行のレガシーコードと対峙してきた。そこで痛感したのは、「コードは書いた瞬間からレガシーになる」という冷徹な事実だ。チーム開発において、命名規則は単なる規約ではない。それは、メモリの生存期間と型の特性をコード上で可視化する「地図」である。
今回は、現代のVBA開発における命名規則の最適解を提示する。
—
1. ハンガリアン記法の「呪い」と「福音」
かつて、変数名の先頭に型を付ける「システムハンガリアン記法」が流行した。`strName` や `lngCount` といった記法だ。しかし、VBAの型推論やCOMオブジェクトの複雑な階層構造の中で、これらは時としてノイズとなる。
現代のアーキテクトが採用すべきは、「意味論的ハンガリアン記法（Appsハンガリアン）」である。型の名前ではなく、その変数が「何を表しているか（用途・状態）」を冠する。
推奨される命名スキーム
- モジュールレベル変数: `m_` を冠する（例: `m_ConfigDictionary`）。これにより、プロシージャスコープとの混同を物理的に排除する。
- 定数: 全て大文字＋アンダースコア（`CONST_TIMEOUT_MS`）。
- 引数: `p`（Parameter）を冠する（例: `pTargetRange`）。
—
2. メモリ管理を意識した変数のライフサイクル管理
VBAにおいて、`Object`型の変数は単なるポインタに過ぎない。特にWindows APIを呼び出す際や、大規模な外部ライブラリと連携する場合、「変数の命名がメモリリークを防ぐトリガーになる」ことを理解しなければならない。
オブジェクト解放を強制する命名と実装
オブジェクト変数は、必ず `o` を冠し、生存期間を意識させる。
‘ 良い例: オブジェクトの明示的解放を意識させる命名
Public Sub ProcessData()
Dim oFSO As Object
Dim oFile As Object
Set oFSO = CreateObject(“Scripting.FileSystemObject”)
Set oFile = oFSO.OpenTextFile(“C:\Logs\system.log”, 1)
‘ … 処理 …
‘ 終了処理: 明示的に Nothing を代入し、メモリを解放する
‘ この記述がないコードは、私のチームでは即座に差し戻しだ
Set oFile = Nothing
Set oFSO = Nothing
End Sub
—
3. API呼び出しにおける「型の厳密性」の担保
Windows API（`user32.dll` や `kernel32.dll`）を扱う際、型指定の曖昧さは死を意味する。VBAの `Long` 型は32bitであり、64bit Office環境では `LongPtr` を使い分ける必要がある。
命名に `ptr` や `hdl`（ハンドル）を含めることで、その変数が単なる数値ではなく、メモリ上のアドレスやシステムリソースであることを明示せよ。
If VBA7 Then
Private Declare PtrSafe Function FindWindow Lib “user32” Alias “FindWindowA” _
(ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr
Else
Private Declare Function FindWindow Lib “user32” Alias “FindWindowA” _
(ByVal lpClassName As String, ByVal lpWindowName As String) As Long
End If
Public Sub GetAppWindow()
‘ hdl: ハンドルであることを明示。これで誤った算術演算を防ぐ
Dim hdlTargetWindow As LongPtr
hdlTargetWindow = FindWindow(“XLMAIN”, Application.Caption)
If hdlTargetWindow <> 0 Then
Debug.Print “Window Found: ” & hdlTargetWindow
End If
End Sub
—
4. チーム開発における極限のガイドライン
チーム開発で混乱を招かないために、以下の3点を「絶対憲法」として掲げよ。
1. スコープの短縮: 可能な限り変数の生存期間を短くせよ。`Sub` の先頭で全ての変数を宣言する古い習慣は捨てろ。使用する直前で宣言する方が、スタック領域の管理において極めて効率的だ。
2. マジックナンバーの排除: `0` や `1` をコードに直書きするな。定数（`Const`）として意味を持たせろ。
3. インターフェースの分離: 外部システム連携を行う場合、`Type` 構造体を駆使し、データ構造を型として定義せよ。`Variant`型は「思考停止」の代名詞である。
結論：プロフェッショナルであるということ
命名規則とは、あなた自身の思考の整理そのものである。
「自分だけが分かればいい」というコードは、将来の自分に対するテロ行為だ。
変数名を見ただけで、その変数がどのメモリ領域を指し、どのタイミングで解放されるべきか、そしてシステム全体のどのレイヤーに位置するのかが読み手に伝わる――それこそが、伝説のエンジニアが到達する「可読性の極致」である。
明日から、君のコードの変数の先頭に、責任の重さを冠してほしい。
