VisasQ Dev Blog

ビザスク開発ブログ

静的コード解析ツールのSwiftLintを使った1人でも安全なiOSアプリ開発

技術記事

はじめまして、こんにちは！ 4月よりiOSアプリエンジニアとしてビザスクにジョインした田中です。

今までビザスクではPC/SPのWebサイトをメインに提供していましたが、iOSアプリ版を提供するためにアプリを鋭意開発中です。

ビザスクでは現在アプリエンジニアは自分1人です。 スタートアップなどで同じように1人でアプリを開発している方は多いのではないでしょうか。

アプリエンジニアが複数いればコードレビューをしながら開発を進めることができ、コードの品質を高めていくことができます。 1人だと誰も自分のコードをみてくれないので「綺麗なコードを書く」という意識が薄れていき、統一感のないコードや他人や明日の自分がみた時に読みづらい汚いコードが生まれがちなのではないかと思います。汚いコードを書いているとバグが生まれやすくなったり、いつか2人目、3人目のエンジニアが増えた時に困ってしまいますよね。

そこで、今日はコーディングスタイルに沿った綺麗なコードを書くために使える静的コード解析ツールのSwiftLintをご紹介したいと思います。

SwiftLintとは

SwiftLintはソースコードの妥当性をチェックするLinterの一種で、GitHub's Swift Style Guideをベースにしたルールに基づきコードを検査するツールです。

例えば余計な空白や改行が入っていないかといったことや、1メソッドの行数が多すぎやしないかなどのルールをチェックし、ワーニングやエラーを発生させます。 定義されているルールはこちらから実装内容を確認できます。

これらのルール全てを適用する必要はなく、個々のルールを適用するかしないか、どの程度適用するかといったことを自由に設定できます。 ワーニングにするかエラーにするかも設定できます。

いくつか具体的にルールをご紹介します。

opening_brace

関数等で使う「{」は直前に1つのスペースが必要で、かつ宣言と同じ行に記述しなければいけません。スペースが2つ以上あってもワーニングが発生します。

leading_whitespace

ファイルの先頭に空白があるといけません。

function_body_length

関数内の行数に制限をかけます。デフォルトでは関数内の行数が41行以上あるとワーニングが発生します。 制限をかける行数は自由に設定できます

mark

MARKを使ってコメントを書く時は正しいフォーマットでなくてはいけません。

// MARK Sample これはOK
// MARK:Sample これはNG

type_name

クラス名は大文字でなくてはいけません。

overridden_super_call

Overrideされたメソッドは必ずSuperのメソッドを呼び出さなければいけません。 (デフォルトではこのルール無効になっているようです)

現在こういったルールが75個以上提供されています。

使い方

インストール

SwiftLintのインストール方法にはHomebrewとCocoaPodsが使えます。ここではCocoaPodsを使ったインストールをご説明します。 CocoaPods自体のインストール・セットアップ方法は省略します。

CocoaPodsでSwiftLintをインストールする場合はPodfileに下記を記述します。

pod 'SwiftLint'

セットアップ

インストールが完了したらxcworkspaceファイルを開いて「TARGETS」→「Build Phases」の「Run Script」に下記を記述します。

"${PODS_ROOT}/SwiftLint/swiftlint"

Build PhasesにRun Scriptがない場合は、Build Phases画面の左上の「＋」ボタンから「New Run Script Phase」を選べば追加できます。

これでアプリをビルドするたびにSwifLintが走るようになります。

試しに作成したばかりのプロジェクトに適用したところ、ワーニングが22件、エラーが2件となりました。なかなか手厳しいですね。

設定変更

個々のルールの適用の有無を変更したり閾値を変更する場合は.swiftlint.ymlに記載します。.swiftlint.ymlはxcworkspaceファイルと同じディレクトリに作成します。

例えば下記のように記載すると先ほどのプロジェクトでワーニングもエラーも発生しなくなります。

included:
 - SwiftLintSample

line_length: 300

disabled_rules:
 - vertical_whitespace
 - trailing_newline

.swiftlint.ymlの詳しい書き方はSwiftLintのgithubをご参照ください。

まとめ

プロジェクトに導入して大体5,000行くらい書いてみました。個人的には導入して正解だったと思います。 一人で書いていては見落とすような場合でも都度指摘してくれるので、必要以上に「綺麗に書こう」と意識しなくても「指摘されたら修正すればいい」という気持ちで気軽にコードを書いていても、一定の統一感は保証されるので楽になりました。

また、試しに個人的に開発している1万行も無いプロジェクトに導入したところワーニングが400個、エラーが60個ほど発生してしまいました。 SwiftLint自体はどのタイミングからも導入できるツールではありますが、できるだけ開発の早い段階で導入した方が導入直後の修正が少なくなるので良いと思います。 ご興味あればぜひ使って見てください。

最後までお読みいただきありがとうございました。

今回はiOSの話をさせていただきましたが、ビザスクでは一緒に働くWEBエンジニアを募集中です！ 世界中の知見をつなぐサービスを一緒に開発してくれる方をお待ちしております！