制御構造の美学：`Select Case`で紐解く条件分岐の最適化と、その先にあるメモリの深淵
現場でコードを読み解いていると、至る所に「If-ElseIf」の墓場を見かける。保守性が欠如し、条件の重複がバグを誘発する。レガシーなVBAからVB.NETへ移行する際、多くのエンジニアが犯す過ちが、この「If文の直訳」だ。
今日は、ただの構文解説ではない。真に保守可能なコードを書き、かつメモリのライフサイクルまで制御する、我々アーキテクトのための「Select Case」の深淵を紐解こう。
1. 「If-ElseIf」の亡霊を祓う：`Select Case`の真価
`If`文は本質的に「手続き」を記述するものであり、「評価」を記述するものではない。対して`Select Case`は、特定の式を評価の対象として固定する。これにより、コンパイラはジャンプテーブルの最適化を検討できる余地が生まれる。
特に強力なのが`Is`キーワードと範囲指定だ。
不格好なIf文の例
‘ 保守性が低い、典型的な「Ifの連鎖」
If score >= 0 AndAlso score < 60 Then
grade = "F"
ElseIf score >= 60 AndAlso score < 70 Then
grade = "D"
...
洗練されたSelect Caseの記述
‘ 評価対象を固定し、可読性とパフォーマンスを両立する
Select Case score
Case 0 To 59
grade = “F”
Case 60 To 69
grade = “D”
Case 70 To 79
grade = “C”
Case Is >= 80
grade = “A”
Case Else
Throw New ArgumentOutOfRangeException(nameof(score), “範囲外の値です”)
End Select
この記述が優れているのは、評価式が一度しか評価されない点だ。複雑なメソッド呼び出しを条件に含める場合、`If`文では毎回メソッドが走る可能性があるが、`Select Case`ならそのリスクはない。
2. Windows APIと連携する際の「Select Case」活用術
我々が扱う業務システムでは、Windows APIから返される戻り値（エラーコードや状態値）を扱う場面が多い。ここで`Select Case`を活用することで、APIの戻り値を「状態」として型定義し、確実にハンドリングできる。
‘ APIの戻り値を定数化し、Select Caseで安全に分岐する
Const ERROR_SUCCESS As Integer = 0
Const ERROR_FILE_NOT_FOUND As Integer = 2
Const ERROR_ACCESS_DENIED As Integer = 5
Dim result As Integer = NativeMethods.PerformOperation()
Select Case result
Case ERROR_SUCCESS
‘ 正常終了
Case ERROR_FILE_NOT_FOUND, ERROR_ACCESS_DENIED
‘ リソース関連の例外処理として一括管理
Logger.LogWarning(“リソースアクセスエラー: ” & result)
Case Is > 1000
‘ 特定の範囲をユーザー定義のエラーとして扱う
HandleCustomError(result)
Case Else
Throw New System.ComponentModel.Win32Exception(result)
End Select
3. 極限の知見：メモリ最適化とオブジェクトのライフサイクル
コードを整理するだけでは、真のアーキテクトとは呼べない。条件分岐の内部で生成されるオブジェクトの「寿命」を意識せよ。
特に、`Select Case`の各`Case`ブロック内で重いオブジェクト（`FileStream`や`Bitmap`など）を生成する場合、ブロックを抜ける前に明示的な解放を行わなければ、GC（ガベージコレクション）の重荷となる。
究極のメモリ管理テクニック
Select Case actionType
Case “ProcessFile”
‘ 変数のスコープをブロック内に限定し、確実に破棄する
Using fs As New FileStream(path, FileMode.Open)
Process(fs)
End Using ‘ ここでDisposeが呼ばれ、メモリが解放される
Case “DisplayImage”
‘ 巨大なメモリを食うオブジェクトは、処理が終わったら即座に開放
Dim bmp As Bitmap = LoadResource()
Try
Display(bmp)
Finally
bmp.Dispose()
bmp = Nothing ‘ 明示的に参照を切り、GCにヒントを与える
End Try
End Select
4. 伝説のアーキテクトからの助言
レガシーなシステムを保守する際、一番の敵は「変更を恐れる心」ではない。「理解できないコードをそのまま放置する怠慢」だ。
`If`文のネストが深くなったら、それは「その処理を別のクラスに切り出せ」というシステムからのサインだ。`Select Case`で条件を整理した時、各`Case`ブロックの中身が数行で収まるかを確認してほしい。もし数十行にも及ぶなら、それは単なる分岐ではなく、別の機能単位である。
コードとは、書くものではなく、削ぎ落として「意図」を浮かび上がらせるものだ。
今日紹介した`Select Case`の活用術は、そのための最も基本的な、しかし最も強力な武器になる。
次は、あなたのプロジェクトでこの武器を試し、不要な`ElseIf`をすべて駆逐してほしい。健闘を祈る。
