はじめに (対象読者・この記事でわかること)

このブログは、iOSアプリ開発を行っている中級者以上のプログラマを対象としています。Swiftで実装した機能が次第に入れ子構造（ネスト）を深くし、コードが読みにくくなる経験はありませんか？ 本記事を読むと、深いネストが生む可読性・保守性の問題点と、ネストを浅く保つ具体的なリファクタリング手法が理解でき、実際のプロジェクトにすぐ適用できるようになります。執筆のきっかけは、社内コードレビューで頻繁に指摘される「if‑letやguard の多重ネスト」をどうすればスマートに解消できるかをまとめたくなったことです。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。
- Swift の基本構文（変数、定数、関数、クロージャ）
- Optional の扱い方（if let、guard let）
- 基本的な Xcode の操作

ネストが深くなる原因とその影響

Swift では安全な型チェックやエラーハンドリングのために if let、guard let、switch、do‑catch といった制御構文を多用します。これらを組み合わせると、たとえば以下のように 三段以上の入れ子 がすぐに形成されます。

Swift

if let user = fetchUser() {
    if let profile = user.profile {
        if let address = profile.address {
            // さらに deep な処理
        }
    }
}

このようなコードは 視認性が低下 し、バグの原因 になるだけでなく、テストしにくい という副作用も伴います。特に匿名クロージャや非同期処理（async/await）と組み合わせると、関数スコープが縦に伸びてしまい、ロジックの追跡が困難になります。

さらに、Swift のコンパイラは 構造が深いほど型推論に時間がかかる ことが報告されています。実際にビルド時間が長くなるケースも多く、開発サイクル全体の効率にも悪影響を及ぼします。したがって、「ネストを浅く保つ」ことは、可読性・保守性・ビルド速度の三点で大きなメリット をもたらす重要な設計指針です。

ネストを浅くする実践テクニック

1. Guard 文で早期リターン

guard は条件が満たされないときに早期リターンできるため、入れ子を横に展開しやすい構文です。上記の例を guard に置き換えると次のようになります。

Swift

guard let user = fetchUser() else { return }
guard let profile = user.profile else { return }
guard let address = profile.address else { return }

// ここからは address が必ず存在することが保証されている
process(address)

ポイント
- 条件ごとに guard を並べるだけでインデントが 1 レベルに収まる。
- 失敗パスが上部に集約されるので、ロジックの主要フローがすぐに見える。

2. Optional Chaining と Nil Coalescing の活用

Swift の ?. と ?? を組み合わせると、複数レベルの Optional を安全に辿れる上に、入れ子構造を一本化できます。

Swift

let city = user?.profile?.address?.city ?? "Unknown"

この一行で user から city までの三段階の Optional をチェックし、nil の場合はデフォルト値 "Unknown" が返ります。if let の多重ネストを完全に排除でき、コード行数も大幅に削減できます。

3. 小さな関数への分割（Extract Method）

入れ子が深くなりがちなロジックは、意味のある単位へ切り出すと効果的です。たとえば、上記の process(address) の内部でさらに複雑な処理がある場合、次のように関数化します。

Swift

func handleAddress(_ address: Address) {
    guard let geo = address.geoCoordinates else { return }
    updateMap(with: geo)
    log(address.id)
}

こうすることで、呼び出し側は 1 行のシンプルなコードになるだけでなく、テスト対象が明確になるためユニットテストも書きやすくなります。

4. Result 型と async/await の組み合わせ

非同期処理でのネストは completion ハンドラが重なることで発生しやすいです。Swift 5.5 以降の async/await と Result 型を併用すると、非同期フローを直列化でき、入れ子が自然に浅くなります。

Swift

func fetchUserProfile() async throws -> Profile {
    let user = try await api.fetchUser()
    guard let profile = user.profile else {
        throw MyError.missingProfile
    }
    return profile
}

// 呼び出し側
Task {
    do {
        let profile = try await fetchUserProfile()
        // ここで profile が安全に使用可能
    } catch {
        // エラーハンドリング
    }
}

try await が順序通りに実行され、エラーハンドリングは do‑catch のみで完結するため、入れ子が 1 レベルに抑えられるのが特徴です。

5. カスタム演算子で条件結合

高度なテクニックとして、複数の guard 条件を一つのカスタム演算子で結合する手法があります。以下は && の代わりに &? を定義し、Optional の連結チェックを簡潔に行う例です。

Swift

infix operator &? : LogicalConjunctionPrecedence
func &? (lhs: Bool?, rhs: Bool?) -> Bool? {
    guard let l = lhs, let r = rhs else { return nil }
    return l && r
}

// 使用例
guard (user != nil) &? (user?.profile != nil) &? (user?.profile?.address != nil) else { return }

このアプローチはコード量を削減しつつ、読み手が意図をすぐに把握できる点で有用です。ただし、可読性を損なわない範囲での使用が推奨されます。

ハマった点やエラー解決

  • Guard のスコープが意図せず広がる
    guard で複数の条件をまとめると、変数がスコープ外になるケースがありました。解決策は、条件ごとに個別の guard に分割し、必要な変数はそれぞれのスコープで再定義することです。

  • Optional Chaining の過度な使用
    ?. を多用しすぎると、意図しない nil が伝搬し、デバッグが困難になることがあります。nil が許容できない箇所では 明示的な guard を併用し、失敗パスを早期に切り出すようにしました。

  • async/await とエラーハンドリングの衝突
    async 関数内で guard を使うと、throw ができないケースがあります。対策としては、guard の代わりに if let と throw を組み合わせるか、カスタムエラー型を用意して throw するように統一しました。

まとめ

本記事では、Swift における深いネストがもたらす可読性・保守性の問題と、Guard 文、Optional Chaining、関数抽出、async/await、カスタム演算子といった実践的テクニックでネストを浅く保つ方法を紹介しました。

  • Guard で早期リターンし、インデントを最小化。
  • Optional Chaining と Nil Coalescingで一行に集約。
  • 小さな関数へ分割してロジックを局所化。
  • async/await と Resultで非同期フローを直列化。
  • カスタム演算子で条件結合を簡潔に。

これらを意識すれば、コードの可読性が向上し、バグの潜在リスクが低減、さらに ビルド時間の短縮にもつながります。次回は、これらのテクニックを組み合わせた大規模プロジェクトでのリファクタリング事例を取り上げる予定です。

参考資料