iOSアプリケーション開発のコードレビューで気をつけていること - ninjinkun's diary
日常的なコードレビューで気をつけていることリストです。GitHub会議(仮)で発表しようと思っていたのですが、日程の都合で参加できないので、書きためておいたメモを公開します。またどこかで発表するかもしれません。 AutoLayoutにできないか AutoLayout化した方がすっきりしそうならAutoLayout化する AutoLayout化できそうなものでやっていないものは、なぜコードで実装したか質問する 例えばUITableViewCell ちゃんと理由があれば別に良い。コードの方が良いことも多い UIAppearanceで解決できないか 各クラスの中にスタイルの指定が入るより、UIAppearanceでスタイル指定を分離して別クラスに書く方がデザイナーも弄りやすくて良い 3.5インチ端末が考慮されているか レイアウトが決め打ちだとここで問題が出ることが多い 着信ステータスバーが考慮さ
もっともっと良いコーディングをするための勘所８つ - 病みつきエンジニアブログ
先日とあるコードレビューを拝見することがあったのですが、それにインスパイアされて記事を書いてみます。レビュワーの方が言ったことも含んでいますが、それと必ずしも一致するものでもありません。 Objective-Cのコードで書いていることが多いですが、わりと一般論だと思います。 photo by Hugo-photography 命名規則は言語の「普通」に任せる 例えば、Objective-Cだと変数にはcamelCaseを使うことが多いです。逆にRubyではsnake_caseを使ったりします。もしくは、略語を使うとか使わないとか、そういう違いもあります。 変数名に対してどういう書き方をするかというのは、個人の好みではなく、言語の慣習に任せるのがいいのではないかと思います。 言語の慣習の調べ方は、Githubで「stars:>100」と検索して、言語を絞るといいでしょう。(参考：Rubyの例
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
