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を参考にしています。
- 作者: 荻原剛志
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2014/12/10
- メディア: 大型本
- この商品を含むブログ (2件) を見る
「 var
なの?let
じゃダメなの?」
強い型付けによる安全性を持っている Swift だからこそ、let
でいけるところは全て let
にしましょう。
var で定義されている変数については、その理由がコードを読んで理解できるかどうかで判断します。
「このオプショナル nil
の可能性あるよね?クラッシュするよ?」
Swift の特徴ともいえるオプショナル型。
その変数に入っている値を実際に取得するために開示したいケースが多々あります。
そこでオプショナル型に対して使われるのが開示指定と呼ばれるもので、変数の後ろの!
を付けるあれです。
手軽な反面、もし変数の値が nil な場合、ランタイム時にクラッシュしてしまいます。
なのでオプショナル型の開示指定は極力避けて、オプショナル束縛構文を用いるべきです。
if let
と言った方がはやいですね。
また同様に暗黙的開示オプショナル型の定義も nil が入る可能性がないか慎重に行うべきです。
使うべきシーンとしては ViewController の GUI パーツなど、初期化時に必ず値が入っていることが
保証されている箇所などに限定するべきです。
「self
いらなくない?」
Objective-C では self
を経由して自身のプロパティやメソッドにアクセスすることが普通でした。
Swift では self
を使わずともそれらにアクセスすることができます。
なので self
を用いる時はクロージャ内や名前空間を意識した場合などに限定して簡潔さを保つべきです。
まとめ
上記の翻訳ドキュメントには他にもまだまだ書いてありますので興味あればみてください。
またこれ以外にも「こんなところみてるよ」などあったらコメントなどで教えて下さい!