Swiftでas!と書く場合のガイドライン - soutaroブログ
as!って言うのは、要するにダウンキャストできない場合にプログラムを終了させるものである。 if let x = expr as? SomeClass { f(x) } else { fatalError() } と書くのであれば、 f(expr as! SomeClass) と、同じことなので、as!で書いた方が良い。その方がタイプ数が減るし、コードの見た目も簡潔になって理解しやすくなる。長いコードはそれだけで苦痛だし、なにか間違ったプログラミングをしていることを示すシグナルにもなる。ダウンキャスト失敗の場合に終了するためだけにifを書くことは、全体的なコードの乱雑さを増してしまい、本当の問題の見落としに繋がる。 ただし、as?とかas!とかダウンキャストをしてる時点で、そのプログラムには潜在的な問題があると考えることもできて、本当にダウンキャストが必要なのか3回くらい考えた方が良い。
iOSアプリケーションでコードベースのレイアウトを積極利用する - クックパッド開発者ブログ
海外事業向けのiOSアプリケーション開発を担当している西山(@yuseinishiyama)です。クックパッドは現在、海外複数カ国に向けてサービスを展開しています。 XcodeにはInterface Builderと呼ばれる、リッチなGUIを持ったデザインツールが付属しており、これを用いて画面のレイアウトを構成することが主流となっています。弊社ブログでも、iOS開発でstoryboardとxibをうまく使い分けるプラクティス等の記事で、GUIベースのレイアウトについて触れています。しかし、現在私が担当しているプロジェクトでは、Interface Builderを用いずに、レイアウトの大半をコードで記述しています。 今回は、コードベースのレイアウトを実装していく中で得た知見を、以下の3つの部分に分けて共有したいと思います。 Interface Builderを用いたレイアウトとコードベースの
Swift のコードレビューで気をつけていること - jarinosuke blog
Swift での iOS アプリ開発 徐々にですが、でも確実に色々な場面で Swift のコードを見る機会が増えてきたことを実感します。 iOS の設計思想など大枠の部分では Objective-C での知見は生きてきます。 しかし Swift の言語仕様についても知っておかないと ついつい低きに流れて Objective-C ぽい Swift になってしまいがちです。 Swift のコードレビュー そこで Swift らしく Swift の良さを活かしたコードにするためにコードレビューの話になるわけです。 iOS 開発全般におけるコードレビューについては以下のブログにまとまっているので省きます。 iOSアプリケーション開発のコードレビューで気をつけていること - ninjinkun's diary また本記事を書くにあたって Swift コードレビューを調べていて良いものがまとまっていた
え!? Swift使ってるのにそんな書きかたしてるのですか!?
iOSアプリをSwiftらしいコードで記述するために
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Port to Android by modocache · Pull Request #1442 · apple/swift
