ダークモード対応を直したあたりで、自分のコードを久しぶりに読み返してみたら、変数名がバラバラで、同じような処理をコピペした跡だらけで、我ながら読みにくいと感じました。誰かにコードの書き方を注意してもらう機会もないので、SwiftLintというツールを導入してみることにしました。
1. 導入した瞬間、警告が100件以上出てきた
Homebrewでインストールし、プロジェクトにビルドフェーズを追加してビルドし直した瞬間、Xcodeの警告一覧に100件以上のメッセージがずらりと並びました。
brew install swiftlint正直、最初は「こんなに直すところがあるのか」と気持ちが折れそうになりました。しかし内容をよく見ると、多くは「行が長すぎる」「force unwrapが使われている」といった、自分でも薄々気になっていた箇所ばかりでした。他人に指摘されるより先に、ツールが機械的に洗い出してくれたことで、感情的にならずに直す作業に集中できたのは意外な発見でした。
2. デフォルトのルールが自分には厳しすぎた
一通り警告を直し始めたのですが、.swiftlint.ymlを作らずデフォルト設定のまま使っていると、行の長さ制限（120文字）に頻繁に引っかかりました。特にSwiftUIのモディファイアを連続で書くコードは、どうしても1行が長くなりがちです。
# .swiftlint.yml
line_length:
warning: 150
error: 200すべてのルールに機械的に従うのではなく、自分の書き方の癖に合わせて許容範囲を調整していいのだと分かってから、SwiftLintとの付き合い方が楽になりました。ルールに縛られるためではなく、自分の書き方の傾向を客観視するために使う、という位置づけに変えたのが良かったと思います。
3. force_castの警告で過去のバグを思い出した
警告の中にforce_cast（強制キャストas!の使用）がありました。これは以前、optional型でクラッシュさせた話で経験した「型を強引に決めつけて実行時に落ちる」パターンと同じ危険性を持つ書き方だと気づきました。
let cell = tableView.dequeueReusableCell(withIdentifier: "cell") as! CustomCell該当箇所をas?とguard letを使った安全な書き方に直したところ、過去に似たような原因で何度もクラッシュさせていた記憶がよみがえりました。SwiftLintは新しいミスを防ぐだけでなく、過去に痛い目にあったパターンをコード全体から探し出してくれるツールでもあると実感しました。
4. 全部を一気に直そうとして手が止まった
最初は100件超の警告を一気に全部潰そうとして、逆に何から手をつけていいか分からなくなり、作業が止まってしまいました。結局、swiftlintコマンドに--fixオプションをつけて自動修正できるものから片付け、残りは種類ごとにまとめて対応する方針に切り替えました。
swiftlint --fix自動修正できないルール違反（変数名の付け方など）だけを手作業で直すようにしてからは、無理なく最後まで終わらせることができました。ツールの機能を「全部人力で直す」のではなく「機械にできることは任せる」と割り切ったのが良かったです。
まとめ
- 導入直後は警告が大量に出るが、多くは自分でも気になっていた書き方の癖であることが多い
- デフォルトルールが厳しすぎる場合は
.swiftlint.ymlで自分に合わせて調整してよい force_castなど危険な書き方の警告は、過去のバグの原因と直結していることがある--fixオプションで自動修正できるものから片付けると、大量の警告にも手が止まらず対応できる
コードレビューをしてくれる人がいない個人開発だからこそ、SwiftLintのような機械的なチェックが、書き方を見直すきっかけとして役に立ちました。
次は、個人開発アプリのユーザーフィードバック、どう集めているかをまとめます。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント