目的

これから、人にも引き継いでいくので、ルールを作っていく。
ブラッシュアップは定期的に行っていくs

関数や、変数名の付け方

キャメル記法（ロウワーキャメルケースってやつ）で。いまそうなってないやつは今後直していきます。
参考：https://blog.e2info.co.jp/2015/09/24/namingrules/

役割を明確に

commonディレクトリや、utilディレクトリは禁止
長くなってもいいから役割を明確に。
〜Utilとかはなるべく使わない。
色々な機能が入らないように、プログラムが短くなるように（目標200行）名前を考える。

ただし

realmのモデル名は、ロウワーキャメルケース
propertyの定義は、スネークケースで！

NSUserDefaultsの扱い

UDWrapperを使ってください。
https://gist.github.com/fwhenin/b770228a982230bd8690

Unwrapped optionalは原則禁止

アプリが落ちる原因になりやすいので、不要の場合は使わない。
IBOutlet系の定義時などやむを得ない場合のみ。

依存性の低い作りに

protocol.delegate,callbackを駆使して、依存性の低い（単体テストをしやすい作りに。）

データベース

Realm一択。現時点では。

UnitTestコードはなるべく書く。

あまり頻繁に修正が入らないところはなるべく書いてね。

testing framework

XCUITest/XCTest
ネットワーク系はmockを使う。
https://gist.github.com/joemasilotti/7ff31584c0b6981a8f41
作る上で上記を参考にした

インスタンス変数にあまりBoolは使わない。

そのうち、そのフラグがなにを意味するかわからなくなりそうなので、避けられるときは避ける。
なるべく関数内のローカル変数で頑張ってほしい。
使い方に気をつける。といった意味が近いかも。

classメソッドで解決できるものは、classメソッド

singletonインスタンスで解決できるものはsingletonで

AppDelegateに定義するものは、protocolを用意する

アプリで共通に使うものは、classメソッド,singletonでやる。
Appdelegateでインスタンスを生成してもできるけど、
AppDelegateにインスタンスを大量に置くと、controllerでAppDelegateだらけになり、
可読性が下がり、依存性が高くなるので、あまり良くない
単体テストをしやすくするために、protocolを使う。

IBoutlet系は、weak

strongにすると、循環参照が発生する
InterfaceBuilderにあるやつを、swift側で参照するだけなので、weakで十分。

メモリ管理で不安な場合

ちゃんと、オブジェクトが終了したときに、終了したことをデバッグで確認する
具体的には、一番簡単（でもめんどいよ）の方法が、
各クラスに

deinit

メソッドを追加して、こちらがコールされるか確認する。例えば、Aって画面を閉じるときに、

Aのdelnitが呼ばれていない=メモリが残り続ける

ので、一番最悪なパターンは、電池の減りが早くなることに繋がる。
→lldbで確認する手もあるっぽい。

protocolとdelegate

宣言する際の用途によって、後ろに~protocol/~delegateにするか決める。

処理を委託するなら

~delegate

インスタンス変数は

weak var delegateXxxxx: XXXXXdelegate?

interfaceやtraitみたいな使い方をするなら

protocolとする

汎用性の高そうなものが開発中に出来た場合

targetを分けて、そちらに移し、後々FWできるか検討する。

gitのsubmoduleを使う。

社内で作った、FWはgitのsubmoduleで取り込む
使い方はこちら。(修正中)
iOSのフレームワークを作ってみる

ある機能に対してのprotocolは追加するものと同じgroup(ディレクトリ)に配置する

その前提で進めてみて、うまくいかないようであれば、別で管理するところを作るなどする。

ViewControllerは〜ViewController、xibは〜Viewとつける

ここを参考に