Hackの深淵：`?`（Nullable）の連鎖を断ち切り、型システムを支配せよ
Hackの型チェッカー（HHVM Typechecker）が我々に与えてくれる最大の恩恵は「ランタイムエラーの静的排除」だ。しかし、多くの開発者はその恩恵を享受する過程で、至る所に `?` を散りばめ、結果として「Nullチェックの迷宮」という技術的負債を自ら作り出している。
いいか、`?` を多用するということは、「私はこの値がNullである可能性を解決する設計ができなかった」と白状しているのと同じだ。
今回は、HHVMのアーキテクチャを知り尽くした視点から、Nullableの伝播を物理的に遮断し、堅牢で美しいコードを構築するための「設計の型」を伝授する。
—
1. Nullableの「伝播」が引き起こすアーキテクチャの腐敗
なぜ `?` を多用してはいけないのか。理由は単純だ。Nullableは伝播するからだ。
ある関数が `?T` を返せば、それを呼び出すすべてのコンテキストで「もしNullだったら…」という分岐処理を強制される。これがコードベース全体に広がると、ビジネスロジックの本質よりも「Nullの防御コード」の方が支配的になる。
静的型付けの真髄は、「Nullが発生しうる境界線（Boundary）を最小限に絞り込み、その先は純粋な型のみでロジックを駆動させること」にある。
—
2. 実戦的パターン：Nullableを「ドメインオブジェクト」で封じ込める
Nullチェックの連鎖を回避する最も強力な武器は、`Shape` や `Class` による構造化と、`Result` パターン（あるいはそれに準ずるNullObject）の採用だ。
アンチパターン：Nullチェックの連鎖
public function processUser(?User $user): void {
// 読みづらく、拡張性が皆無
if ($user !== null) {
$profile = $user->getProfile();
if ($profile !== null) {
$address = $profile->getAddress();
if ($address !== null) {
// ここにようやくロジックが書ける
}
}
}
}
推奨パターン：型による境界の強制と「デフォルト値」の設計
Nullが発生する可能性のある外部データ（APIレスポンス等）は、システムの入り口で即座に「Validなオブジェクト」か「例外（またはResult）」に変換する。
<<__ConsistentConstruct>>
final class UserProfile {
public function __construct(
private string $address = ‘Unknown’, // Nullの代わりにデフォルト値を保持
) {}
public function getAddress(): string {
return $this->address;
}
}
// 境界線でNullableを解消するファクトリメソッド
final class UserFactory {
public static function createFromData(mixed $data): User {
// ここでバリデーションを完結させ、システム内部にはNullを流さない
$address = idx($data, ‘address’) ?? ‘Unknown’;
return new User(new UserProfile($address));
}
}
// 内部ロジックは常にクリーン
public function processUser(User $user): void {
// Nullチェックは不要。型が保証されているため、HHVMの最適化も最大化される
echo $user->getProfile()->getAddress();
}
—
3. なぜこの設計が「速い」のか（HHVMアーキテクチャの視点）
HHVMのJITコンパイラは、コードが「厳格な型（Strict Mode）」で記述されているほど、推論の精度が上がり、マシンコードへの変換効率が向上する。
- 型推論の単純化: `?T` が排除されることで、HHVMのType-Inferenceエンジンは変数のライフサイクルをより精密に追跡できる。
- 分枝予測の最適化: `null` チェックの数が減れば、CPUの分枝予測（Branch Prediction）ミスが激減する。パフォーマンスのボトルネックは往々にして「無意味なガード節」にある。
—
4. プロダクションコードで使うべき「Nullable制御」の鉄則
最後に、君たちが明日からチームに導入すべき3つの鉄則を記す。
1. 「Nullableを関数外に出さない」: 関数の戻り値に `?` をつけたら、その瞬間にその関数の設計を見直せ。`null` の代わりに `Result
2. `idx()` は境界線のみ: 配列アクセスにおける `idx()` は便利な道具だが、ビジネスロジックの深部で使えばそれは「思考停止」の証拠だ。データの取得層（Repository/Gateway）で全て解決せよ。
3. Strict Modeの厳守: 全てのファイルに `<<__Strict>>` を付与し、Hackの型チェッカーを最大限に働かせろ。型チェッカーがエラーを吐くのは「コードが悪い」のではなく、「設計が曖昧である」という警告だ。
—
結論：型は自由を奪う鎖ではない
多くのエンジニアは、静的型付けを「面倒な制約」と捉える。だが、真のプロフェッショナルにとって、型は「バグの可能性を排除し、コードを自信を持ってリファクタリングするための地図」だ。
`?` を連鎖させるのは簡単だ。だが、その先に保守性はない。
システムが成長すればするほど、Nullチェックの連鎖は君たちの足元をすくうだろう。
今日から `?` を見つけたら、それは「設計の改善要求」だと認識してほしい。コードの境界線を正しく引き、HHVMに最適化の余地を与え、型システムを味方につける。それこそが、Hackを掌握するということだ。
コードレビューで君たちがこのアプローチを実践することを期待している。健闘を祈る。