「動けばいい」を卒業する。VB.NETの品質を劇的に変える『Option Strict On』の真実
こんにちは。プログラミングの世界へようこそ。
あなたが今、Visual Basic（VB.NET）を使って「マクロの記録」から一歩踏み出し、自分自身の手でコードを書き始めたのだとしたら、それはエンジニアとして非常に素晴らしい第一歩を踏み出したと言えます。
「コードを書いた。実行した。エラーは出ない。よし、完成だ！」
……もしあなたがそう思っているなら、少しだけ立ち止まって、私の話を聞いてください。実は、その「エラーが出ない」という状態が、将来的にあなたのアプリケーションを破壊する「静かな時限爆弾」になっている可能性があるのです。
今日は、プロの現場で「型（Type）」をいかに扱うか、そしてなぜ『Option Strict On』という設定が、初心者から脱却するための「聖杯」と呼ばれるのかを、そのメカニズムと共に深く掘り下げていきましょう。
1. 忍び寄る「暗黙の型変換」という罠
VB.NETは、非常に「親切な」言語です。あなたが多少、雑なコードを書いても、コンパイラ（プログラムを機械語に翻訳する仕組み）が気を利かせて、「たぶん、こういう意味だよね？」と解釈して動かしてくれます。これを「暗黙の型変換（Implicit Conversion）」と呼びます。
例えば、次のようなコードを見てみましょう。
' --- 危険なコードの例 ---
Dim age As Integer = 25
Dim ageText As String = "30"
' 文字列と数値を足そうとしている（暗黙の変換が走る）
Dim total As Object = age + ageText一見、何の問題もなさそうに見えますよね？ しかし、ここにプロフェッショナルが嫌う「不確実性」が潜んでいます。
なぜ「暗黙の変換」が危険なのか？
1. 実行時エラー（Runtime Error）の恐怖:
コンパイル（ビルド）時はエラーが出ませんが、ユーザーが「数字ではない文字列（例: “abc”）」を入力した瞬間、プログラムは無残にクラッシュします。
2. パフォーマンスの低下（オーバーヘッド）:
コンピュータは、型が曖昧だと「これは整数か？ 文字列か？ それともオブジェクトか？」と、実行中にいちいち推論しなければなりません。この「推論」こそが、CPUの貴重なリソースを浪費する原因です。
3. 意図しない挙動:
「10」＋「20」が「30」になるのか、「1020」になるのか。暗黙の変換に頼っていると、あなたの意図とは異なる計算結果が、気づかないうちにデータベースに書き込まれてしまうのです。
2. 究極の盾：`Option Strict On` を有効にする
ここで登場するのが、今回最も伝えたい技術的規範、`Option Strict On` です。
これは、コンパイラに対して「一切の妥協を許すな。型が完全に一致しない限り、エラーとして報告せよ」と命令するスイッチです。
設定の方法
ファイルの最上部に、たった一行書き加えるだけです。
Option Strict On ' これを必ず書く！これを記述すると、先ほどの「雑なコード」は、実行する前（ビルド時）に「型が合わないので、修正してください」と真っ赤なエラーを出して教えてくれるようになります。
「えっ、エラーが出て動かなくなったら不便じゃないですか？」と思うかもしれません。しかし、考えてみてください。「開発中にエラーが出て教えてくれること」と、「ユーザーの手元で突然アプリが落ちること」、どちらがエンジニアとして致命的でしょうか？
3. 実践：クリーンなコーディングへの昇華
では、`Option Strict On` を有効にした状態で、どのようにコードを書くのが「正解」なのか。具体的なビフォー・アフターを見ていきましょう。
❌ 避けるべきコード（暗黙の変換に頼った書き方）
' Option Strict Off だと動いてしまうが、非常に危険
Dim input As String = "100"
Dim value As Integer = input ' ← ここでエラー（型が違うため）✅ プロフェッショナルなコード（明示的な変換）
プロは、型を変換する際に必ず「変換できるかどうかを確認するステップ」と「明示的な指示」を挟みます。
' --- クリーンなコーディング作法 ---
Option Strict On
Module Module1
Sub Main()
Dim input As String = "100"
Dim value As Integer
' 1. 安全な型変換: TryParse を使う
' 文字列が数値に変換可能かチェックし、可能なら value に代入する
If Integer.TryParse(input, value) Then
Console.WriteLine($"変換成功: {value}")
Else
Console.WriteLine("エラー: 数値として認識できません。")
End If
' 2. オブジェクトから特定の型へ変換する場合: DirectCast を使う
' CType よりも高速で、厳格な型チェックを行う
Dim obj As Object = 500
Dim strictValue As Integer = DirectCast(obj, Integer)
Console.WriteLine($"DirectCast成功: {strictValue}")
End Sub
End Moduleここがポイント！エンジニアの知恵袋
1. `Integer.TryParse` を愛せ:
ユーザー入力（テキストボックスなど）を扱うときは、これ一択です。プログラムをクラッシュさせずに、優雅にエラーハンドリングができます。
2. `DirectCast` と `CType` の使い分け:
- `DirectCast`: 「これは絶対にこの型だ」と確信がある時に使います。非常に高速です。
- `CType`: 型の変換（例：整数から文字列へなど）を柔軟に行いたい時に使いますが、`DirectCast` よりは少し重いです。
- `Option Strict On` の環境では、これらを使い分けることで、コードの意図が明確になります。
4. まとめ：堅牢なコードは「規律」から生まれる
`Option Strict On` を導入すると、最初はコンパイラに怒られ続け、コードを書くのが少し面倒に感じるかもしれません。まるで、厳しい先生に細かく添削されているような気分になるでしょう。
しかし、その「面倒くささ」こそが、あなたのアプリケーションの「堅牢性（Robustness）」と「パフォーマンス」、そして「保守性（Maintainability）」を支える土台となります。
今日から始める3つのルール：
1. すべてのファイルの先頭に `Option Strict On` を書く。
2. 「なんとなく動く」を禁止し、型が一致するか常に意識する。
3. 変換には `TryParse` や `DirectCast` を使い、意図を明確にする。
ここをクリアすれば、あなたはもう「マクロを記録する人」ではありません。「信頼されるソフトウェアを設計するエンジニア」への道を歩み始めたのです。
応援していますよ。さあ、素晴らしいコードを書き進めましょう！
