【実務・中級編】 noFallthroughCasesInSwitchによる制御フローの厳格化 – TypeScript実践ガイド

switch文の「うっかり」を撲滅せよ：`noFallthroughCasesInSwitch` で手に入れる堅牢な制御フロー

やあ。現場でコードを書いていて、「なぜここでバグが起きるんだ？」と頭を抱えた経験はないか？その犯人の一人が、実はJavaScriptの歴史的遺産である「switch文のフォールスルー」だったりする。

今日は、TypeScriptの `tsconfig.json` に隠された、地味だが非常に強力な防波堤である `noFallthroughCasesInSwitch` について、プロの視点から掘り下げていこう。

—

C言語の時代から続くJavaScript（およびTypeScript）の `switch` 文は、明示的に `break` を書かない限り、次の `case` へと処理がなだれ込む仕様になっている。

// 悪い例：これぞ負の遺産
switch (status) {
case ‘loading’:
renderSpinner();
// breakを忘れると…
case ‘success’:
renderContent(); // 意図せずここも実行される！
break;
}

これは「複数のケースで同じ処理をしたい」という時には便利だが、9割のケースでは単なる書き忘れによるバグだ。特に複雑なドメインロジックを扱うフロントエンドにおいて、この「意図しない挙動」は、デバッグ困難な不具合の温床になる。

ブラウザのJavaScriptエンジンは、このコードを「仕様通り」に解釈する。エンジン側からすれば「`break` がないのは、お前がそう書いたからだろう？」というスタンスだ。これに頼るのは、地雷原を裸足で歩くようなものだ。

この設定を `true` にすると、TypeScriptコンパイラは「フォールスルーが発生しうる箇所」を厳しく監視し、警告を飛ばしてくれるようになる。

// tsconfig.json
{
“compilerOptions”: {
“noFallthroughCasesInSwitch”: true
}
}

これを有効にするだけで、「breakを書き忘れた箇所」をビルド時に一瞬で特定できるようになる。現場レベルでの生産性向上、そして何より「ケアレスミスで休日を潰すリスク」を確実に下げることができるんだ。

ただ、現場では「どうしても複数のケースをまとめたい」という正当な理由がある場面もある。この時、`noFallthroughCasesInSwitch: true` だとエラーが出てしまう。そんな時はどうすべきか？

無理に設定をオフにするのではなく、「明示的なフォールスルーであること」をコンパイラに教えるのがプロの流儀だ。

/
function getTaxRate(category: ‘book’ | ‘food’ | ‘luxury’): number {
switch (category) {
case ‘book’:
return 0;

// 意図的にフォールスルーさせる場合は、コメントで意図を残すのがチーム開発の鉄則
// TypeScriptはこれだけでは黙らないため、実務的には下記のように記述を分けるのがベスト
case ‘food’:
case ‘luxury’:
return 10;

default:
return 0;
}
}

もし、どうしても処理を共通化したい場合は、フォールスルーを使うのではなく、ロジックを別関数に切り出すことを強く推奨する。

// 推奨パターン：ロジックを切り出してDRYに保つ
const applyTax = (rate: number) => rate 1.1;

switch (category) {
case ‘food’:
return applyTax(10);
case ‘luxury’:
return applyTax(10);
default:
return 0;
}

このように書けば、`noFallthroughCasesInSwitch` に怒られることもないし、コードの可読性も格段に上がる。

実務でTypeScriptを運用する際、「コンパイラの警告は、自分を助けてくれる優秀なペアプログラマーの指摘」だと捉えてほしい。

`noFallthroughCasesInSwitch` を導入した直後は、既存コードのあちこちからエラーが出るかもしれない。最初は面倒に感じるだろうが、それは今まで「潜在的なバグが放置されていた」証拠だ。

1. まずは設定を有効にする
2. エラーが出た箇所を一つずつ精査する（案外、本当にバグだった場所が見つかるはずだ）
3. どうしても必要な箇所はロジックをリファクタリングして切り出す

このプロセスこそが、君のコードを一段上のレベルへ引き上げる。型安全性とは、単に `any` を排除することではなく、こういった地道な設定の積み重ねによって「実行時の驚き」を極限まで減らすことなんだ。

さあ、今すぐ `tsconfig.json` を開いて、この設定を有効にしてみてくれ。君のチームのコードが、より堅牢で信頼できるものになることを約束するよ。