Swiftのコーディングスタイルガイド

JavaやPythonなどそれぞれの言語に応じたコーディングスタイルガイド（規約）というものがある。自分一人で開発を行う場合でもそういったものにしたがっておいた方が後々見直すときに都合がよい。

しかしSwiftは新しいこともあり、あまりコーディング（プログラミング）スタイルガイドについて記載されているものを見かけない。

JavaやC++などでは一冊まるごとスタイルガイドという本さえある。いまでも売っている実践Javaコーディング作法 プロが知るべき、112の規約と21の心得やThe Elements of C++ Styleがある。後者には日本語版もあったが絶版のようだ。

昔から開発を行っている大手SIerなどなら独自にガイドラインを作成している所も少なくないだろう。中小の開発会社でそういうものを作成する余力のあるところはないのではないだろうか？

Swift言語の定本

プロの開発者向けのSwiftの定本としてMastering Swiftがお勧めできる。内容はもちろんだが、頻繁にアップデートされるSwiftに追いついていて今では第6版で最新5.3に対応しているからである。

全部で20章、約400ページの洋書としては中くらいの厚さの本で、19章にスタイルガイドがまとめられている。

1章分ということで、すぐに読めるし実戦的だ。

Swiftスタイルガイド

1. 文末にセミコロンをおかないこと

   C++等から来た人は思わず付けてしまうが、Swiftでは付けてもよいけど付けない方が良いだろう。ということらしい。

2. 条件文に丸括弧を使わない

   コレも習慣の問題。複雑な条件(&&)||(&&)等の場合は仕方ないと思うが、そういう複雑な条件を設定する時点で一歩立ち止まって考えた方が良いかも。

3. 命名法について

   記述的な名前をキャメルケースで用いる

   i. カスタム型

   大文字で始まるキャメルケース

   ii. 関数とメソッド

   小文字で始まるキャメルスタイル。アンダースコアで単語を分けない。（Pythonでよくある書き方だがSwiftではダメ）

   iii. 定数と変数

   基本は関数やメソッドと同じだが、グローバル定数の時は全部大文字で書く。

4. インデント

   Xcodeで4スペースが既定になっている。そのままでいい。下はXcodeのインデントに関するPrefereneces
   

5. コメント

   1行コメントとブロックコメントがある。

   関数のコメントブロックコメントにパラメータや返却値、スローするエラーについてのキーワードを設定し、ドキュメント化できるようである。

   parameter, returns, throwsがそれ。

6. selfキーワードの利用法

   selfキーワードは他の言語ではthisキーワードとして知られていることが多い。Swift 5.3になって大抵の場合使わなくてもコンパイラが認識してくれるようになった。だから特別に必要性を感じなければ書かないようにした方が良いだろう。

7. まずは定数として定義し、値を変更する必要が出て初めて変数として定義しなおす

   まずはletで作っておいて、後で変更する必要が出てきたらvarにする。もっとも一度も変更されないVarについては警告が出るようになってはいる。（でも警告されるのは嫌な人がほとんどだろう。。）

8. オプショナルについて

   必要最小限にすることと。やたらなんでもOptional定義する人がいるが、上級のPGなりエンジニアが「それ、なんでオプショナル？」と聞いて答えられないケースってよくあるものだ。

   これが厄介なのは意味不明なままオプショナルになっているコードをメンテする際。もともとのところまでたどっていかないと必要性の判断ができないケースが多い。

9. 型推論を利用し、必要なときだけ明示的に型を示す

   これは場合と状況による。明らかな文字列に String修飾子を付ける必要がないが大きな配列などではコンパイル時にコンパイラが「音を上げる」こともある。基本は付けず、大型の配列などでは付け、と言うので良いと思う。コンパイル時間も掛かるし。

10. コレクションについては簡略定義を用いる

    簡略定義とは以下のようなもの

    “`Swift
    //Preferred Method　好ましい書き方
    var MyDictionary: Dictionary [String: String] = [:]
    var strArray: [String] = []var strOptional: String?

    //Non-Preferred Method　　好ましくない書き方
    var myDictionary: Dictionary
    var strArray: Array
    var strOptional: Optional

11. 複数のif分を用いるよりはswitch分を用いる

    確かにこの方が見やすいl

12. コメントアウトしたコードを最終版に残さない

    なんのためみGitHubなどVCSを入れたのか？ということだろう。

まとめ

コーディングスタイル（規約）はあまりギチギチにしても生産性が下がるが、後で自分のコードを読むときにも役立つので一人で開発を請うなう場合でも守っておいた方が良いと思う。

またこのMastering SwiftはSwift全般についてよく書かれてある良い本なのでもっておいて損はないと思う。

Appleプラットフォームで何か作る場合にはClassとStructの大きな違いに気をつけなければいけないので、それについてはまた別途記載することにする。

いくつかのプロジェクトに参画した経験から言うと、こういった規約の利用を推奨するPMや社としての方針で作成している所は実に少ない。