導入
プログラミングにおいて、最も恐ろしいバグの一つが「想定外のケース」の発生です。特に、新しい状態や型を追加した際に、以前書いたコードの修正漏れによって予期せぬ実行時エラーが発生することは、大規模なシステム開発において非常に大きなリスクとなります。本記事で解説する「網羅性チェック」を活用すれば、コンパイラが自動的に修正漏れを指摘してくれるため、新機能追加時の心理的負荷を劇的に下げることができます。
基礎知識
関数型言語（Haskell, Scala, Rust, Elmなど）における「網羅性チェック」とは、パターンマッチングを行う際に、定義されたすべてのデータ型（コンストラクタ）が処理されているかをコンパイラが静的に検証する仕組みです。
例えば、あるデータ型に「成功」と「失敗」の2つの状態があるとして、両方のケースに対する処理を記述しなければ、コンパイラは「パターンが網羅されていません」とエラーを吐き出します。これにより、プログラムが実行される前に、開発者が考慮漏れに気づくことができるのです。
実装/解決策
網羅性を確保するための鉄則は、「if文による条件分岐を避け、データ型に基づいたパターンマッチングを利用すること」です。また、言語によっては、不要なケースを明示的に無視する「ワイルドカード（_）」を多用しすぎないことも重要です。ワイルドカードを使ってしまうと、新しいコンストラクタを追加してもコンパイラが警告を出せなくなってしまうためです。
サンプルプログラム
今回は、状態を表すデータ型を例に、網羅性チェックの力を確認します。以下はRust風の疑似コードです。
// 3つの状態を持つデータ型
enum TaskStatus {
Pending,
InProgress,
Completed,
}
// 状態に応じたメッセージを返す関数
fn get_message(status: TaskStatus) -> String {
match status {
// 全てのケースを網羅しているため安全
TaskStatus::Pending => “開始待ちです”.to_string(),
TaskStatus::InProgress => “進行中です”.to_string(),
TaskStatus::Completed => “完了しました”.to_string(),
}
}
/
仮にここで「Cancelled（キャンセル）」という新しい状態を追加したとします。
すると、上記のget_message関数のmatch式でコンパイルエラーが発生し、
「Cancelledが処理されていません」とコンパイラが教えてくれます。
これにより、修正漏れが物理的にゼロになります。
/
応用・注意点
現場での開発において陥りやすい罠は、ライブラリの外部型などに対して「とりあえずワイルドカードで逃げる」ことです。もちろん、将来的に増える可能性がないと断言できる場合は別ですが、基本的には可能な限り網羅的に記述することを推奨します。
また、どうしてもデフォルトの処理が必要な場合は、網羅性を確保した上で、その関数内でのみデフォルト値を扱うように設計を見直すのが、関数型プログラマとしての洗練されたアプローチです。コンパイラという「最強の同僚」を信頼し、自分自身の記憶力に頼らない開発環境を構築していきましょう。
コメント