iOSアプリ/Swift開発において、コードの品質と可読性を保つための Lint と Formatter についてまとめました。
目的とメリット
Lint（静的解析ツール）
- 目的
- 潜在的なバグやアンチパターン、非推奨な書き方を検出
- クラスやメソッドの行数、複雑度を監視し、巨大化を防ぐことにより保守性を担保
Formatter（コード整形ツール）
- 目的
- コードの整形ルールを強制し、スタイルを統一
- インデントや改行、スペースなどの表記揺れを自動で修正し、可読性を向上
共通のメリット:
- 開発チーム全体のコード品質・一貫性が向上
- 読みやすく保守しやすいコード
- レビューでスタイル指摘（「ここはスペース空けて」等）に時間を使わず、本質的なレビューに集中が可能
代表的なツール
- SwiftLint (Lint)
- SwiftFormat (Formatter)
- swift-format (Lint + Formatter)
現段階では、 SwiftLint + SwiftFormat の併用が主流で、柔軟なルール設定が可能です。
ただ、 swiftlang/swift-format は Apple 公式のため、長期的には主流になっていく可能性があります。
実案件での運用例
SwiftFormat の GitHub のページでは下記のような使用例が挙げられています。
- 手動で、あるいは他のツールチェーンの一部として実行するコマンドラインツール
- Xcode 内の [Editor] > [SwiftFormat] メニューから呼び出せる Source Editor Extension
- Cmd-R や Cmd-B を押すたびに実行される、Xcode プロジェクトの Build Phase
- ファイルをチェックインする前に変更箇所に対して実行される Git pre-commit フック
上記の内容を踏まえて開発現場での、運用例の一例を紹介します。
実際のスクリプトや導入方法については、それぞれの GitHub レポジトリにも記載があるため、こちらの記事では割愛します。
ローカル環境
Formatter
- ビルド時に実行する Script を追加し自動実行
- 常に整形された状態でコミットすることで、差分をきれいに保つ
Lint
- ビルド時に実行する Script を追加し Xcode 上に Warning/Error を表示
- 開発者は Warning/Error を確認し、手動で修正
CI環境
- PR作成時などにチェックを実行
- ルール違反（Lintエラーやフォーマット未適用）があればCI失敗
補足説明と注意点
SwiftLintの自動修正
SwiftLintには --fix (autocorrect) 機能がありますが、フォーマッターとしては不十分です。
「空白を削除する」などはできますが、「改行を入れて読みやすくする」といった構造的な整形はしません。
そのため、可読性を高めるための構造的な整形や、厳密なスタイル統一を行いたい場合には、SwiftFormat との併用がおすすめです。
ツール間のルールの競合
SwiftLint と SwiftFormat を併用する場合、ルールが競合することがあります。
下記の例は両ツールでデフォルトルールのままですが、コンフリクトが発生します。
- 例：末尾のカンマ (Trailing Comma)
- SwiftFormat: 配列の最後の要素にもカンマをつけようとする（diffが見やすいため）
- SwiftLint: 「余計なカンマがある」とWarningを出す
let array = [
"A",
"B",
]
基本的に Formatter（SwiftFormat）を優先し、SwiftLint側の競合するルールを無効化（disabled_rules）するのが良いかと思います。
Discussion