こんにちは！HHVMの深淵を覗く、あなたの先輩フルスタックエンジニアです。
今回は、Hack言語の心臓部である「HHVM型チェッカー（hh_client / hh_server）」が、コードの裏側でどのように動いているのか、その核心に迫ります。テーマは「デッドコード（到達不能コード）の静的解析アルゴリズム」です。
「動かないコードなんて書かなきゃいいじゃん」と思いましたか？
いえいえ、ここを理解すると、Hackの静的型システムがどれほど厳密に、そして優しく私たちのコードを守ってくれているのかが手に取るように分かります。ここをクリアすれば、Hackのコードリーディングと設計のスキルは一気にプロの領域へ到達しますよ。
それでは、HHVMの脳内を覗く旅に出発しましょう！
—
1. なぜHackの型チェッカーは「デッドコード」が嫌いなのか？
他の動的型付き言語（PHPやPythonなど）では、実行されないコード（例えば `return` の後ろに書かれた処理など）は、単に「無視される」か「ちょっとした無駄」で済みます。
しかし、厳格な静的モード（`<<____EnforceGenerics>>` や `<<__Strict>>`）を掲げるHackの世界では話が違います。
HHVMの型チェッカーは、コードを実行する前に「すべてのパス（道のり）が論理的に正しいか」をコンパイル時に完璧に証明しようとします。
もし、絶対に実行されない「デッドコード」が放置されていると、型チェッカーはこう考えます：
> 「おいおい、このコードは型チェックの対象になっているのに、一生実行されないぞ。何か君の論理設計にバグがあるんじゃないのか？」
この厳格さこそが、大規模なプロダクトでバグを未然に防ぐためのHackの最大の武器なんです。
—
2. 型チェッカーの頭の中：制御フローグラフ（CFG）の仕組み
HHVMの型チェッカーは、ソースコードを読み込むと、それを制御フローグラフ（Control Flow Graph: CFG）という数学的な「地図」に変換します。
イメージとしては、以下のような「分岐と合流の迷路」を脳内で構築している感じです。
[ 関節の開始 (Entry) ]
│
▼
{ 条件分岐 } ──( true )──> [ 処理A ] ──┐
│ │
( false ) │
│ │
▼ ▼
[ 処理B ] ──────────────────> [ 合流点 (Join) ]
│
▼
[ return ]
│
▼
⚡ [ デッドコード ] ⚡ <--- ここを検知！
型チェッカーはこの迷路を歩きながら、すべての道が最終的にどこに繋がっているかをトラッキングします。そして、「どの道筋からも絶対に到達できないブロック」を発見した瞬間、静的解析エラーをバシッと吐き出すのです。
—
3. 具体例で見る「やってはいけない」デッドコード
それでは、実際のHackコードでよくあるデッドコードのパターンを見てみましょう。初学者がやりがちなミスを交えて解説しますね。
パターンA：`return` の後の悲劇
一番シンプルでよくあるケースです。
<<__Strict>>
namespace HackMasterclass;
function calculate_discount(bool $is_vip): float {
if ($is_vip) {
return 0.20; // VIPは20%オフ
} else {
return 0.05; // 通常は5%オフ
}
// ─── ここから下がデッドコード！ ───
$tax = 1.10;
return 0.20 $tax; // 永远に実行されない
}
【何が起きているか？】
`if` 文の中でも `else` の中でも、必ず途中で `return` が実行されます。そのため、関数自体の出口（Exit）にすでに到達しており、その下にある `$tax` の計算や `return` には物理的にたどり着くことができません。
HHVMはこれを検知し、ビルド（型チェック）時にエラーを返します。
—
パターンB：絶対に偽（false）になる条件分岐
型チェッカーは、変数の型情報（Type Refinement）を非常に鋭く追跡します。そのため、論理的に「あり得ない分岐」を作ってしまうと、それもデッドコードとして怒られます。
<<__Strict>>
namespace HackMasterclass;
function process_age(int $age): string {
if ($age < 0) {
return 'Invalid age';
}
// ここを通過した時点で、$age は必ず 0 以上であることが保証される
if ($age < 0) { // ← ここ！
return 'Negative age'; // 絶対に実行されないデッドコード！
}
return 'Valid age: '.$age;
}
【何が起きているか？】
最初の `if ($age < 0)` で、もしマイナスであればすでに `return` で関数が終了しています。したがって、2つ目の `if ($age < 0)` の時点では、型チェッカーの脳内では `$age < 0` は「絶対にあり得ない（False）」と断定されています。結果として、このブロック全体がデッドコード判定を受けるわけです。賢いですよね！
—
4. デッドコードを綺麗に整理するための極意
実務でコードをリファクタリングしていると、仕様変更の残骸としてデッドコードが生まれがちです。これをキレイに整理するためのアプローチを伝授します。
1. 早期リターン（Early Return）を徹底する
条件が合わない場合は最初に弾く（Guard Clause）スタイルはHackでも推奨されますが、その後のコードが本当に必要か常に疑いましょう。
2. 型システムの賢さを信じる
「もしかしたらこうなっているかも…」という不安から冗長なチェックを書くと、型チェッカーに「それデッドコードだよ」と怒られます。型チェッカーが推論できる情報は、コード側で二重にチェックしないのがCleanなHackコードの書き方です。
3. `hh_client` を常に走らせる
エディタ（VSCodeやNuclide等）のプラグインで常に `hh_client` を有効にしておき、保存した瞬間に赤波線（エラー）が出たらすぐに対処する習慣をつけましょう。
—
まとめ：型チェッカーはあなたの最高のペアプログラマー
今回は、HHVM型チェッカーが検知するデッドコードの静的解析アルゴリズムについて、制御フローの観点から解説しました。
「デッドコードを怒るなんて、型チェッカーは厳しいやつだな」と感じたかもしれません。ですが視点を変えれば、これは「君の書いたコードに論理的な矛盾やムダがあるよ、一緒に直そうよ」と教えてくれる、世界最高峰の優秀なペアプログラマーそのものです。
ここをクリアできれば、あなたの書くHackコードは劇的に美しく、そして堅牢になります。
ぜひ、日々の開発で `hh_client` の声に耳を傾けてみてくださいね。それでは、次回の極限の知見でお会いしましょう！