jarinosuke blog

about software engineering, mostly about iOS

Swift のコードレビューで気をつけていること

Swift での iOS アプリ開発

徐々にですが、でも確実に色々な場面で Swift のコードを見る機会が増えてきたことを実感します。

iOS の設計思想など大枠の部分では Objective-C での知見は生きてきます。

しかし Swift の言語仕様についても知っておかないと

ついつい低きに流れて Objective-C ぽい Swift になってしまいがちです。

Swift のコードレビュー

そこで Swift らしく Swift の良さを活かしたコードにするためにコードレビューの話になるわけです。

iOS 開発全般におけるコードレビューについては以下のブログにまとまっているので省きます。

iOSアプリケーション開発のコードレビューで気をつけていること - ninjinkun's diary

また本記事を書くにあたって Swift コードレビューを調べていて良いものがまとまっていたので

fork して日本語訳にしたものもあります。

jarinosuke/swift-style-guide README_JP.md

日本語訳が怪しいところは[?]を付けているので、レビューしてもらえると助かります。

書こうと思って溜めていたことは大体上にも書いてあったので安心しました。

ということで以下から気をつけていることをいくつか挙げました。

以下に挙げる具体的な言語仕様や文言の翻訳などは詳解Swiftを参考にしています。

詳解 Swift

詳解 Swift

var なの?let じゃダメなの?」

強い型付けによる安全性を持っている Swift だからこそ、let でいけるところは全て let にしましょう。

var で定義されている変数については、その理由がコードを読んで理解できるかどうかで判断します。

「このオプショナル nil の可能性あるよね?クラッシュするよ?」

Swift の特徴ともいえるオプショナル型。

その変数に入っている値を実際に取得するために開示したいケースが多々あります。

そこでオプショナル型に対して使われるのが開示指定と呼ばれるもので、変数の後ろの! を付けるあれです。

手軽な反面、もし変数の値が nil な場合、ランタイム時にクラッシュしてしまいます。

なのでオプショナル型の開示指定は極力避けて、オプショナル束縛構文を用いるべきです。

if let と言った方がはやいですね。

また同様に暗黙的開示オプショナル型の定義も nil が入る可能性がないか慎重に行うべきです。

使うべきシーンとしては ViewController の GUI パーツなど、初期化時に必ず値が入っていることが

保証されている箇所などに限定するべきです。

self いらなくない?」

Objective-C では self を経由して自身のプロパティやメソッドにアクセスすることが普通でした。

Swift では self を使わずともそれらにアクセスすることができます。

なので self を用いる時はクロージャ内や名前空間を意識した場合などに限定して簡潔さを保つべきです。

まとめ

上記の翻訳ドキュメントには他にもまだまだ書いてありますので興味あればみてください。

またこれ以外にも「こんなところみてるよ」などあったらコメントなどで教えて下さい!

参考