投稿理由、内容

自分自身の振り返りを含めて投稿します。
仕様の指摘、OS・言語としてのベストプラクティス、デグレやアップデート時の確認など
いろいろなレビュー時の観点があると多います。
今回の投稿ではiOS/Swiftで開発してのナレッジになります。

あと、SwiftLintとか入れると勉強になりますよね。٩( 'ω' )و

参考になったもの

今回２人体制での開発、相互レビューだったので教えてもらう部分もたくさんありつつ、以下の記事は観点と目的がまとまってたのでわかりやすかったです。
https://qiita.com/kkoide1332/items/4545bf8c2ffbfb05bb1f

コメント例

その他実際に意識してた部分、レビュー時にコメントされた中でプロジェクト関係なく必要なものを以下にざっくりまとめました。

また、Swift、Cocoaフレームワーク限定の観点もありますので全部が全部ではないです。（get/setはjavaとか普通に使うし）

名前get/setつけない。
BooLでis使う時には考える。意味がおかしくなるのが多いのでhasやshouldなど場合に応じて適宜する。
typo、インデント大事。
デザイン確認。
OS差分、端末差分確認。
メソッドは何が必要でどのような結果になるかわかるように作る。
　例えば、返却値があったほうが結果がわかる。返却値がない場合はメソッド名をわかりやすく。
　引数を持たせる時もswiftやCocoaの思想に寄せる。
メンバ変数はできるだけ作らない。というかスコープを狭く。
Viewをtagで判定しない（UIButtonとかの）。enum作ったり、extentionして分かりやすく。
〜Array,Listという名前は使わない。複数形は〜s。
配列操作は.mapやfilter。FRPを意識する。
　ループはforinではなくてforEachを使った方が統一感が出て読みやすい（もちろん用途によるが）。
略記は使わない。（imgViewやVcはなし。imageViewやviewControllerと書く）
2行改行は使わない。（意図があればよし）逆に１行改行は見やすくするためよく使う。
if文で条件複数の場合で１行が長くなるようだったら改行入れて見やすく。
　例）if let text = XXXXXXXXXXX.text,
text.isEmpty {}
修飾子は基本privateつける。defaultはinternal。
classには基本finalつける。
命名はUIKitのproperty名に合わせる。ScreenではなくてViewなど
読み手に分かりやすいコメントを。素材差し替えするなど修正する場合→TODO: で、不具合ある場合は、FIXME: ,理由や実装経緯はNote：、でコメント追加。
ifNeededは使っていいと思うが嫌派もいる。
プロジェクトでコーディングルールを決める。
例えば、コロンの後に必ず半角スペース。コロンは左の変数に対してかかっている。
基本的にメソッドコメントは残さなくて良い。なぜその処理をしているのかの説明のコメントを残す。
TODOコメントや不要なテストコードはレビュー前に削除。
非公開APIはAppleの審査に通らないのでNG。
個人情報に関する表示、データの扱いはAppleの規約確認でリジェクト対応。申請時の理由模索。
StoryboardでのViewの前後関係に注意（どちらが画面手前か）。
guardで弾いて良いか、ifletで継続させるかチェック。
didSetかviewDidLoadなどでの設定かは意識する。（funcにするくらい長ければ（10~40行目安）viewdidloadで。他でもそのfuncを使用するならなど。）
if文内でBoolを変更する場合はelseで反対の値を入れる必要があるかチェック。
タスク分解はMVC粒度とかが良い気がする。
readOnlyか外からsetできる必要があるか考慮。コードを読むときの可読性向上。private(set)や変数{}など使用。
引数のdefault値を設定する場合、引数名がなくても外から分かりやすいか考慮する。
typoの気づきが減るよう、英語の勉強と確認必要。公式APIは読めるように。¹
基本的にViewにaddsubViewする。buttonの上にbutton,imageViewの上にButtonなどaddsubViewしない。
ViewにModelを持たせない。

typoを教えてくれるXcodeの機能についてはtypo多い自分にとって過去一レベルで便利だったXcodeの機能で紹介してます。 ↩